[PATCH] ld: harmonize the value of --enable-warn-execstack=no option

Alan Modra amodra@gmail.com
Fri May 20 06:45:26 GMT 2022


On Fri, May 20, 2022 at 03:24:23PM +0930, Alan Modra wrote:
> On Tue, May 17, 2022 at 02:51:40PM +0200, Clément Chigot via Binutils wrote:
> > This patch sets the configure value of warn-execstack to 2 when
> > disabled as expected by bfd.
> > 
> > ld/ChangeLog:
> > 
> >         * configure.ac: Update ac_default_ld_warn_execstack value when
> >         --enable-warn-execstack=no is given.
> >         * configure: Regenerate
> >         * testsuite/ld-elf/elf.exp: Add --warn-execstack to ensure
> >         the warning is always shown.
> 
> Thanks for the patch, but I'm suspicious of the testsuite change and I
> think we need a little more here.  I agree a change is needed to make
> ld/bfd values consistent but I'm going to jump the other way, changing
> link_info.warn_execstack.  Making it consistent that way is nicer in
> that the flag becomes an "extended" boolean, ie. 0 => don't warn,
> 1 => always warn, 2 or 3 => conditional warning depending on
> link_info.execstack.
> 
> Testing still in progress, I'll commit this shortly if I don't
> discover the need for a testsuite change.

So my patch results in 
aarch64_be-linux-gnu_ilp32  +FAIL: PR ld/29072 (warn about an executable .note.GNU-stack)
aarch64-linux  +FAIL: PR ld/29072 (warn about an executable .note.GNU-stack)
armeb-linuxeabi  +FAIL: PR ld/29072 (warn about an executable .note.GNU-stack)
arm-linuxeabi  +FAIL: PR ld/29072 (warn about an executable .note.GNU-stack)
arm-nacl  +FAIL: PR ld/29072 (warn about an executable .note.GNU-stack)

That's really an arm/aarch64 backend problem in that those targets
define a gld${EMULATION_NAME}_before_parse function that overrides the
one in elf.em.  So at the moment it looks like
DEFAULT_LD_Z_SEPARATE_CODE, DEFAULT_LD_WARN_EXECSTACK,
DEFAULT_LD_WARN_RWX_SEGMENTS and DEFAULT_LD_EXECSTACK all do nothing
on arm/aarch64.  The obvious fix would be to add a few lines to the
arm/aarch64 before_parse functions but I'm going to leave that to an
ARM maintainer.  A more elegant solution might be possible.

I'm going to ignore buildbots or user complaints that this change of
mine introduced regressions as the truth is the new failure exposes
a real bug in arm/aarch64.  Committed.

-- 
Alan Modra
Australia Development Lab, IBM


More information about the Binutils mailing list