public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] [PATCH] arm: arm926ejs: use ELF relocations
Date: Tue, 05 Oct 2010 00:57:02 +0200	[thread overview]
Message-ID: <4CAA5BBE.5010803@free.fr> (raw)
In-Reply-To: <AANLkTinCdLjkh56ZnF0Q-MFTHq=Jy+AHkS32UmmNUHwO@mail.gmail.com>

Le 05/10/2010 00:22, Graeme Russ a ?crit :
> On Tue, Oct 5, 2010 at 9:01 AM, Albert Aribaud<albert.aribaud@free.fr>  wrote:
>> This patch is *not* a submission for master!
>>
>> It is a proof of concept of ELF relocations for ARM, hastily done
>> in a day's work time for people on the list to try and to comment.
>> All comments are welcome, as several suggestions have been made
>> today on the list that I did not have time to incorporate, such as
>> rewriting the elf table fixup code in C.
>
> Yes, this would be nice. I imagine it would look somewhat like the version
> for x86. It would be nice to have a generic function which will work for
> all arches.
>
> [snip]
>
>> With GOT relocs:
>>
>>    text    data     bss     dec     hex filename        .bin size
>>   141376    4388   16640  162404   27a64 ./u-boot        145764
>>
>> With ELF relocs:
>>
>>    text    data     bss     dec     hex filename        .bin size
>>   149677    3727   16636  170040   29838 ./u-boot        153408
>
> Hmm, I'm a bit suprised by the text increase - Can you provide a more
> detailed breakdown of before and after sizes by section?

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 
108112. This is due to the fact that GOT relocation requires additional 
instruction for GOT indirection whereas ELF relocations work by patching 
the code.

- 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.

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.

> Regards,
>
> Graeme

Amicalement,
-- 
Albert.

  reply	other threads:[~2010-10-04 22:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-04 22:01 [U-Boot] [RFC] [PATCH] arm: arm926ejs: use ELF relocations Albert Aribaud
2010-10-04 22:09 ` Albert ARIBAUD
2010-10-04 23:57   ` John Rigby
2010-10-05  0:01     ` Graeme Russ
2010-10-05  5:34       ` Wolfgang Denk
2010-10-05  5:40         ` Graeme Russ
2010-10-05  5:42           ` Graeme Russ
2010-10-05  6:13             ` Albert ARIBAUD
2010-10-05  5:30   ` Wolfgang Denk
2010-10-05  5:41     ` J. William Campbell
2010-10-05  5:47     ` Albert ARIBAUD
2010-10-04 22:22 ` Graeme Russ
2010-10-04 22:57   ` Albert ARIBAUD [this message]
2010-10-04 23:21     ` Graeme Russ
2010-10-05  0:16       ` Albert ARIBAUD
2010-10-05  3:42         ` J. William Campbell
2010-10-04 23:23 ` Graeme Russ
2010-10-04 23:59   ` Albert ARIBAUD
2010-10-05  6:11 ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2010-10-05  6:13 Wolfgang Denk
2010-10-05  6:33 ` Albert ARIBAUD
2011-03-29 23:13 du zhigang
2011-03-30  5:06 ` Albert ARIBAUD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CAA5BBE.5010803@free.fr \
    --to=albert.aribaud@free.fr \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox