Message ID | 16a40e11-e97f-59bd-9990-9b7e6dee39c9@gmail.com |
---|---|
State | Committed |
Commit | d993c6dea7c664aa26ee04210c471cfcb4e7d0e0 |
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 DFB223856DF3 for <patchwork@sourceware.org>; Thu, 28 Apr 2022 16:10:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DFB223856DF3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1651162255; bh=yVf53qrMYr1uBQBDNJA+mggVQXAAFea3034nGCODq0o=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=NbpATC7yh6cXdU2tJMjEZowJTIlXTC9adXmBxzKCrCgm2jCAQJUKuXiS4DZb8bKDe 9fop23mk3mXRoBiTQ53KixZaT3c6bVkEkJWwPG0aamtEANz03k5R3tluT3ssFWDHb0 iAnxd463SCsnRFowpfecron1xAoLfuvYF/PJ1XXo= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id BD3B5385842B for <gcc-patches@gcc.gnu.org>; Thu, 28 Apr 2022 16:10:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BD3B5385842B Received: by mail-pl1-x631.google.com with SMTP id c23so4819234plo.0 for <gcc-patches@gcc.gnu.org>; Thu, 28 Apr 2022 09:10:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:subject:to; bh=yVf53qrMYr1uBQBDNJA+mggVQXAAFea3034nGCODq0o=; b=6mwvZV3867wh/KyhYB3AfiLabkfmBXUkqVzpWOwn0yDn/H50c3WqUFEzxyg27XRRCk Epd5GIuHmPbsKe3Mf6or7YXY/IjIOtaLt4zuarlFoniOYMNWDPRlgygM81xCvI7V8tLZ tPaDVux77LHKKlDP27/FnqfRk2vt+dpBepyAVseKBBHb4gZwNKA+b9byqIH3MMtc5bes R/Kc5VdXLTTI25PFYg6kY/TEh20DCAlTa36XI+aZOP1+eh/G8kck1lJ8cJ9fKDiYRQYH seKXCKVgXe6oUxQJCkgejK1p5gny2Od9S7TfGwhSg+Rc3LPKRFwoy4tJY7S1ww8b9Gxf whxg== X-Gm-Message-State: AOAM533ZE83fS8Fn0BViziF+Cy7YoqMSZ4tYvxCAsLFtCLpaitZgeuUQ /xgeBWn94cDTMZdrbqMPfLfonECFfLk= X-Google-Smtp-Source: ABdhPJwa9hNMegxfstygIkXYznaMOfhUDMsv0/DKliNH/XRolK/Z27IA92zC4DKJiul7cQKaD4YhnQ== X-Received: by 2002:a17:902:db0f:b0:15d:1e6b:4357 with SMTP id m15-20020a170902db0f00b0015d1e6b4357mr19465786plx.127.1651162219315; Thu, 28 Apr 2022 09:10:19 -0700 (PDT) Received: from [172.31.0.204] (c-73-63-24-84.hsd1.ut.comcast.net. [73.63.24.84]) by smtp.gmail.com with ESMTPSA id t186-20020a6281c3000000b0050d242b604dsm279356pfd.108.2022.04.28.09.10.18 for <gcc-patches@gcc.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Apr 2022 09:10:18 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------04eOF46RSgln0mSMy63Us0ak" Message-ID: <16a40e11-e97f-59bd-9990-9b7e6dee39c9@gmail.com> Date: Thu, 28 Apr 2022 10:10:17 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US Subject: [committed] Fix more problems with new linker warnings To: 'GCC Patches' <gcc-patches@gcc.gnu.org> X-Spam-Status: No, score=-8.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: Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jeff Law <jeffreyalaw@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 |
[committed] Fix more problems with new linker warnings
|
|
Commit Message
Jeff Law
April 28, 2022, 4:10 p.m. UTC
As I mentioned in the original thread, my change to pr94157_0 was an attempt to avoid these warnings by passing a magic flag to the linker. Of course we may not be using GNU ld. Or we may be on a non-elf target where the flag I used doesn't exist. Or we may even be on a ELF target where those bits weren't added to the linker (frv). Furthermore, we need fixes to all the nested function tests as well. So even though I initially resisted pruning the warning, that seems like the best course of action. So this patch removes my recent change to pr94157_0 and instead uses our pruning facilities. I'll be pushing this to the trunk and gcc-12 branch. Jeff commit af71f96631920f32ed9ec6c1c35d140dbe9992d1 Author: Jeff Law <jeffreyalaw@gmail.com> Date: Thu Apr 28 12:03:52 2022 -0400 [committed] Fix more problems with new linker warnings gcc/testsuite * gcc.dg/lto/pr94157_0.c: Revert last change. * lib/prune.exp (prune_gcc_output): Prune new linker warning.
Comments
On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > As I mentioned in the original thread, my change to pr94157_0 was an > attempt to avoid these warnings by passing a magic flag to the linker. > Of course we may not be using GNU ld. Or we may be on a non-elf target > where the flag I used doesn't exist. Or we may even be on a ELF target > where those bits weren't added to the linker (frv). Furthermore, we > need fixes to all the nested function tests as well. > > So even though I initially resisted pruning the warning, that seems like > the best course of action. So this patch removes my recent change to > pr94157_0 and instead uses our pruning facilities. > > I'll be pushing this to the trunk and gcc-12 branch. > Can you backport it to other release branches? Thanks.
On 4/28/2022 10:27 AM, H.J. Lu wrote: > On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: >> As I mentioned in the original thread, my change to pr94157_0 was an >> attempt to avoid these warnings by passing a magic flag to the linker. >> Of course we may not be using GNU ld. Or we may be on a non-elf target >> where the flag I used doesn't exist. Or we may even be on a ELF target >> where those bits weren't added to the linker (frv). Furthermore, we >> need fixes to all the nested function tests as well. >> >> So even though I initially resisted pruning the warning, that seems like >> the best course of action. So this patch removes my recent change to >> pr94157_0 and instead uses our pruning facilities. >> >> I'll be pushing this to the trunk and gcc-12 branch. >> > Can you backport it to other release branches? I wasn't planning to, but can if the RMs want it. jeff
On Thu, Apr 28, 2022 at 9:59 AM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > On 4/28/2022 10:27 AM, H.J. Lu wrote: > > On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > >> As I mentioned in the original thread, my change to pr94157_0 was an > >> attempt to avoid these warnings by passing a magic flag to the linker. > >> Of course we may not be using GNU ld. Or we may be on a non-elf target > >> where the flag I used doesn't exist. Or we may even be on a ELF target > >> where those bits weren't added to the linker (frv). Furthermore, we > >> need fixes to all the nested function tests as well. > >> > >> So even though I initially resisted pruning the warning, that seems like > >> the best course of action. So this patch removes my recent change to > >> pr94157_0 and instead uses our pruning facilities. > >> > >> I'll be pushing this to the trunk and gcc-12 branch. > >> > > Can you backport it to other release branches? > I wasn't planning to, but can if the RMs want it. > jeff Hi Jakub, Ricard, Is it OK to backport the new linker support to GCC 11 and GCC 10 branches? Thanks.
On Thu, Apr 28, 2022 at 7:54 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Thu, Apr 28, 2022 at 9:59 AM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > > > > > On 4/28/2022 10:27 AM, H.J. Lu wrote: > > > On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches > > > <gcc-patches@gcc.gnu.org> wrote: > > >> As I mentioned in the original thread, my change to pr94157_0 was an > > >> attempt to avoid these warnings by passing a magic flag to the linker. > > >> Of course we may not be using GNU ld. Or we may be on a non-elf target > > >> where the flag I used doesn't exist. Or we may even be on a ELF target > > >> where those bits weren't added to the linker (frv). Furthermore, we > > >> need fixes to all the nested function tests as well. > > >> > > >> So even though I initially resisted pruning the warning, that seems like > > >> the best course of action. So this patch removes my recent change to > > >> pr94157_0 and instead uses our pruning facilities. > > >> > > >> I'll be pushing this to the trunk and gcc-12 branch. > > >> > > > Can you backport it to other release branches? > > I wasn't planning to, but can if the RMs want it. > > jeff > > Hi Jakub, Ricard, > > Is it OK to backport the new linker support to GCC 11 and > GCC 10 branches? It's OK if no problems have been reported for a while. Thanks, Richard. > Thanks. > > -- > H.J.
On Thu, Apr 28, 2022 at 11:52 PM Richard Biener <richard.guenther@gmail.com> wrote: > > On Thu, Apr 28, 2022 at 7:54 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > On Thu, Apr 28, 2022 at 9:59 AM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > > > > > > > > > On 4/28/2022 10:27 AM, H.J. Lu wrote: > > > > On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches > > > > <gcc-patches@gcc.gnu.org> wrote: > > > >> As I mentioned in the original thread, my change to pr94157_0 was an > > > >> attempt to avoid these warnings by passing a magic flag to the linker. > > > >> Of course we may not be using GNU ld. Or we may be on a non-elf target > > > >> where the flag I used doesn't exist. Or we may even be on a ELF target > > > >> where those bits weren't added to the linker (frv). Furthermore, we > > > >> need fixes to all the nested function tests as well. > > > >> > > > >> So even though I initially resisted pruning the warning, that seems like > > > >> the best course of action. So this patch removes my recent change to > > > >> pr94157_0 and instead uses our pruning facilities. > > > >> > > > >> I'll be pushing this to the trunk and gcc-12 branch. > > > >> > > > > Can you backport it to other release branches? > > > I wasn't planning to, but can if the RMs want it. > > > jeff > > > > Hi Jakub, Ricard, > > > > Is it OK to backport the new linker support to GCC 11 and > > GCC 10 branches? > > It's OK if no problems have been reported for a while. > > Thanks, > Richard. I am backporting it now. Thanks.
On 4/28/22 18:10, Jeff Law via Gcc-patches wrote: > As I mentioned in the original thread, my change to pr94157_0 was an attempt to avoid these warnings by passing a magic flag to the linker. Of course we may not be using GNU ld. Or we may be on a non-elf target where the flag I used doesn't exist. Or we may even be on a ELF target where those bits weren't added to the linker (frv). Furthermore, we need fixes to all the nested function tests as well. > > So even though I initially resisted pruning the warning, that seems like the best course of action. So this patch removes my recent change to pr94157_0 and instead uses our pruning facilities. > > I'll be pushing this to the trunk and gcc-12 branch. > > Jeff Hello. I noticed this patch during my GCC test-suite run with mold linker. As you likely now, the linker defaults to non-executable stack and so one sees test-suite crashes (not only warnings) [1]. So the question is if we want to explicitly fix all tests that rely on exectack? Or is it something we can assume as it's what GNU linkers do? List of affected tests: https://gist.githubusercontent.com/marxin/aadb75408a5a7867bf9fb26e879ce4c4/raw/aff2a0e4559e2dba8ea358520ca836eda6e7dc70/gistfile1.txt Thanks, Martin [1] https://github.com/rui314/mold/issues/427
On 8/22/2022 3:39 AM, Martin Liška wrote: > On 4/28/22 18:10, Jeff Law via Gcc-patches wrote: >> As I mentioned in the original thread, my change to pr94157_0 was an attempt to avoid these warnings by passing a magic flag to the linker. Of course we may not be using GNU ld. Or we may be on a non-elf target where the flag I used doesn't exist. Or we may even be on a ELF target where those bits weren't added to the linker (frv). Furthermore, we need fixes to all the nested function tests as well. >> >> So even though I initially resisted pruning the warning, that seems like the best course of action. So this patch removes my recent change to pr94157_0 and instead uses our pruning facilities. >> >> I'll be pushing this to the trunk and gcc-12 branch. >> >> Jeff > Hello. > > I noticed this patch during my GCC test-suite run with mold linker. As you likely now, the linker defaults > to non-executable stack and so one sees test-suite crashes (not only warnings) [1]. > > So the question is if we want to explicitly fix all tests that rely on exectack? Or is it something > we can assume as it's what GNU linkers do? > > List of affected tests: > https://gist.githubusercontent.com/marxin/aadb75408a5a7867bf9fb26e879ce4c4/raw/aff2a0e4559e2dba8ea358520ca836eda6e7dc70/gistfile1.txt The problem I ran into was that there wasn't a good way to determine what to do, even if we know the test was going to need execstack. We can't just blindly pass the magic flag to the linker -- at the least that would need to be conditional on the linker being used as well as the target as some of the ELF targets don't have the linker infrastructure. And given that the linker can vary across gnu-ld, gold, mold, it's a rats nest. jeff
On 8/31/22 17:49, Jeff Law wrote: > > > On 8/22/2022 3:39 AM, Martin Liška wrote: >> On 4/28/22 18:10, Jeff Law via Gcc-patches wrote: >>> As I mentioned in the original thread, my change to pr94157_0 was an attempt to avoid these warnings by passing a magic flag to the linker. Of course we may not be using GNU ld. Or we may be on a non-elf target where the flag I used doesn't exist. Or we may even be on a ELF target where those bits weren't added to the linker (frv). Furthermore, we need fixes to all the nested function tests as well. >>> >>> So even though I initially resisted pruning the warning, that seems like the best course of action. So this patch removes my recent change to pr94157_0 and instead uses our pruning facilities. >>> >>> I'll be pushing this to the trunk and gcc-12 branch. >>> >>> Jeff >> Hello. >> >> I noticed this patch during my GCC test-suite run with mold linker. As you likely now, the linker defaults >> to non-executable stack and so one sees test-suite crashes (not only warnings) [1]. >> >> So the question is if we want to explicitly fix all tests that rely on exectack? Or is it something >> we can assume as it's what GNU linkers do? >> >> List of affected tests: >> https://gist.githubusercontent.com/marxin/aadb75408a5a7867bf9fb26e879ce4c4/raw/aff2a0e4559e2dba8ea358520ca836eda6e7dc70/gistfile1.txt > The problem I ran into was that there wasn't a good way to determine what to do, even if we know the test was going to need execstack. We can't just blindly pass the magic flag to the linker -- at the least that would need to be conditional on the linker being used as well as the target as some of the ELF targets don't have the linker infrastructure. And given that the linker can vary across gnu-ld, gold, mold, it's a rats nest. Makes sense. So far the simplest approach seems to me modifying mold and allowing execstack. Unfortunately, the author does not want to introduce a new configure option. Martin > > jeff >
diff --git a/gcc/testsuite/gcc.dg/lto/pr94157_0.c b/gcc/testsuite/gcc.dg/lto/pr94157_0.c index a76141b1809..a6e308b855b 100644 --- a/gcc/testsuite/gcc.dg/lto/pr94157_0.c +++ b/gcc/testsuite/gcc.dg/lto/pr94157_0.c @@ -1,6 +1,6 @@ /* { dg-lto-do link } */ /* { dg-require-effective-target gas } */ -/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack -Wa,--noexecstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wl,-z,execstack} } } */ +/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack -Wa,--noexecstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack } } } */ int main() { diff --git a/gcc/testsuite/lib/prune.exp b/gcc/testsuite/lib/prune.exp index 422498527aa..04c6a1dd7a1 100644 --- a/gcc/testsuite/lib/prune.exp +++ b/gcc/testsuite/lib/prune.exp @@ -82,6 +82,11 @@ proc prune_gcc_output { text } { regsub -all "(^|\n)\[^\n\]*file path prefix \[^\n\]* never used" $text "" text regsub -all "(^|\n)\[^\n\]*linker input file unused since linking not done" $text "" text + # Ideally the tests would indicate that executable stacks were needed + # to the linker. But the option for that varies and may not even exist + # on some targets. So we're stuck pruning the warning. + regsub -all "(^|\n)(\[^\n\]*: warning:\[^\n\]*requires executable stack\[^\n\]*\n?)+" $text "\\1" text + # Ignore harmless warnings from Xcode 3.2.x. regsub -all "(^|\n)\[^\n\]*ld: warning: can't add line info to anonymous symbol\[^\n\]*" $text "" text regsub -all "(^|\n)\[^\n\]*warning: DWARFDebugInfoEntry::AppendDependants\[^\n\]*AT_\[^\n\]*FORM_ref4\[^\n\]*" $text "" text