On Wed, 20 Apr 2011, Dave Martin wrote:
Hi,
On Wed, Apr 20, 2011 at 1:42 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Wed, 20 Apr 2011, Dave Martin wrote:
On Tue, Apr 19, 2011 at 01:33:12PM -0400, Nicolas Pitre wrote:
You must not use static variable in the decompressor. For one thing, that breaks the ability to XIP the decompressor code and move writable data elsewhere.
So the fix is indeed to _not_ declare any global variable as static in this case.
After some thinking about this, I think I agree.
Having to relocate a GOT-full of addresses many of which are actually at fixed PC-relative offsets just for this capability is a bit annoying, but the GNU tools don't support other models very well.
You cannot relocate PC-relative offsets at run time. Those references are spread throughout the code into literal pools. Forcing all references to go through the GOT makes it possible for the code to relocate selected parts of itself at run time.
My point was that relocatability implies overhead, and the GOT potentially contains a load of relocations for code and read-only data which will never get moved in practice.
Sure, for code (already implicit) or ro data, using GOTOFF relocs is perfectly fine. As long as the relevant data is marked const then there is no issue also marking it static, at which point the same effect as -fvisibility=hidden is achieved i.e. no GOT entries are allocated.
For writable/uninitialised data, it's different of course -- we often will need to relocate that in real situations (as observed here). I'd guessed that only part of the GOT in the compressed loader was addressing such data, but actually, it seems to be pretty much all of it, as you suggest.
Yes, and in practice it contains only between 6 and 8 entries depending on the config used. And all of them are references to .bss variables. So the overhead is pretty small.
Nicolas