On Tue, Apr 19, 2011 at 01:33:12PM -0400, Nicolas Pitre wrote:
On Wed, 20 Apr 2011, Shawn Guo wrote:
On Tue, Apr 19, 2011 at 04:23:09PM +0100, Dave Martin wrote:
Hopefully this explains what's going on, but what are you trying to achieve exactly?
Thanks a ton, Dave. It does explain what I'm seeing, and your explanation looks like a very good learning material.
I'm running into a problem with John Bonies' append-dtb-to-zImage patch. That is the header of dtb was overwritten by uart_base value. John's patch did fix up .bss entries in .got to move them behind dtb image. But as you explained, when uart_base is defined as static one, its address is fixed up in pc-relative way at link time, and John's patch does not help it, hence the write to uart_base at runtime overwrites dtb image.
What do you think is the right fix to this problem? Forbid the use of static uninitialized variable? I'm afraid not. Is it possible to fix up the cases like uart_base here at runtime?
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.
We might be able to reduce the size of the GOT by building with -fvisibility=hidden, and making judicious use of "extern" on all data declarations/definitions:
[gcc-4.4.info] `extern' declarations are not affected by `-fvisibility', so a lot of code can be recompiled with `-fvisibility=hidden' with no modifications. However, this means that calls to `extern' functions with no explicit visibility will use the PLT, so it is more effective to use `__attribute ((visibility))' and/or `#pragma GCC visibility' to tell the compiler which `extern' declarations should be treated as hidden.
This only seems to work reliably for data definitions; plus the toolchain behaviour may "evolve" with respect to obscure features like this. So if we wanted to achieve such a thing reliably, we'd probably need explicit visibility attributes on the affected declarations.
The advantage is unlikely to be huge though since the GOT is small anyway; and we wouldn't be able to throw away the GOT relocation code completely, beacuse of the need to relocate bss references...
Cheers ---Dave