[Bug lto/99618] New: `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[Bug lto/99618] New: `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

            Bug ID: 99618
           Summary: `.gnu.debuglto_.debug_macro' referenced in section
                    `.gnu.debuglto_.debug_macro' of X defined in discarded
                    section
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

I'm not sure if it's problem at compiler or linker side. Reduced from perf
package:

$ cat 1.i
;
# 1 "/usr/include/bits/wordsize.h" 1  
#define __WORDSIZE 64
#define __WORDSIZE_TIME64_COMPAT32 1

$ gcc -flto -ggdb3 -c -fPIC -g 1.i && cp 1.o 2.o && gcc -r -o libperf-in.o
[12].o -fuse-ld=bfd
`.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro'
of /tmp/ccnBoXGI.debug.temp.o: defined in discarded section
`.gnu.debuglto_.debug_macro[wm4.wordsize.h.1.b68ef8235bd466c01307f942f7f51e04]'
of /tmp/ccnBoXGI.debug.temp.o
collect2: error: ld returned 1 exit status

While ld.gold is fine:

$ gcc -flto -ggdb3 -c -fPIC -g 1.i && cp 1.o 2.o && gcc -r -o libperf-in.o
[12].o -fuse-ld=gold

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, so the linker complains that .debug_macro refers to COMDAT .debug_macro
which is discarded.  Quite possibly the linker misses special-casing of
.debug_macro because it's called .gnu.debuglto_.debug_macro in this case.

Again, this looks like a linker issue to me.

Note all involved sections are marked 'E'.

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Move to https://sourceware.org/bugzilla/show_bug.cgi?id=27590

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|MOVED                       |---
   Last reconfirmed|                            |2021-03-17
             Status|RESOLVED                    |REOPENED
     Ever confirmed|0                           |1

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
This is what GCC generates:

hjl@gnu-cfl-2 pr27590]$ cat bad.s
        .section        .gnu.debuglto_.debug_macro,"e",@progbits
.Ldebug_macro0:
        .long   .Ldebug_macro2
        .section        .gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
.Ldebug_macro2:
        .value  0x4
[hjl@gnu-cfl-2 pr27590]$ gcc -c bad.s
[hjl@gnu-cfl-2 pr27590]$ ld -r bad.o bad.o
`.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro'
of bad.o: defined in discarded section `.gnu.debuglto_.debug_macro[wm4]' of
bad.o
[hjl@gnu-cfl-2 pr27590]$

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #3)
> This is what GCC generates:
> 
> hjl@gnu-cfl-2 pr27590]$ cat bad.s
> 	.section	.gnu.debuglto_.debug_macro,"e",@progbits
> .Ldebug_macro0:
> 	.long	.Ldebug_macro2
> 	.section	.gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
> .Ldebug_macro2:
> 	.value	0x4
> [hjl@gnu-cfl-2 pr27590]$ gcc -c bad.s
> [hjl@gnu-cfl-2 pr27590]$ ld -r bad.o bad.o
> `.gnu.debuglto_.debug_macro' referenced in section
> `.gnu.debuglto_.debug_macro' of bad.o: defined in discarded section
> `.gnu.debuglto_.debug_macro[wm4]' of bad.o
> [hjl@gnu-cfl-2 pr27590]$

what's wrong with it?  All sections are marked as to be Excluded, that
the excluded sections reference each other should be irrelevant?  I suppose
that one s comdat confuses the linker?

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Maybe it's an assembler bug that it fails to set 'E' on the GROUP section?

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .group            GROUP            0000000000000000  00000040
       0000000000000008  0000000000000004           8     6     4
...
  [ 5] .gnu.debuglt[...] PROGBITS         0000000000000000  00000048
       0000000000000004  0000000000000000   E       0     0     1
  [ 6] .rela.gnu.de[...] RELA             0000000000000000  00000118
       0000000000000018  0000000000000018   I       8     5     8
  [ 7] .gnu.debuglt[...] PROGBITS         0000000000000000  0000004c
       0000000000000002  0000000000000000  GE       0     0     1

COMDAT group section [    1] `.group' [wm4] contains 1 sections:
   [Index]    Name
   [    7]   .gnu.debuglto_.debug_macro

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For normal non-LTO debug macro we emit:
        .section        .debug_macro,"",@progbits
.Ldebug_macro0:
        .value  0x5     # DWARF macro version number
        .byte   0x2     # Flags: 32-bit, lineptr present
        .long   .Ldebug_line0
        .byte   0x7     # Import
        .long   .Ldebug_macro2
...
        .section       
.debug_macro,"G",@progbits,wm4.0.d634b2ca9ddb72f687ab125549c033d0,comdat
.Ldebug_macro2:
        .value  0x5     # DWARF macro version number
        .byte   0       # Flags: 32-bit
        .byte   0x5     # Define macro strp
        .uleb128 0      # At line number 0
...
I don't see how that is any different from the above.  The intent is (and it
has been working fine for years) that linker merges the comdat sections with
the same hash into one, and the import relocations resolve to the start of that
section.

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #6)
> For normal non-LTO debug macro we emit:
>         .section        .debug_macro,"",@progbits
> .Ldebug_macro0:
>         .value  0x5     # DWARF macro version number
>         .byte   0x2     # Flags: 32-bit, lineptr present
>         .long   .Ldebug_line0
>         .byte   0x7     # Import
>         .long   .Ldebug_macro2
> ...
>         .section       
> .debug_macro,"G",@progbits,wm4.0.d634b2ca9ddb72f687ab125549c033d0,comdat
> .Ldebug_macro2:
>         .value  0x5     # DWARF macro version number
>         .byte   0       # Flags: 32-bit
>         .byte   0x5     # Define macro strp
>         .uleb128 0      # At line number 0
> ...
> I don't see how that is any different from the above.  The intent is (and it
> has been working fine for years) that linker merges the comdat sections with
> the same hash into one, and the import relocations resolve to the start of
> that section.

