Message ID | CAKCAbMi5W_dGvaeMRdvjGrC9b09YK37TkCiyTkqL1F+5TPnpeg@mail.gmail.com |
---|---|
State | Superseded |
Headers |
Received: (qmail 112509 invoked by alias); 10 Jul 2017 15:54:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 112468 invoked by uid 89); 10 Jul 2017 15:53:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_SORBS_SPAM, RP_MATCHES_RCVD, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy=our, research X-HELO: mailbackend.panix.com X-Gm-Message-State: AIVw113oFe3t7sZUXzpR+3ELwy9mVTcD0zczl3MTiSLpUTXUWLqZ0Ara bvXdz674wFaY87SNNprGT8ZrqjAsDQ== X-Received: by 10.36.236.3 with SMTP id g3mr12619913ith.45.1499702033259; Mon, 10 Jul 2017 08:53:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <alpine.DEB.2.20.1707101252200.30742@digraph.polyomino.org.uk> References: <CAKCAbMj2RvaJFM8ec7+huEOTCSrUiWV4sv2hK8K_iUJ5q4fEmg@mail.gmail.com> <alpine.DEB.2.20.1707101115470.22173@digraph.polyomino.org.uk> <CAKCAbMhq7Ht3FTeuqK3R9JX9eotcmj603CviJVuhd1dqi_TgXw@mail.gmail.com> <alpine.DEB.2.20.1707101252200.30742@digraph.polyomino.org.uk> From: Zack Weinberg <zackw@panix.com> Date: Mon, 10 Jul 2017 11:53:52 -0400 X-Gmail-Original-Message-ID: <CAKCAbMi5W_dGvaeMRdvjGrC9b09YK37TkCiyTkqL1F+5TPnpeg@mail.gmail.com> Message-ID: <CAKCAbMi5W_dGvaeMRdvjGrC9b09YK37TkCiyTkqL1F+5TPnpeg@mail.gmail.com> Subject: Re: A quick architecture status report To: Joseph Myers <joseph@codesourcery.com> Cc: GNU C Library <libc-alpha@sourceware.org> Content-Type: text/plain; charset="UTF-8" |
Commit Message
Zack Weinberg
July 10, 2017, 3:53 p.m. UTC
On Mon, Jul 10, 2017 at 8:56 AM, Joseph Myers <joseph@codesourcery.com> wrote: > On Mon, 10 Jul 2017, Zack Weinberg wrote: > >> Alas, this is significantly more research than I have time for. I was >> hoping for a simple matter of adding .note.GNU-stack annotations to >> our own .S files :) > > Since we build with -Wa,--noexecstack if the compiler puts .note.GNU-stack > sections in its output, that's never necessary. What's needed in GCC is > (a) a TARGET_ASM_FILE_END hook that uses file_end_indicate_exec_stack, (b) > any assembly sources in libgcc need .note.GNU-stack annotations. Easy to > add, but architecture maintainers are best placed to know if that's the > right thing to do for the particular architecture. Hm, what do you think of this patch? It makes elf/check-execstack an expected failure on any target where the compiler doesn't put .note.GNU-stack sections in its output. (UNSUPPORTED might be more appropriate, but I don't see a way to trigger that from a makefile conditional.) zw
Comments
On Mon, 10 Jul 2017, Zack Weinberg wrote: > Hm, what do you think of this patch? It makes elf/check-execstack an > expected failure on any target where the compiler doesn't put > .note.GNU-stack sections in its output. (UNSUPPORTED might be more > appropriate, but I don't see a way to trigger that from a makefile > conditional.) It's not clear it *should* be expected unless there's a good architecture-specific reason.
On Jul 10 2017, Zack Weinberg <zackw@panix.com> wrote: > +# If the compiler does not support .note.GNU-stack for this > +# architecture, check-execstack is expected to fail. > +ifeq (,$(filter %noexecstack,$(ASFLAGS-config))) > +test-xfail-check-execstack = yes > +endif An architecture that is noexec by default doesn't have -znoexecstack either. Andreas.
On Mon, Jul 10, 2017 at 11:59 AM, Joseph Myers <joseph@codesourcery.com> wrote: > On Mon, 10 Jul 2017, Zack Weinberg wrote: >> Hm, what do you think of this patch? It makes elf/check-execstack an >> expected failure on any target where the compiler doesn't put >> .note.GNU-stack sections in its output. (UNSUPPORTED might be more >> appropriate, but I don't see a way to trigger that from a makefile >> conditional.) > > It's not clear it *should* be expected unless there's a good > architecture-specific reason. This is why I said UNSUPPORTED might be more appropriate. Regardless of whether it *should* work, the fact is that it doesn't, for reasons outside the control of code in glibc, and therefore leaving this as a FAIL is inappropriate in my book. Would you be satisfied with a patch along these lines (and a more specific configure check, because of what Andreas said downthread) if I also filed bugs on GCC for all affected architectures? I didn't find any existing such bugs, but I didn't look very hard. zw
On Mon, 10 Jul 2017, Zack Weinberg wrote: > On Mon, Jul 10, 2017 at 11:59 AM, Joseph Myers <joseph@codesourcery.com> wrote: > > On Mon, 10 Jul 2017, Zack Weinberg wrote: > >> Hm, what do you think of this patch? It makes elf/check-execstack an > >> expected failure on any target where the compiler doesn't put > >> .note.GNU-stack sections in its output. (UNSUPPORTED might be more > >> appropriate, but I don't see a way to trigger that from a makefile > >> conditional.) > > > > It's not clear it *should* be expected unless there's a good > > architecture-specific reason. > > This is why I said UNSUPPORTED might be more appropriate. > > Regardless of whether it *should* work, the fact is that it doesn't, > for reasons outside the control of code in glibc, and therefore > leaving this as a FAIL is inappropriate in my book. Would you be Well, if you (a new architecture, say) have executable stacks there's something wrong with your toolchain port unless there's a good reason, and I think it's desirable for there to be something immediately visible showing there's something wrong. That is, we should decide case-by-case whether something should be fixed or XFAILed. Which for this test should be fix if it's just a straightforward GCC change needed (ask architecture maintainers), XFAIL with comments otherwise. Or obsolete the port in the absence of architecture maintainers (MicroBlaze, for which email to the maintainer bounces).
diff --git a/elf/Makefile b/elf/Makefile index e758a4c960..f62f31a45b 100644 --- a/elf/Makefile +++ b/elf/Makefile @@ -1082,6 +1082,12 @@ $(objpfx)check-execstack.out: $(..)scripts/check-execstack.awk \ $(evaluate-test) generated += check-execstack.out +# If the compiler does not support .note.GNU-stack for this +# architecture, check-execstack is expected to fail. +ifeq (,$(filter %noexecstack,$(ASFLAGS-config))) +test-xfail-check-execstack = yes +endif + $(objpfx)tst-dlmodcount: $(libdl) $(objpfx)tst-dlmodcount.out: $(test-modules)