From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 25230 invoked from network); 16 Nov 2021 16:26:04 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 16 Nov 2021 16:26:04 -0000
Received: (qmail 1223 invoked by uid 550); 16 Nov 2021 16:26:02 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 1188 invoked from network); 16 Nov 2021 16:26:01 -0000
Date: Tue, 16 Nov 2021 11:25:49 -0500
From: Rich Felker <dalias@libc.org>
To: Dragan Mladjenovic <Dragan.Mladjenovic@syrmia.com>
Cc: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>, gcc-patches@gcc.gnu.org,
	Jeff Law <jeffreyalaw@gmail.com>, musl@lists.openwall.com
Message-ID: <20211116162549.GQ7074@brightrain.aerifal.cx>
References: <CALCv0x31=aZLuAE5e-_UR8pQZge9Tz5mwSxJJJ1JdQe6mxk5uA@mail.gmail.com>
 <20211116051323.4900-1-ilya.lipnitskiy@gmail.com>
 <7cfc5adb-64e8-7259-4c7e-26bb832cd00a@syrmia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7cfc5adb-64e8-7259-4c7e-26bb832cd00a@syrmia.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] Re: [PATCH v2] configure: define TARGET_LIBC_GNUSTACK on
 musl

On Tue, Nov 16, 2021 at 03:40:00PM +0100, Dragan Mladjenovic wrote:
> Hi,
> 
> Looks fine to me. If possible, maybe it should even be back-ported
> to stable branches.
> 
> Not sure if MIPS assembly sources (if any) in musl would need
> explicit ..note.GNU-stack
> 
> to complement this?

What are the actual consequences of making this change, and what is
the goal? I'm concerned that it might produce object files which don't
include annotation that they don't need executable stack, in which
case the final executable file will be marked as executable-stack and
the kernel will load it as such. That would be very bad.

Rich


> On 16-Nov-21 06:13, Ilya Lipnitskiy wrote:
> >musl only uses PT_GNU_STACK to set default thread stack size and has no
> >executable stack support[0], so there is no reason not to emit the
> >.note.GNU-stack section on musl builds.
> >
> >[0]: https://lore.kernel.org/all/20190423192534.GN23599@brightrain.aerifal.cx/T/#u
> >
> >gcc/ChangeLog:
> >
> >	* configure: Regenerate.
> >	* configure.ac: define TARGET_LIBC_GNUSTACK on musl
> >
> >Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
> >---
> >  gcc/configure    | 3 +++
> >  gcc/configure.ac | 3 +++
> >  2 files changed, 6 insertions(+)
> >
> >diff --git a/gcc/configure b/gcc/configure
> >index 74b9d9be4c85..7091a838aefa 100755
> >--- a/gcc/configure
> >+++ b/gcc/configure
> >@@ -31275,6 +31275,9 @@ fi
> >  # Check if the target LIBC handles PT_GNU_STACK.
> >  gcc_cv_libc_gnustack=unknown
> >  case "$target" in
> >+  mips*-*-linux-musl*)
> >+    gcc_cv_libc_gnustack=yes
> >+    ;;
> >    mips*-*-linux*)
> >  if test $glibc_version_major -gt 2 \
> >diff --git a/gcc/configure.ac b/gcc/configure.ac
> >index c9ee1fb8919e..8a2d34179a75 100644
> >--- a/gcc/configure.ac
> >+++ b/gcc/configure.ac
> >@@ -6961,6 +6961,9 @@ fi
> >  # Check if the target LIBC handles PT_GNU_STACK.
> >  gcc_cv_libc_gnustack=unknown
> >  case "$target" in
> >+  mips*-*-linux-musl*)
> >+    gcc_cv_libc_gnustack=yes
> >+    ;;
> >    mips*-*-linux*)
> >      GCC_GLIBC_VERSION_GTE_IFELSE([2], [31], [gcc_cv_libc_gnustack=yes], )
> >      ;;