On Fri, Sep 11, 2009 at 9:39 PM, Adrian Cornish <adrianc@xxxxxxx> wrote: > Hi All, > > Please excuse me if this is incorrect list. > > How/where should I look in kernel source to see how Linux loads binaries > and whether debug symbols are using physical RAM if they are included in > executable. if it is userspace program....as suggested by Mulyadi....but if it is for kernel module...it is load_module(). http://lxr.linux.no/#linux+v2.6.30.5/kernel/module.c#L1649 > > Or is kernel smart enough to skip all debug symbols and only load needed > Text page into ram. yes....definitely....looking into layout_sections() in the same URL above (from the functions's comment, and code's logic, noticed the SHF_ALLOC is needed to decide whether to allocate memory for it or not): and then look into (for eg) vmlinux: 357 Section Header[45]: sh_name: .debug_info 358 sh_addr: 0 sh_flags: 0 359 sh_size: 0x35b2235 sh_type: [ SHT_PROGBITS ] 360 sh_offset: 0xe9d15a sh_entsize: 0 361 sh_link: 0 sh_info: 0 362 sh_addralign: 0x1 363 364 Section Header[46]: sh_name: .debug_abbrev 365 sh_addr: 0 sh_flags: 0 366 sh_size: 0x167a26 sh_type: [ SHT_PROGBITS ] 367 sh_offset: 0x444f38f sh_entsize: 0 368 sh_link: 0 sh_info: 0 369 sh_addralign: 0x1 370 371 Section Header[47]: sh_name: .debug_line 372 sh_addr: 0 sh_flags: 0 373 sh_size: 0x3050e6 sh_type: [ SHT_PROGBITS ] 374 sh_offset: 0x45b6db5 sh_entsize: 0 375 sh_link: 0 sh_info: 0 376 sh_addralign: 0x1 we can see all the sh_name with "debug" above does not have SHF_ALLOC, whereas for other sections: 49 Section Header[1]: sh_name: .text.head 50 sh_addr: 0xffffffff81000000 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ] 51 sh_size: 0x9000 sh_type: [ SHT_PROGBITS ] 52 sh_offset: 0x200000 sh_entsize: 0 53 sh_link: 0 sh_info: 0 54 sh_addralign: 0x1000 55 56 Section Header[2]: sh_name: .text 57 sh_addr: 0xffffffff81009000 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ] 58 sh_size: 0x4b81f2 sh_type: [ SHT_PROGBITS ] 59 sh_offset: 0x209000 sh_entsize: 0 60 sh_link: 0 sh_info: 0 61 sh_addralign: 0x1000 62 63 Section Header[3]: sh_name: .notes 64 sh_addr: 0xffffffff814c11f4 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ] 65 sh_size: 0x24 sh_type: [ SHT_NOTE ] 66 sh_offset: 0x6c11f4 sh_entsize: 0 67 sh_link: 0 sh_info: 0 68 sh_addralign: 0x4 69 70 Section Header[4]: sh_name: __ex_table 71 sh_addr: 0xffffffff814c1220 sh_flags: [ SHF_ALLOC ] 72 sh_size: 0x1510 sh_type: [ SHT_PROGBITS ] 73 sh_offset: 0x6c1220 sh_entsize: 0 74 sh_link: 0 sh_info: 0 75 sh_addralign: 0x10 76 77 Section Header[5]: sh_name: .rodata 78 sh_addr: 0xffffffff814c3000 sh_flags: [ SHF_ALLOC ] 79 sh_size: 0x1d5cda sh_type: [ SHT_PROGBITS ] 80 sh_offset: 0x6c3000 sh_entsize: 0 81 sh_link: 0 sh_info: 0 82 sh_addralign: 0x40 another important part of layout_sections()'s logic, is that all core sections are loaded BEFORE THE init sections. This is so that all the init sections comes later and grouped together. after initialization of the ELF, the entire sections containing all the init will be deallocated and free from memory, which affecting the other parts of the ELF. which is also why "init" always occupy higher virtual address....but don't ever try to look into it....either the memory is already freed, or the binary information does not match the byte-for-byte mapping on the ELF file (memory used for other purposes). > This is for x84_64 and i686 type kernels with gcc/gdb > > > Adrian > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
