From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mpc83xx: Add -fpic relocation support
Date: Tue, 12 Oct 2010 22:37:54 +0200 [thread overview]
Message-ID: <4CB4C722.8020905@free.fr> (raw)
In-Reply-To: <OF1DB03B74.12F6E672-ONC12577BA.006316CE-C12577BA.0063E566@transmode.se>
Le 12/10/2010 20:11, Joakim Tjernlund a ?crit :
>>
>> Le 12/10/2010 19:11, Joakim Tjernlund a ?crit :
>>
>>> Figured I should mention that I have added -msingle-pic-base(from ARM)
>>> which
>>> works nicely with -fpic(not sure if -fPIC is possible) and reduces
> size
>>> even more:
>>
>> Since you seem to be following the same path as I did on ARM, I may as
>> well ask: did you try removing -fPIC and -msingle-pic-base from compile
>> options and adding -pie to the link options instead?
>
> looked at it briefly but -pie is really massive. Each access needs
> a reloc entry, even if they access the same data.
OTOH, the accesses are as simple as without reloc, i.e. no indirection
as GOT introduces. What is the size of the .rel.dyn and .dynsym sections?
>> Link option -pie generates ELF relocation and, on ARM at least, does a
>> better job than GOT reloc, which does not fix handle pointers in
>> initialized data while ELF reloc fixes them.
>
> on ppc -mrelocatable does the job for you and adds fixup relocs.
> It a simple addon that should be fairly easy to add to other archs too.
It does not exist on ARM targets whereas -pie is general.
>> And since ELF reloc does not modify code (it is a linker option), you
>
> ehh, I think you need to reloc directly in the text segment.
I meant that it does not cause the compiler to generate a different
code, whereas GOT relocation generates a different code, which causes
the text section to grow.
>> end up with the same size for text+data+rodata. You do have a bigger
>> FLASH image though, because the ELF reloc tables are bigger than the GOT
>
>> table; but you can git rid of them / not copy them to RAM once
> relocated.
>
> I don't think RAM is as much as a problem as flash is.
Indeed in some cases it isnt; but you gain some boot time if you don't
have to copy the relocation table along with the code.
>> The move from -fPIC to ELF on ARM can be looked for in the elf_reloc
>> branch of the u-boot-arm repo.
>
> Yes, but I believe the ppc way is smaller once -fpic and -msingle-pic-base
> are used(In flash anyway).
> Also, I don't think you will be able to do true PIC in the
> future without PIC code.
Problem is, -fPIC / -fPIE (I tried both) is not really position
independent either, and requires ugly manual relocation. Besides, for
the moment, true position independence is not required, although I'd
like at least the u-boot FLASH startup code to be.
I do understand, though, that ppc and arm may not share a common optimal
relocation method.
Amicalement,
--
Albert.
next prev parent reply other threads:[~2010-10-12 20:37 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-12 12:38 [U-Boot] [PATCH] mpc83xx: Add -fpic relocation support Joakim Tjernlund
2010-10-12 12:52 ` Wolfgang Denk
2010-10-12 13:04 ` Joakim Tjernlund
2010-10-12 13:47 ` Wolfgang Denk
2010-10-12 14:10 ` Joakim Tjernlund
2010-10-12 17:31 ` Kim Phillips
2010-10-12 17:38 ` Scott Wood
2010-10-12 17:41 ` Joakim Tjernlund
2010-10-12 18:19 ` Kim Phillips
2010-10-12 18:25 ` Scott Wood
2010-10-12 18:38 ` Kim Phillips
2010-10-12 19:09 ` Joakim Tjernlund
2010-10-12 19:17 ` Joakim Tjernlund
2010-10-12 19:54 ` Kim Phillips
2010-10-12 21:23 ` Joakim Tjernlund
2010-10-12 21:30 ` Scott Wood
2010-10-13 9:44 ` Joakim Tjernlund
2010-10-12 19:13 ` Joakim Tjernlund
2010-10-12 19:20 ` Scott Wood
2010-10-12 19:51 ` Joakim Tjernlund
2010-10-12 20:16 ` Scott Wood
2010-10-12 20:40 ` Joakim Tjernlund
2010-10-12 20:48 ` Scott Wood
2010-10-12 21:06 ` Joakim Tjernlund
2010-10-12 15:52 ` Scott Wood
2010-10-12 17:11 ` Joakim Tjernlund
2010-10-12 17:41 ` Albert ARIBAUD
2010-10-12 18:11 ` Joakim Tjernlund
2010-10-12 20:37 ` Albert ARIBAUD [this message]
2010-10-12 21:00 ` Joakim Tjernlund
2010-10-13 6:30 ` Albert ARIBAUD
2010-10-13 7:07 ` Joakim Tjernlund
2010-10-13 9:05 ` Albert ARIBAUD
2010-10-13 9:34 ` Joakim Tjernlund
2010-10-13 21:25 ` Joakim Tjernlund
2010-10-14 6:25 ` Albert ARIBAUD
2010-10-13 7:21 ` J. William Campbell
2010-10-13 8:37 ` Joakim Tjernlund
2010-10-12 17:37 ` Wolfgang Denk
2010-10-13 9:41 ` [U-Boot] [PATCHv2] " Joakim Tjernlund
2010-10-13 21:11 ` [U-Boot] [PATCHv3] " Joakim Tjernlund
2010-10-20 6:32 ` Joakim Tjernlund
2010-10-28 8:46 ` Joakim Tjernlund
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=4CB4C722.8020905@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