[committed] Fix more problems with new linker warnings

[committed] Fix more problems with new linker warnings

[Jeff Law]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

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

[-- Attachment #2: P --]
[-- Type: text/plain, Size: 2327 bytes --]

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.

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

Re: [committed] Fix more problems with new linker warnings

[H.J. Lu]

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.

-- 
H.J.

Re: [committed] Fix more problems with new linker warnings

[Jeff Law]

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

Re: [committed] Fix more problems with new linker warnings

[H.J. Lu]

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.

-- 
H.J.

Re: [committed] Fix more problems with new linker warnings

[Richard Biener]

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.

Re: [committed] Fix more problems with new linker warnings

[H.J. Lu]

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.

-- 
H.J.

Re: [committed] Fix more problems with new linker warnings

[Martin Liška]

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

[Jeff Law]

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

[Martin Liška]

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
>