From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id C7337386197D; Thu, 15 Apr 2021 20:07:39 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C7337386197D
From: "swilde@sha-bang.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment:
 Permission denied on NetBSD 9.1
Date: Thu, 15 Apr 2021 20:07:39 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: jit
X-Bugzilla-Version: 10.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: swilde@sha-bang.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-100096-4-L1KYghiapD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-100096-4@http.gcc.gnu.org/bugzilla/>
References: <bug-100096-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2021 20:07:39 -0000

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

--- 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 em=
itted.
> > >=20
> > > 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 amoun=
t of
> > > logging (see
> > > https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-lo=
g-file)
> > >=20
> > > Can you attach the log you get please?
> >=20
> > With security.pax.mprotect.global=3D1 it produces no extra output.
> > I'll attach the output produced when security.pax.mprotect.global is
> > disabled.
>=20
> 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.
>=20
> 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=