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