| Message ID | 87a4vtdx13.fsf@phoenix-rtos.com |
|---|---|
| State | New |
| Headers |
Return-Path: <binutils-bounces~patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id BF8BA4BA23D1 for <patchwork@sourceware.org>; Fri, 27 Mar 2026 17:04:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF8BA4BA23D1 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=phoenix-rtos.com header.i=@phoenix-rtos.com header.a=rsa-sha256 header.s=google header.b=UKW3Vp8T X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id BBAD74BA2E0D for <binutils@sourceware.org>; Fri, 27 Mar 2026 17:04:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BBAD74BA2E0D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=phoenix-rtos.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=phoenix-rtos.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BBAD74BA2E0D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::229 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1774631053; cv=none; b=VHqmU2Q0JgmKhtw2CsDV4+ymkf1k5DOIl6OqRMMFo7aI+sRLAl1phT9Q7QBWENSptIJivOd0hmvvsTKcRfaKIIpNu1ms5E88q9hAE0zw0/5OdLBGd/9iFjCqSb+i+S9VbSS34sFeOpYOgfDxezPuXoadgZDPJBGweXOZ9mtfJL4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1774631053; c=relaxed/simple; bh=1LQi6ipHLvpOv0coxJKK/wOcFyBh5UAT9JkjeO355kU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=E9gDqPJD5mtZyM/Vc5NjitMhdnF7Qcrz3RJtnJEkVgqGUo404SRLj+IuSZbGm1un1eAQ46A3lH4wRmuV3aB5Z7T2B8yHQ8Yx8FksqdYCPKKnUlDWFmXsA5zoa8T9Z24rsTmMaqiiVZrFZAxnO9RcrLZ0djVrO7xeRTaWQyB23E4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BBAD74BA2E0D Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-38a42a0d7f7so28823501fa.1 for <binutils@sourceware.org>; Fri, 27 Mar 2026 10:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=phoenix-rtos.com; s=google; t=1774631051; x=1775235851; darn=sourceware.org; h=mime-version:message-id:date:user-agent:subject:to:from:from:to:cc :subject:date:message-id:reply-to; bh=KED/jrCvE0r+8txrYgTNPSKkJhFGgZb6YkrCHOeobzc=; b=UKW3Vp8T7G/tD7kB5XK1AP79VKGgtMgiB1fYPYJqcX6csmwF/VGE1QZEo3Izb7Izx4 1p7NTKqiwCIit4GMLZWZ7wIiHio5QoKDwwRgBG+yYp3ctVeZHdLyzLxSUdTQvTl1+HtK llHmEltsEmpwfvLAiD3xdaDQoiPDSfBm33/cjD1zzAjcAPqiwsnA8iR30fiDAmX3Cok6 xkooFHbOLRjUQ8kTcPgpYvLzHyNAzpbpjnSIvmNEukfPfSr4xU4tN9WeTSIGPmzR3w7k /IYOgWH22BUGaWb/KhQFtZysVZPMjguNduHJDT0MK35sOrCs39jhP8ElEX5tmhKwU7aL 72iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774631051; x=1775235851; h=mime-version:message-id:date:user-agent:subject:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KED/jrCvE0r+8txrYgTNPSKkJhFGgZb6YkrCHOeobzc=; b=Y7M6+iQVf67MuPAG8hzOIemUA7O9UmaGOgn0R/Wy462Ki1pTXCdP0Fi7y5UVYFpUUX 0qCfCqTqz8XZU1WlR5VxiCoUkTNbgX31+fAitY+sRwOTzP2hzYWJZRgUJO/lRCjdSsB6 g8iyZT6Qykl3JbsObfAdC9shaa6oJbHg2whPeFk3yUKlL9bmd8cLUEFMT58N5tUoIHah LjTQP0ID/gCvxMnKwdB4e/jSUmU4Dwp1uGa0fpW4GtgyxVt0xSqBP5njD6NubFniDb8p t0uRfeHcLii+SxC5PevErModkwhWWjhSylR6zyABrBXEZrSu2ZEAUMl+rDrzD1sB5Tsg x1Ag== X-Gm-Message-State: AOJu0YwK5yE9ueZDrQ++ervpzP1whPqy9TEAw4JGlnrhmRJViiFfhBIU kvElsLOU3ums/HNalBWLoTbvQRY8j9fNkppb8knf0EGLqPqBHHH/W73uA4URfSOygumpXYMM+pD +7RRd2cQ= X-Gm-Gg: ATEYQzzjZbd/AyyqSh7jAPn0h6WnqPydSake4HVC3SkEIYzSJ2uy/F6pK5viusx2jgW /GD/A2ImO8+MDYIk6lBVftrI14BvaFQxnTc19RHFlTxK1cJZNDnLLTHZIIaKo+LbgT3SZB/IbEZ iRA0MdCI9NgcPJFSSr6/grNG/zZdYGwpIDX+o5BBk29ELx07Oe2KK+yV2Ollta8gCEA23+ZH8Fz sHRcahA1hXBjyZXYVVPSl+QEVbO9HmfIJqUM/2P/fPqqAujfQa59FvkILPIH+GgXwKUNe4KAV2Y F6hZzl/LzGEyLQY/6s6vOfJHnJ083y6pgJq6MA0trlc29B13Q7AiRqGm+RjibxyRp78NppEq8ip fJl3oUyyLDSO3Jy/wrFPWtNFL7FLgb/RfI/f5Ce4gjfWVx5pfl4Tf0bHgfzLPir8doqe+iGbJt3 1zLTw3hsXhnYvIlyiRqwWfySyPBlIkEzsK/5qB452EHSAMjQytJeQyXhlCed3O X-Received: by 2002:a05:651c:1a25:b0:38a:4e8d:747 with SMTP id 38308e7fff4ca-38c756d1ca8mr11064671fa.1.1774631051190; Fri, 27 Mar 2026 10:04:11 -0700 (PDT) Received: from hedwig (ip-89-250-200-19.rev.snt.net.pl. [89.250.200.19]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-38c532f41efsm14820321fa.29.2026.03.27.10.04.10 for <binutils@sourceware.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Mar 2026 10:04:10 -0700 (PDT) From: Michal Lach <michal.lach@phoenix-rtos.com> To: Binutils <binutils@sourceware.org> Subject: [RFC] Disabling -z execstack per emulation User-Agent: mu4e 1.12.12; emacs 30.2 Date: Fri, 27 Mar 2026 18:04:08 +0100 Message-ID: <87a4vtdx13.fsf@phoenix-rtos.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Binutils mailing list <binutils.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>, <mailto:binutils-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/binutils/> List-Post: <mailto:binutils@sourceware.org> List-Help: <mailto:binutils-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>, <mailto:binutils-request@sourceware.org?subject=subscribe> Errors-To: binutils-bounces~patchwork=sourceware.org@sourceware.org |
| Series |
[RFC] Disabling -z execstack per emulation
|
|
Checks
| Context | Check | Description |
|---|---|---|
| linaro-tcwg-bot/tcwg_binutils_build--master-arm | fail | Patch failed to apply |
| linaro-tcwg-bot/tcwg_binutils_build--master-aarch64 | fail | Patch failed to apply |
Commit Message
Michal Lach
March 27, 2026, 5:04 p.m. UTC
Hi, I was wondering about having an emulation parameter for elf.am based emulations to disable usage of -z execstack. The rationale is that there are systems that do not allow for creation of executable stack mappings, such as OpenBSD, on which warnings about executable stacks will appear regardless; that is a bit misleading. I'd like to ask for any thoughts on the matter described. I'm attaching a patch with a draft of how I have this implemented right now. --- -- 2.53.0 -- - Michal Lach
Comments
On 27.03.2026 18:04, Michal Lach wrote: > Hi, > > I was wondering about having an emulation parameter for elf.am > based emulations to disable usage of -z execstack. > > The rationale is that there are systems that do not allow for creation > of executable stack mappings, such as OpenBSD, And that also never was possible there? > on which warnings about > executable stacks will appear regardless; that is a bit misleading. > > I'd like to ask for any thoughts on the matter described. > > I'm attaching a patch with a draft of how I have this implemented > right now. That isn't quite enough, is it? You would also want to suppress ELF note generation as well as recognition, I guess. Diagnostics emitted when finding an execstack note (from an old or "foreign" toolchain) may also want to have alternative wording there. Jan > --- > diff --git a/ld/emultempl/elf.em b/ld/emultempl/elf.em > index 37bdfff051c..1fd03b9b859 100644 > --- a/ld/emultempl/elf.em > +++ b/ld/emultempl/elf.em > @@ -900,7 +900,7 @@ gld${EMULATION_NAME}_handle_option (int optc) > break; > case OPTION_NO_ROSEGMENT: > link_info.one_rosegment = false; > - break; > + break; > EOF > > if test x"$GENERATE_SHLIB_SCRIPT" = xyes; then > @@ -998,11 +998,25 @@ fragment <<EOF > 'default'. */ > link_info.stacksize = -1; > } > +EOF > +if test x"$DISALLOW_EXECSTACK" = xyes; then > +fragment <<EOF > + else if (strcmp (optarg, "execstack") == 0) > + { > + einfo (_("%P: -z execstack is disabled on this target" > + ", treating this flag as a no-op\n")); > + } > +EOF > +else > +fragment <<EOF > else if (strcmp (optarg, "execstack") == 0) > { > link_info.execstack = true; > link_info.noexecstack = false; > } > +EOF > +fi > +fragment <<EOF > else if (strcmp (optarg, "noexecstack") == 0) > { > link_info.noexecstack = true; > -- > 2.53.0 > > -- > - Michal Lach
Jan Beulich <jbeulich@suse.com> writes: Resending with binutils@ CC, sorry, did not reply-all. > On 27.03.2026 18:04, Michal Lach wrote: >> Hi, >> >> I was wondering about having an emulation parameter for elf.am >> based emulations to disable usage of -z execstack. >> >> The rationale is that there are systems that do not allow for creation >> of executable stack mappings, such as OpenBSD, > > And that also never was possible there? It was, 24 years ago, from 1.19 executable stacks are disabled by default IIUC. >> on which warnings about >> executable stacks will appear regardless; that is a bit misleading. >> >> I'd like to ask for any thoughts on the matter described. >> >> I'm attaching a patch with a draft of how I have this implemented >> right now. > > That isn't quite enough, is it? You would also want to suppress ELF > note generation as well as recognition, I guess. Diagnostics emitted > when finding an execstack note (from an old or "foreign" toolchain) > may also want to have alternative wording there. This would have to be paired with disabling execstack warnings per-target in configure.tgt scripts, but it is already possible, unlike what I described. -- - Michal Lach
Okay, so if there are no NAK's on this, I'll submit this patch tomorrow and see how it does. Michal Lach <michal.lach@phoenix-rtos.com> writes: > Jan Beulich <jbeulich@suse.com> writes: > > Resending with binutils@ CC, sorry, did not reply-all. > >> On 27.03.2026 18:04, Michal Lach wrote: >>> Hi, >>> >>> I was wondering about having an emulation parameter for elf.am >>> based emulations to disable usage of -z execstack. >>> >>> The rationale is that there are systems that do not allow for creation >>> of executable stack mappings, such as OpenBSD, >> >> And that also never was possible there? > > It was, 24 years ago, from 1.19 executable stacks are disabled by > default IIUC. > >>> on which warnings about >>> executable stacks will appear regardless; that is a bit misleading. >>> >>> I'd like to ask for any thoughts on the matter described. >>> >>> I'm attaching a patch with a draft of how I have this implemented >>> right now. >> >> That isn't quite enough, is it? You would also want to suppress ELF >> note generation as well as recognition, I guess. Diagnostics emitted >> when finding an execstack note (from an old or "foreign" toolchain) >> may also want to have alternative wording there. > > This would have to be paired with disabling execstack warnings > per-target in configure.tgt scripts, but it is already possible, > unlike what I described. -- - Michal Lach
diff --git a/ld/emultempl/elf.em b/ld/emultempl/elf.em index 37bdfff051c..1fd03b9b859 100644 --- a/ld/emultempl/elf.em +++ b/ld/emultempl/elf.em @@ -900,7 +900,7 @@ gld${EMULATION_NAME}_handle_option (int optc) break; case OPTION_NO_ROSEGMENT: link_info.one_rosegment = false; - break; + break; EOF if test x"$GENERATE_SHLIB_SCRIPT" = xyes; then @@ -998,11 +998,25 @@ fragment <<EOF 'default'. */ link_info.stacksize = -1; } +EOF +if test x"$DISALLOW_EXECSTACK" = xyes; then +fragment <<EOF + else if (strcmp (optarg, "execstack") == 0) + { + einfo (_("%P: -z execstack is disabled on this target" + ", treating this flag as a no-op\n")); + } +EOF +else +fragment <<EOF else if (strcmp (optarg, "execstack") == 0) { link_info.execstack = true; link_info.noexecstack = false; } +EOF +fi +fragment <<EOF else if (strcmp (optarg, "noexecstack") == 0) { link_info.noexecstack = true;