> Date: Tue, 18 Aug 2015 06:58:43 -0400 > From: David Higgs <hig...@gmail.com> > > On Tue, Aug 18, 2015 at 6:22 AM, Mark Kettenis <mark.kette...@xs4all.nl> > wrote: > > > > Date: Tue, 18 Aug 2015 05:03:19 +0000 > > > From: Miod Vallat <m...@online.fr> > > > > > > > I spent some time today figuting out why the binutils update broke ld > > > > -Z on powerpc. Turns out to be a fairly thorny issue. > > > > > > > > The new binutils discard empty setions. As a result the .gotpad0 and > > > > .gotpad1 sections have disappeared. And a s a consequence the > > > > __got_start and __got_end symbols are now "absolute" symbols as the > > > > section they referenced to is no longer there. For example, an older > > > > libc has: > > > > > > > > 845: 000eeb68 0 NOTYPE GLOBAL DEFAULT 17 __got_start > > > > > > > > whereas -current has: > > > > > > > > 810: 000eeb58 0 NOTYPE GLOBAL DEFAULT ABS __got_start > > > > > > > > On powerpc, crt0.o has weak references to __got_start and __got_end. > > > > When building a binary with ld -Z, these are resolved to the absolute > > > > symbols from libc. At runtime we then use these values, relocated as > > > > if they were addresses within the binary itself, to change protections > > > > and flush the instruction cache. This is very likely to result in a > > > > segmentation fault. > > > > > > > > There is probably a linker bug here, as it doesn't make any sense for > > > > the linker to pick the address of these symbols from libc and stick it > > > > into the binary. But I'm not sure about this. And it isn't all that > > > > obvious what the fix would be. Is the bug that the symbols end up as > > > > absolute? Or is the problem that it sibsequently resolves these to > > > > the values from libc.so? > > > > > > Wouldn't something like that address the problem better? > > > > Unfortunately not. Using PROVIDE() makes the __got_start/end symbols > > disappear from shared libraries. If I use: > > > > GOTSTART="__got_start = .;" > > > > I end up with the same "absolute" symbols as before. You really have > > to tie the symbols to a specific section that isn't discarded to make > > them end up as "normal" symbols. And that is difficult since we try > > to make __got_start/end cover multiple sections, some of which may or > > may not be present. > > > > I still think my diff to remove code is the way to go. As I > > explained, it isn't really clear which set of symbols the references > > in crt0.o will actually resolve to. And the secure-plt work will > > require changes to the code anyway to make sure we don't end up with > > an executable GOT after all. > > > Would KEEP statements in a linker script be a suitable workaround? > > https://sourceware.org/binutils/docs/ld/Input-Section-Keep.html#Input-Section-Keep
No that doesn't work, presumably because .gotpad0 and .gotpad1 aren't really input sections.
