| Message ID | 16a40e11-e97f-59bd-9990-9b7e6dee39c9@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [committed] Fix more problems with new linker warnings | expand |
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
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.