Ollie Lho <[EMAIL PROTECTED]> writes: > With ELF like this: > > ollie mkelfImage 68:objdump -h elfImage
First the really useful dump is: objdump -p elfImage Which actually shows the segments of the image being loaded. And there should be a much better correspondence, between what is loaded, and the segments. > > elfImage: file format elf32-i386 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00001163 00010000 00010000 00001000 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 1 .rodata 000002f1 00011163 00011163 00002163 2**5 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 2 .data 00000018 00011460 00011460 00002460 2**2 > CONTENTS, ALLOC, LOAD, DATA > 3 .bss 000042a8 00011478 00011478 00002478 2**5 > ALLOC > 4 .nokill 00000028 00091000 00091000 00003000 2**0 > CONTENTS, ALLOC, LOAD, CODE > 5 .kernel 00154660 00100000 00100000 00004000 2**0 > CONTENTS, ALLOC, LOAD, DATA > > I got: > Welcome to elfboot, the open sourced starter. > January 2002, Eric Biederman. > Version 1.0 > > 43:fill_inbuf() - ram buffer:0x00012c28 > 53:fill_inbuf() - nvram:0x00010000 block_count:0 > Found ELF candiate at offset 0 > Loading Section: addr: 0x000000000776ecb8 memsz: 0x0000000000005720 filesz: > 0x0000000000001478 > Clearing Section: addr: 0x0000000007770130 memsz: 0x00000000000042a8 > Loading Section: addr: 0x0000000000091000 memsz: 0x0000000000000028 filesz: > 0x0000000000000028 > Loading Section: addr: 0x0000000000100000 memsz: 0x0000000000154660 filesz: > 0x0000000000154660 > 53:fill_inbuf() - nvram:0x00020000 block_count:1 [snip] > 53:fill_inbuf() - nvram:0x00160000 block_count:21 > Loading Section: addr: 0x0000000000000000 memsz: 0x0000000040000000 filesz: > 0x0000000000000018 > 53:fill_inbuf() - nvram:0x00170000 block_count:22 > 53:fill_inbuf() - nvram:0x00180000 block_count:23 > 53:fill_inbuf() - nvram:0x00190000 block_count:24 > 53:fill_inbuf() - nvram:0x001a0000 block_count:25 > 53:fill_inbuf() - nvram:0x001b0000 block_count:26 > 53:fill_inbuf() - nvram:0x001c0000 block_count:27 > 53:fill_inbuf() - nvram:0x001d0000 block_count:28 > > An it runs forever in loading the last section. My question is > where do .text .rodata and .data go ?? It seems only load .bss > .nokill and .kernel. And WTH is Does it actually terminate or is there an infinite loop in there? > Loading Section: addr: 0x000000000776ecb8 memsz: 0x0000000000005720 filesz: > 0x0000000000001478 I think I may need to improve my debugging messages a little bit. What is happening here is of of the ELF segments (possibly being split) would normally overwrite linuxBIOS. So it is temporarily loaded at the top of memory. At the very end of the process it will be copied back. > There is no section with 0x1478 nor 0x5720 in size. A couple of the sections probably run together into one ELF segment. Hmm. There is something else I can fix in my debug messages... So in summary. objdump -p elfImage shows the elf segments that are being loaded. There is not a 1-1 correspondence between the ELF sections and the ELF segments. Very large address (almost at the top of memory) are from segments that would have normally overwritten linuxBIOS but instead have been relocated to a linuxBIOS sized buffer at the top of memory. Later an assembly stub (in boot.c) copies the data over linuxBIOS. Eric
