[m-dev.] test server
Peter Wang
novalazy at gmail.com
Thu Apr 3 12:52:02 AEDT 2025
On Wed, 02 Apr 2025 17:24:32 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>
>
> On Mon, 31 Mar 2025 14:15:26 +1100, Peter Wang <novalazy at gmail.com> wrote:
>
> > On Mon, 31 Mar 2025 12:42:29 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > >
> > > I note that there seems to be an issue with a warning from
> > > compiling Boehm gc. Does anyone know the root cause for that is?
> >
> > The full warning message is:
> >
> > /usr/bin/ld: warning: atomic_ops_sysdeps.o: missing .note.GNU-stack section implies executable stack
> > /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
> >
> > It seems that old versions of GNU ld defaulted to an executable stack,
> > while newer versions of GNU ld warn about depending on that default.
> > To suppress the warning, we would pass -z noexecstack to the linker at
> > the correct places, but I haven't tried it yet.
>
> The file boehm_gc/libatomic_ops/src/atomic_ops_sysdeps.S, which in my workspace
> is the only possible source for the .o file the linker is complaining about, is effectively
> an empty file on non-SPARC systems, i.e. on all the systems that we use, AFAIK.
> Instead of telling ld to use an executable stack, we could
>
"-z noexecstack" would tell ld to NOT allow an executable stack.
Also, atomic_ops_sysdeps.S should only be required on Solaris/SPARC
if using a compiler other than GCC (see where "need_atomic_ops_asm=true"
is set in boehm_gc/configure.ac).
> - add the missing .note.GNU-stack section to atomic_ops_sysdeps.S,
> provided Boehm does not actually need executable stacks on SPARCs
> (which I think is likely),
>
> - if Boehm does need executable stacks on SPARCs, we could add a
> dummy definition to a new else arm of the #ifdef in that file,
> which should fix the issue on non-SPARC systems if the only reason
> for the warning is that ld is complaining about the *empty* .o file
> missing that section, or
>
> - we could modify the makefile to include atomic_ops_sysdeps.S among
> the list of source modules only if the condition of the #ifdef is true.
> There is already a flag for that, NEED_ASM, but I don't see why its value
> calls for the inclusion of atomic_ops_sysdeps.S; configure.ac should set it
> only on Solaris hosts. But then, I have never used automake, so my reading
> of Makefile.am is superficial.
We don't run boehm_gc or libatomic_ops's configure scripts,
or use any automake generated makefiles.
We build boehm_gc using boehm_gc/Makefile.direct, which currently
includes atomic_ops_sysdeps.o in the OBJS list unconditionally.
I see a few options:
1. Filter out the warning from ld in our test setup. The warning will
go away eventually. I've checked that Mercury binaries produced on
various Linux distributions are not requiring executable stacks,
so I don't think that's actually an issue.
2. Delete atomic_ops_sysdeps.o from OBJS in our fork of bdwgc.
This might break builds for Solaris/SPARC with non-GCC compilers,
if they were working at all. I expect we will hear zero complaints
about it.
3. Introduce a variable in Makefile.direct in our fork of bdwgc
that controls whether to include atomic_ops_sysdeps.o in OBJS,
then make Mercury's configure script set that variable as required.
Option 3 shouldn't be much harder than 2, but we won't be able to test
it properly.
Peter
More information about the developers
mailing list