Eric W. Biederman wrote:
> 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.
>
OOPS,
ollie mkelfImage 70:objdump -p elfImage
elfImage: file format elf32-i386
Program Header:
LOAD off 0x00001000 vaddr 0x00010000 paddr 0x00010000 align 2**12
filesz 0x00001478 memsz 0x00005720 flags rwx
LOAD off 0x00003000 vaddr 0x00091000 paddr 0x00091000 align 2**12
filesz 0x00000028 memsz 0x00000028 flags rwx
LOAD off 0x00004000 vaddr 0x00100000 paddr 0x00100000 align 2**12
filesz 0x00154660 memsz 0x00154660 flags rw-
Still no section as
Loading Section: addr: 0x0000000000000000 memsz: 0x0000000040000000
filesz: 0x0000000000000018
Ollie
