| Message ID | 20211116051323.4900-1-ilya.lipnitskiy@gmail.com |
|---|---|
| State | New |
| Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8B8993864802 for <patchwork@sourceware.org>; Tue, 16 Nov 2021 05:14:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8B8993864802 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1637039682; bh=iY1LnXV2Fm/b39gSJk1lYlye9km7UyS5AbF0mNqA1tY=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=OSzajcFJ4bAF4t2eNVOGl1XMX1k5vFy7B95g6ViwgwHANYzS1fvXtfLktoOczoaAm cv8KdpZFyAq0GT85aPOiLBGd5j3C5GIYlPda1I6eNQSw8uKUzvy1Y5PrlN7Qboy6Fg fy5UDzs7fmjN1Ydwv8Ox/omkm7TG8MWW9EFrCBxQ= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 20C793857C63 for <gcc-patches@gcc.gnu.org>; Tue, 16 Nov 2021 05:13:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 20C793857C63 Received: by mail-pl1-x629.google.com with SMTP id b11so16323790pld.12 for <gcc-patches@gcc.gnu.org>; Mon, 15 Nov 2021 21:13:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=iY1LnXV2Fm/b39gSJk1lYlye9km7UyS5AbF0mNqA1tY=; b=mhk/yk4wv3bYhLE1B4HgXF30ckF/lr6RTGqVIgVBIFFCYrULY9JGj7XzrYgEX+lD0Y XII4RuKWbi/H6N92xmWL7Ko7Ek7y9HfGv3TIBml5fuak4SGH1XtvrHkp8KezoGV3IKVc G3ZH2nKJxPZE6nHfhShAG3FCBDKp2vjjbhs1ykpLObCGzxSykZnzlGOReW1+Zr0FMUj7 EMMgVigtcCYhTo/MRIpIGAAqxu+RPkO7/44HbYqj3nYAvgOXVZ5Xj8z5LyeVOWrjR8mr KGuB6ruV+7EGmJkpVjkl+TvPZzq8pld9cnCyKXF+a2q54vCRBAvwXHkuP1I+fhQw9Dj5 AbRA== X-Gm-Message-State: AOAM530CnveoAV8vKHWXhiXFXukwhx21KwcelOYCa4jRJtroEP9pBHuy KuZVBUWbLvvaTr+CJ5DMAKablTieM08= X-Google-Smtp-Source: ABdhPJxhppOxFMSPZXtismdV7AsOo0vqDYQ0tpIvq0J9WaBPudz0j2Om9OAtN7pHB6u4dTiEEb3bDA== X-Received: by 2002:a17:902:b718:b0:143:72b7:409e with SMTP id d24-20020a170902b71800b0014372b7409emr41904773pls.28.1637039627081; Mon, 15 Nov 2021 21:13:47 -0800 (PST) Received: from z640-arch.lan ([2602:61:73aa:e00::9d4]) by smtp.gmail.com with ESMTPSA id c9sm13049417pgq.58.2021.11.15.21.13.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 21:13:46 -0800 (PST) To: gcc-patches@gcc.gnu.org, Dragan Mladjenovic <Dragan.Mladjenovic@syrmia.com>, Jeff Law <jeffreyalaw@gmail.com> Subject: [PATCH v2] configure: define TARGET_LIBC_GNUSTACK on musl Date: Mon, 15 Nov 2021 21:13:24 -0800 Message-Id: <20211116051323.4900-1-ilya.lipnitskiy@gmail.com> X-Mailer: git-send-email 2.33.1 In-Reply-To: <CALCv0x31=aZLuAE5e-_UR8pQZge9Tz5mwSxJJJ1JdQe6mxk5uA@mail.gmail.com> References: <CALCv0x31=aZLuAE5e-_UR8pQZge9Tz5mwSxJJJ1JdQe6mxk5uA@mail.gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Ilya Lipnitskiy via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com> Cc: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
| Series |
[v2] configure: define TARGET_LIBC_GNUSTACK on musl
|
|
Commit Message
Ilya Lipnitskiy
Nov. 16, 2021, 5:13 a.m. UTC
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(+)
Comments
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? Best regards, Dragan 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], ) > ;;
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], ) > > ;;
On Tue, Nov 16, 2021 at 8:41 AM Rich Felker <dalias@libc.org> wrote: > > 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. The change cherry-picks fine onto 10.x and 11.x branches. Should I send out separate patches or can the committer of this patch apply it to 10.x and 11.x? > > > > 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. It is actually the other way around - for MIPS hard-float targets on non-glibc (or glibc < 2.31) without this change the .note.GNU-stack annotation is not emitted by GCC. Ilya > > 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], ) > > > ;;
On 11/15/2021 10:13 PM, 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 Thanks. I've pushed this to the trunk. Sorry for the long wait. Jeff
On Thu, Dec 2, 2021 at 12:48 PM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > On 11/15/2021 10:13 PM, 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 > Thanks. I've pushed this to the trunk. Sorry for the long wait. No worries, and thank you! How about 10.x and 11.x branches, do you think it should get picked into those since this change is effectively a follow-up to https://gcc.gnu.org/g:54b3d52c3 ? Please also update https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103470 I created to track this fix. Ilya
On 12/2/2021 1:59 PM, Ilya Lipnitskiy wrote: > On Thu, Dec 2, 2021 at 12:48 PM Jeff Law <jeffreyalaw@gmail.com> wrote: >> >> >> On 11/15/2021 10:13 PM, 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 >> Thanks. I've pushed this to the trunk. Sorry for the long wait. > No worries, and thank you! How about 10.x and 11.x branches, do you > think it should get picked into those since this change is effectively > a follow-up to https://gcc.gnu.org/g:54b3d52c3 ? Please also update > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103470 I created to track > this fix. I wasn't planning to backport it. I'd leave that decision up to the release managers. jeff
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], ) ;;