Dear John Rigby,
In message AANLkTin+NyvQr6hnDOt82WzwSwM+4Tw+h+Py5Rt1Xh6D@mail.gmail.com you wrote:
The part that does not work is that some veneer routines do not get fixed up.
These veneer routines seem to be specific to some (pretty recent?) tool chain versions. We haven't seen any of these with older tool chains (say, up to and including gcc 4.2.x).
Can anybody shed some light on 1) when these routines have been introduced and 2) what their exact function is?
Is the specific tool chain in question available somewhere for testing?
When u-boot copies itself to ram it relocates the jump tables it knows about and could relocate the addresses in the veneer routines if it knew about them.
The relocation performed by U-Boot is based on the fact that we compile the code with -fPIC and then rely on entries in the GOT to apply the relocation offset to the addresses registered there.
It seems these veneer routines have not been entered into the GOT.
Note: it would be helpfup if somebody could verify this.
If so, the question is if there is a problem with handling -fPIC code?
There are at least three possible ways to fix these:
- u-boot has its own private libgcc and if I use it the problem goes away.
In U-Boot we consider this always as a last resort workaround for broken tool chains. We prefer to see the problems fixed at the cause - either in U-Boot or in the tool chain, wherever the problem may be.
- is there an option for the toolchain to use an arm libgcc instead of thumb?
I cannot comment on that. I don't even know which tool chain was used, or which versions of gcc and binutils.
- is there a way to find the veneers at runtime and fix them up?
The problem should go away automatically when the addresses of these routines somehow make their way into the GOT.
Best regards,
Wolfgang Denk