On 1/31/06, Olwe Bottorff <galanolwe at yahoo.com> wrote:

> $ size hello_world-1 hello_world-1.o
>    text   data   bss    dec   hex   filename
>     916    256     4   1176   498   hello_world-1
>      48      0     0     48    30   hello_world-1.o
>
> $ objdump -h hello_world-1.o
>
>    hello_world-1.o:     file format elf32-i386
>
>    Sections:
>    Idx Name          Size      VMA       LMA
> File off  Algn
>      0 .text         00000023  00000000  00000000
> 00000034  2**2
>                      CONTENTS, ALLOC, LOAD, RELOC,
> READONLY, CODE
>      1 .data         00000000  00000000  00000000
> 00000058  2**2
>                      CONTENTS, ALLOC, LOAD, DATA
>      2 .bss          00000000  00000000  00000000
> 00000058  2**2
>                      ALLOC
>      3 .rodata       0000000d  00000000  00000000
> 00000058  2**0
>                      CONTENTS, ALLOC, LOAD, READONLY,
> DATA
>      4 .note.GNU-stack 00000000  00000000  00000000
> 00000065  2**0
>                      CONTENTS, READONLY
>      5 .comment      0000001b  00000000  00000000
> 00000065  2**0
>                      CONTENTS, READONLY
>
>
> You see that objdump object file says text is size 23,
> while size says it's 48. There's a 25 byte
> discrepency. Why? It seems to be the exact size of the
> entire printf... line in the code (plus a \0?). Any ideas?


size is listing the text size in base 10.  objdump is listing it in base
16.  Also objdump is using more finely grained categories. So the 48 bytes
of text in size have become 0x23 bytes in .text and 0xd bytes in .rodata,
which conveniently enough, adds up to 0x30 hex, which is 48 bytes.  Someone
that knows more about it/has had to care at some point, can explain why the
size/bytes are where they are according to size and objdump.

leif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20060131/38fa9e1c/attachment-0001.htm