[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

["swilde@sha-bang.de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096

--- Comment #17 from Sascha Wilde <swilde@sha-bang.de> ---
(In reply to David Malcolm from comment #16)
> (In reply to Sascha Wilde from comment #10)
> > (In reply to David Malcolm from comment #8)
> > > It would be good to know exactly where that error message is being emitted.
> > > 
> > > If you add:
> > >   gcc_jit_context_set_logfile (ctxt, stderr, 0, 0);
> > > to the test code (e.g. immediately after the call to
> > > gcc_jit_context_acquire), libgccjit ought to spew out a copious amount of
> > > logging (see
> > > https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file)
> > > 
> > > Can you attach the log you get please?
> > 
> > With security.pax.mprotect.global=1 it produces no extra output.
> > I'll attach the output produced when security.pax.mprotect.global is
> > disabled.
> 
> Thanks!  I was wondering if the error message was:
>   (a) due to a problem dynamically linking libgccjit into the process, or
>   (b) a later problem with linking the code that libgccjit generates into
> the process.
> 
> Given that there's no extra log output at all with the protection flag, it
> sounds like it's (a) - though you may run into a similar problem with (b)
> if/when (a) gets solved.

FWIW, the reason why I stumbled upon this problem is that I am testing
the native compiling GNU Emacs branch[0] on the NetBSD system.
(Which, by the way, can be build and works great once
security.pax.mprotect.global is disabled)

When security.pax.mprotect.global is enable the Emacs, linked with
libgccjit can not be started at all, failing with the same error as
the hello-world example.  So this matches your analysis that the
problem is triggered by dynamically linking libgccjit.

[0] https://akrl.sdf.org/gccemacs.html