On Tue, Oct 5, 2010 at 9:57 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Le 05/10/2010 00:22, Graeme Russ a écrit :
On Tue, Oct 5, 2010 at 9:01 AM, Albert Aribaudalbert.aribaud@free.fr wrote:
The output from MAKEALL is curiously calculated... If I look at objdumps of the GOT and ELF binaries, I find that:
- the GOT .text section is 118960 bytes and the ELF .text section only
- This is due to the fact that GOT relocation requires additional
instruction for GOT indirection whereas ELF relocations work by patching the code.
It would be interesting to compare against the basline non-relocatable version
- the .rodata section is 22416 for GOT, 22698 for ELF, whereas the .data
section is 2908 for GOT, 2627 for ELF. Some initialized data apparently moved from non-const ton const for some reason, but basically, initialized data remains constant.
- the .bss section remains constant too, 16640 for GOT vs. 16636 for ELF.
I'm not going to track what causes the 4 byte difference. :)
Many sections are output in the ELF file which do not appear in the GOT file, such as .interp, .dynamic, .dynstr etc. They probably pollute MAKEALL's figures.
I now discard a few sections:
/DISCARD/ : { *(.dynstr*) } /DISCARD/ : { *(.dynamic*) } /DISCARD/ : { *(.plt*) } /DISCARD/ : { *(.interp*) } /DISCARD/ : { *(.gnu*) }
Not that it makes a huge difference - most of these are trivially small
So actually the code (.text+.rodata+.data) is smaller for ELF than for GOT (which is normal as GOT causes adding indirection instructions whereas ELF does not alter the code size) but the .rel.dyn is way bigger than the .got (which is also normal as GOT does not relocate all that ELF does).
As I have mentioned before, x86 has an in-RAM increase of only 284 bytes (0.3 %) with an additional 22424 bytes in .rel.dyn
That's roughly consistent with the numbers I get: about 19 KB of .rel.dyn plus .dynsym, which we will be able to cut by half if we preprocess it.
Which is not copied to RAM, so not as nasty as the .got related increase
I'm also looking at moving the low-level intialisation and relocation code into a seperate section (outside .text) so I even less to relocate to RAM
Then I could even compress the relocatable section, but that is just being silly ;)
Regards,
Graeme