[RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros

[Segher Boessenkool]

>> All of the variables references through @got translated into 
>> relocation
>> type R_PPC64_GOT16_DS entries. All these entries correspond to one of
>> the above entries in the .got section. But none of the entries in .got
>> section are relocated.
>
> If that last statement is really true, then that would be an absolute
> show-stopper, since you're not going to stop the compiler generating
> loads from the TOC to get addresses of things.
>
> However, I don't think it's true.  I compiled up a kernel using
> --emit-relocs on the final link, and with readelf -e I can see a
> .rela.got section containing a bunch of R_PPC64_ADDR64 relocs for
> entries in the .got section.
>
> So the problem appears to be either just that you are ignoring
> R_PPC64_ADDR64 relocs, or else that your relocs.c program has a bug
> and isn't seeing the .rela.got section.

I analysed this further.

.rela.got does have lots of relocs in it, but _not_ for relocations
create with @got in the assembler code.  GCC never does this AFAICS,
it explicitly creates a TOC entry and uses that.

So, the workaround would be to manually create TOC entries in the
LOAD_REG_ADDR code as well.  I'll work on that, feel free to beat me
to it of course.

>> Now I have two options left:
>> 1. Check for R_PPC64_GOT16_DS entries and check whether the contents
>> addressed by r2+offset is relocated or not and apply relocation if 
>> its not.
>> 2. Change all LOAD_REG_ADDR macros to LOAD_REG_IMMEDIATE. This I have
>> already done.
>
> I was trying to point out that this can't possibly be a viable
> solution to the problem, because most of the TOC loads in the binary
> are generated by the C compiler, and only a few of them come from use
> of the LOAD_REG_ADDR macro in assembly code.

binutils has a problem only with the @gotXXX relocations, where the
_linker_ creates the GOT entry (it doesn't emit a reloc for -emit-relocs
in that case).


Segher