From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95983 invoked by alias); 25 Jul 2018 20:56:31 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 95972 invoked by uid 89); 25 Jul 2018 20:56:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=Hx-languages-length:804 X-HELO: relay1.mentorg.com Date: Wed, 25 Jul 2018 20:56:00 -0000 From: Joseph Myers To: Vineet Gupta CC: Zong Li , "libc-alpha@sourceware.org" , "zongbox@gmail.com" , arcml Subject: Re: [PATCH] Fix the ld flags not be applied to tst-execstack-mod.so In-Reply-To: Message-ID: References: <1532081682-25895-1-git-send-email-zong@andestech.com> <469dcf75-d652-62ee-8310-ea59ec878a0a@synopsys.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-07/txt/msg00852.txt.bz2 On Wed, 25 Jul 2018, Vineet Gupta wrote: > But given the dso code has nested function, a well equipped gcc when generating > trampoline code would also generate the GNU_STACK segment for the dso > automatically, without need to force the same via the linker flags as is done in > the Makefile currently. Only when a port's gcc doesn't support this (ARC gcc > didn't until recently), should we need ld assist, and this could be detected using > a configure test - No ? The test should achieve the executable stack markings independent of whether nested functions require them on that architecture (for example, it should still have the markings on architectures with function descriptors). -- Joseph S. Myers joseph@codesourcery.com