quoted

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.

quoted

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