https://sourceware.org/bugzilla/show_bug.cgi?id=20113
--- Comment #19 from Andreas Krebbel <krebbel at linux dot ibm.com> --- (In reply to maamountki from comment #18) > *patch > > I just noticed that SEPARATE_GOTPLT is duplicated in the 64 bit script and > partial relro support is already implemented so yes my patch should be > reverted, I'm contacting Bountysource to revert the claim submission too. > Anyway I'm not sure why you think that SEPARATE_GOTPLT must remain as 0 > hence the relro segment doesn't extend across those entries, SEPARATE_GOTPLT > have this argument for the exact reason and architectures such as x86 and > aarch64 take advantage of this feature and there is a reason actually there > are no harm in making those entries non-exploitable. For IBM Z we had to chose a slightly different scheme. Our ABI requires that *all* GOT entries (.got + .got.plt) are accessible via _GLOBAL_OFFSET_TABLE_ symbol and a *positive* displacement. Just setting SEPARATE_GOTPLT makes _GLOBAL_OFFSET_TABLE_ to point at the start of .got.plt which would come after the other .got entries. Hence a negative offset would be needed to address .got entries. More changes to the backend were required to make _GLOBAL_OFFSET_TABLE_ end up at the start of .got. As you say the value of SEPARATE_GOTPLT is used to make the relro segment cover the magic entries assumed to be located at start of .got.plt. With moving _GLOBAL_OFFSET_TABLE_ to start of .got I also had to move the 3 magic entries to the start of .got. So they will be covered by the relro segment anyway. Setting it to 0 is the right value for us then. I apologize for not monitoring the bugzilla and closing it after the relro work was finished. I know you are doing a great job for other of our bounties (e.g. OpenBlas). Please keep up your great work! -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils