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

[Clément Chigot]

Hi Alan

On Fri, May 20, 2022 at 8:45 AM Alan Modra <amodra@gmail.com> wrote:
>
> 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)

Thanks for handling this patch.

However, the testsuite changes look mandatory to me.
As of now, the results are different dependending on the
configure options being passed.
If the warnings are disabled, ld/29072 will always fail.
If the warnings are forced, stack exec will fail too.

I agree that forcing --warn-execstack might not be the
right approach.
Maybe disabling the problematic tests and creating
new ones: tests that are run only when a given
configure option is set, would be better. That way
we can also check that the behavior of each configure
choice is preserved.

Clément