Mohan Kumar M writes: > 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. > 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. Paul. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