Same result:

[hjl@gnu-cfl-2 pr27590]$ cat bad2.s 
        .section        .gnu.debuglto_.debug_macro,"",@progbits
.Ldebug_macro0:
        .long   .Ldebug_macro2
        .section        .gnu.debuglto_.debug_macro,"G",@progbits,wm4,comdat
.Ldebug_macro2:
        .value  0x4
[hjl@gnu-cfl-2 pr27590]$ gcc -c bad2.s
[hjl@gnu-cfl-2 pr27590]$ ld -r bad2.o bad2.o
`.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro'
of bad2.o: defined in discarded section `.gnu.debuglto_.debug_macro[wm4]' of
bad2.o
[hjl@gnu-cfl-2 pr27590]$

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Richard Biener from comment #5)
> Maybe it's an assembler bug that it fails to set 'E' on the GROUP section?
> 

SHF_EXLCUDE doesn't apply to "ld -r".

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #6)
> I don't see how that is any different from the above.  The intent is (and it
> has been working fine for years) that linker merges the comdat sections with
> the same hash into one, and the import relocations resolve to the start of
> that section.

This works if the symbol reference to the comdat section is global.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #9)
> (In reply to Jakub Jelinek from comment #6)
> > I don't see how that is any different from the above.  The intent is (and it
> > has been working fine for years) that linker merges the comdat sections with
> > the same hash into one, and the import relocations resolve to the start of
> > that section.
> 
> This works if the symbol reference to the comdat section is global.

Ah, yeah.  The issue is we get a SECTION relocation because we use a
local label here?

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It has never been global.  All it needs is the start of the comdat section.
And GCC is doing it that way for 9.5 years already.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, gold happily links w/o a problem.  lld (from llvm9) reports

> ld.lld -r bad.o bad.o
ld.lld: warning: relocation refers to a discarded section:
.gnu.debuglto_.debug_macro
>>> referenced by bad.o:(.rela.gnu.debuglto_.debug_macro+0x4)

looks like gold adjusts SECTION relocs upon comdat section "merging"

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gcc dot gnu.org

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
In the end the question is what the spec for ELF says here.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looking at current binutils, it seems to misbehave though.
If I compile:
pr99618.c:
#include <stdio.h>
int i;
pr99618-2.c:
#include <stdio.h>
extern int i;

int
main ()
{
  return i++;
}
gcc -g3 -gdwarf-5 -O2 -o pr99618{,.c,-2.c}
then readelf -wm shows:
Contents of the .debug_macro section:

  Offset:                      0x0
  Version:                     5
  Offset size:                 4
  Offset into .debug_line:     0x0

 DW_MACRO_import - offset : 0x14a
 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: pr99618.c
 DW_MACRO_start_file - lineno: 0 filenum: 2 filename:
/usr/include/stdc-predef.h
 DW_MACRO_import - offset : 0x9a0
 DW_MACRO_end_file
...
  Offset:                      0x14a
  Version:                     5
  Offset size:                 4

 DW_MACRO_define_strp - lineno : 0 macro : __STDC__ 1
 DW_MACRO_define_strp - lineno : 0 macro : __STDC_VERSION__ 201710L
...
  Offset:                      0x11c2
  Version:                     5
  Offset size:                 4
  Offset into .debug_line:     0x1ec

 DW_MACRO_import - offset : 0x0
 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: pr99618-2.c
 DW_MACRO_start_file - lineno: 0 filenum: 2 filename:
/usr/include/stdc-predef.h
 DW_MACRO_import - offset : 0x0
 DW_MACRO_end_file

Obviously the last two DW_MACRO_import should have been 0x14a and 0x9a0.
I don't think we can use a global symbol though, we don't want that exported
from libraries, nor have any special naming for those.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
So as expected all of the linkers are happy with

        .section        .gnu.debuglto_.debug_macro,"e",@progbits
.Ldebug_macro0:
        .long   debug_macro2
        .section        .gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
        .globl debug_macro2
debug_macro2:
        .value  0x4

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Richard Biener from comment #15)
> So as expected all of the linkers are happy with
> 
>         .section        .gnu.debuglto_.debug_macro,"e",@progbits
> .Ldebug_macro0:
>         .long   debug_macro2
>         .section        .gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
>         .globl debug_macro2
> debug_macro2:
>         .value  0x4

You can put the first .gnu.debuglto_.debug_macro in a comdat group section.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No.  The point is that the compiler splits macros from each of the includes
into a separate comdat .debug_macro section, the TU .debug_macro additions
should stay but they macros from the same headers should be merged when
identical.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Just tried the #c14 testcase with GCC 4.7.2 (ok, not -gdwarf-5, just -g3) and
with
GNU ld version 2.22.52.0.1-10.fc17 20120131
and it works fine.
So it is the linker that regressed here.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

--- Comment #19 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #18)
> Just tried the #c14 testcase with GCC 4.7.2 (ok, not -gdwarf-5, just -g3) and
> with
> GNU ld version 2.22.52.0.1-10.fc17 20120131
> and it works fine.
> So it is the linker that regressed here.

Can you please attach both corresponding object files and the assembly file?

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=27590
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> ---
Moved to

https://sourceware.org/bugzilla/show_bug.cgi?id=27590