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
_______________________________________________
linaro-toolchain mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
