On Tuesday 9. January 2018 18.28.52 James Cowgill wrote:
>
> Thanks for this. I think I know what's going on now.
Thanks for replying and figuring it out from my notes!
[...]
> The problem here is that the assembler and GCC don't agree on whether
> thread2 is a global or local symbol. In GCC you have declared it
> non-static so it thinks it's a global symbol. In the assembler, all
> symbols default to local unless you say otherwise with a .global
> directive. This means that GCC only inserts a GOT16 relocation (no LO16)
> at the call sites of thread2. When the assembler looks at this, it sees
> that thread2 is a local symbol and therefore inserts a GOT16 relocation
> to the .text section in the object file (expecting a LO16 to later fix
> it up). Since there is no LO16 relocation, the linker rightfully
> complains.
>
> I guess you could add ".global thread2" to fix this, although I really
> don't know why you can't use C to implement L4UTIL_THREAD_STATIC_FUNC.
> Maybe there's some dark magic going on somewhere in L4re?
As I noted, I think it is perhaps done to avoid generating a few more
instructions. However, as shown, it is certainly possible to generate
something reasonable using a C-level function. And as far as I know, it would
be preferable to do everything in C as well.
Using ".global thread2" suppresses the error, confirming your suspicions. It
seems that ".internal thread2" is superfluous, at least from the output of
"readelf -s" on the object both with and without it used in the assembly
language portion:
30: 00000000 0 FUNC GLOBAL INTERNAL 1 thread2
I'll let the L4Re developers know about this and try and figure out what the
reasoning for changing this might have been. As far as I know, this code was
tested with the Imagination compilers (which also differed in behaviour in
other ways from GCC), so perhaps they have something to do with this code
being introduced.
Thanks once again for looking at this!
Paul
