Re: [committed] Fix more problems with new linker warnings
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 >
Re: [committed] Fix more problems with new linker warnings
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
Re: [committed] Fix more problems with new linker warnings
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
Re: [committed] Fix more problems with new linker warnings
On Thu, Apr 28, 2022 at 11:52 PM Richard Biener wrote: > > On Thu, Apr 28, 2022 at 7:54 PM H.J. Lu wrote: > > > > On Thu, Apr 28, 2022 at 9:59 AM Jeff Law 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 > > > > 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. -- H.J.
Re: [committed] Fix more problems with new linker warnings
On Thu, Apr 28, 2022 at 7:54 PM H.J. Lu wrote: > > On Thu, Apr 28, 2022 at 9:59 AM Jeff Law 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 > > > 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.
Re: [committed] Fix more problems with new linker warnings
On Thu, Apr 28, 2022 at 9:59 AM Jeff Law 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 > > 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. -- H.J.
Re: [committed] Fix more problems with new linker warnings
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 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
Re: [committed] Fix more problems with new linker warnings
On Thu, Apr 28, 2022 at 9:10 AM 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. > Can you backport it to other release branches? Thanks. -- H.J.
[committed] Fix more problems with new linker warnings
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.
Jeffcommit af71f96631920f32ed9ec6c1c35d140dbe9992d1
Author: Jeff Law
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.
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
