Re: [PATCH] Fix the ld flags not be applied to tst-execstack-mod.so

[Vineet Gupta <Vineet dot Gupta1 at synopsys dot com>]

On 07/25/2018 01:22 PM, Joseph Myers wrote:
> On Wed, 25 Jul 2018, Vineet Gupta wrote:
>
>> Chiming in as I'm looking into these things myself in context of testing 
>> for ARC port submission. Do we really need to fix this part - in this 
>> way. I'd vote to not force the execstack through linker and rely on gcc 
>> generating this itself when it knows it doing something for trampolines. 
>> And only if target gcc doesn't support it (detected via configure test) 
>> should this be done.
> The whole point of this test is to verify executable stack changes on 
> dlopen of a module requiring an executable stack.

I'm not contesting that at all. For this exact test, I recently had to fix a
kernel bug for allowing mprotect(PROT_EXEC) stack mappings on ARC.

>   Thus, for this test to 
> work correctly, this module must be forced to have a marking as needing an 
> executable stack.

But given the dso code has nested function, a well equipped gcc when generating
trampoline code would also generate the GNU_STACK segment for the dso
automatically, without need to force the same via the linker flags as is done in
the Makefile currently. Only when a port's gcc doesn't support this (ARC gcc
didn't until recently), should we need ld assist, and this could be detected using
a configure test - No ?