On Mon, Jul 10, 2017 at 6:29 AM, Nick Alcock wrote: > On 10 Jul 2017, H. J. Lu said: >> On Mon, Jul 10, 2017 at 11:50:02AM +0100, Nick Alcock wrote: >>> If it passes a test build with --enable-stack-protector=all without >>> pulling junk into ld.so and exploding at ld.so link time, sure. (That's >>> what happened every time I tried to remove this stuff before, but I may >>> have failed to notice that this may not be necessary any more.) >> >> Here is the updated patch. tst-_dl_addr_inside_object should be >> linked with $(dummy-stack-chk-fail). Otherwise, __stack_chk_fail is >> undefined. OK for master branch? > > I presume this is because it's in $(all-nonlib)? Are other all-nonlib > things similarly affected? (If they are, is the code in Makerules > perhaps a better place to adjust this?) > > I guess the only affected nonlib things would be things that directly > link against objects that will otherwise end up in the shared libc or > ld.so, which means this is the only affected test (since only those > things reference the usually-hidden __stack_chk_fail). If so, I have no > objection to this patch, but maybe a comment explaining this would be a > good idea so that if more such tests turn up in future this unusual > piece of linking can be generalized a bit. > > Modulo that, I have no objections, but of course I also have no actual > right to ack anything whatsoever :) > >>> > -/* On some architectures, this helps needless PIC pointer setup >>> > - that would be needed just for the __stack_chk_fail call. */ >>> >>> Does anyone know what architectures these might be? Presumably x86-32... >>> >> >> config/i386/i386.c: __stack_chk_fail_local hidden function instead of calling > > I presume you tested a build on x86-32 :) I guess that will suffice... We must keep debug/stack_chk_fail_local.c for libc_nonshared.a. Here is the updated patch to add __stack_chk_fail_local alias only to libc.so. Tested on i686 and x86-64 with and without --enable-stack-protector=all. OK for master? -- H.J.