* [Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
@ 2021-03-16 13:23 ` rguenth at gcc dot gnu.org
2021-03-16 13:26 ` marxin at gcc dot gnu.org
` (18 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-16 13:23 UTC (permalink / raw)
To: gcc-bugs
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'.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
2021-03-16 13:23 ` [Bug lto/99618] " rguenth at gcc dot gnu.org
@ 2021-03-16 13:26 ` marxin at gcc dot gnu.org
2021-03-17 13:33 ` hjl.tools at gmail dot com
` (17 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-16 13:26 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
2021-03-16 13:23 ` [Bug lto/99618] " rguenth at gcc dot gnu.org
2021-03-16 13:26 ` marxin at gcc dot gnu.org
@ 2021-03-17 13:33 ` hjl.tools at gmail dot com
2021-03-17 13:41 ` rguenth at gcc dot gnu.org
` (16 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: hjl.tools at gmail dot com @ 2021-03-17 13:33 UTC (permalink / raw)
To: gcc-bugs
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]$
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (2 preceding siblings ...)
2021-03-17 13:33 ` hjl.tools at gmail dot com
@ 2021-03-17 13:41 ` rguenth at gcc dot gnu.org
2021-03-17 13:44 ` rguenth at gcc dot gnu.org
` (15 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 13:41 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (3 preceding siblings ...)
2021-03-17 13:41 ` rguenth at gcc dot gnu.org
@ 2021-03-17 13:44 ` rguenth at gcc dot gnu.org
2021-03-17 13:44 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 13:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (4 preceding siblings ...)
2021-03-17 13:44 ` rguenth at gcc dot gnu.org
@ 2021-03-17 13:44 ` jakub at gcc dot gnu.org
2021-03-17 13:49 ` hjl.tools at gmail dot com
` (13 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-17 13:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (5 preceding siblings ...)
2021-03-17 13:44 ` jakub at gcc dot gnu.org
@ 2021-03-17 13:49 ` hjl.tools at gmail dot com
2021-03-17 13:51 ` [Bug debug/99618] " hjl.tools at gmail dot com
` (12 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: hjl.tools at gmail dot com @ 2021-03-17 13:49 UTC (permalink / raw)
To: gcc-bugs
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]$
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (6 preceding siblings ...)
2021-03-17 13:49 ` hjl.tools at gmail dot com
@ 2021-03-17 13:51 ` hjl.tools at gmail dot com
2021-03-17 13:54 ` hjl.tools at gmail dot com
` (11 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: hjl.tools at gmail dot com @ 2021-03-17 13:51 UTC (permalink / raw)
To: gcc-bugs
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".
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (7 preceding siblings ...)
2021-03-17 13:51 ` [Bug debug/99618] " hjl.tools at gmail dot com
@ 2021-03-17 13:54 ` hjl.tools at gmail dot com
2021-03-17 13:56 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: hjl.tools at gmail dot com @ 2021-03-17 13:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (8 preceding siblings ...)
2021-03-17 13:54 ` hjl.tools at gmail dot com
@ 2021-03-17 13:56 ` rguenth at gcc dot gnu.org
2021-03-17 13:59 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 13:56 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (9 preceding siblings ...)
2021-03-17 13:56 ` rguenth at gcc dot gnu.org
@ 2021-03-17 13:59 ` jakub at gcc dot gnu.org
2021-03-17 14:08 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-17 13:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (10 preceding siblings ...)
2021-03-17 13:59 ` jakub at gcc dot gnu.org
@ 2021-03-17 14:08 ` rguenth at gcc dot gnu.org
2021-03-17 14:10 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 14:08 UTC (permalink / raw)
To: gcc-bugs
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"
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (11 preceding siblings ...)
2021-03-17 14:08 ` rguenth at gcc dot gnu.org
@ 2021-03-17 14:10 ` rguenth at gcc dot gnu.org
2021-03-17 14:12 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 14:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (12 preceding siblings ...)
2021-03-17 14:10 ` rguenth at gcc dot gnu.org
@ 2021-03-17 14:12 ` jakub at gcc dot gnu.org
2021-03-17 14:12 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-17 14:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (13 preceding siblings ...)
2021-03-17 14:12 ` jakub at gcc dot gnu.org
@ 2021-03-17 14:12 ` rguenth at gcc dot gnu.org
2021-03-17 14:29 ` hjl.tools at gmail dot com
` (4 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-17 14:12 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (14 preceding siblings ...)
2021-03-17 14:12 ` rguenth at gcc dot gnu.org
@ 2021-03-17 14:29 ` hjl.tools at gmail dot com
2021-03-17 14:32 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: hjl.tools at gmail dot com @ 2021-03-17 14:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (15 preceding siblings ...)
2021-03-17 14:29 ` hjl.tools at gmail dot com
@ 2021-03-17 14:32 ` jakub at gcc dot gnu.org
2021-03-17 15:54 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-17 14:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (16 preceding siblings ...)
2021-03-17 14:32 ` jakub at gcc dot gnu.org
@ 2021-03-17 15:54 ` jakub at gcc dot gnu.org
2021-03-17 18:09 ` marxin at gcc dot gnu.org
2021-03-17 22:45 ` hjl.tools at gmail dot com
19 siblings, 0 replies; 21+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-17 15:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (17 preceding siblings ...)
2021-03-17 15:54 ` jakub at gcc dot gnu.org
@ 2021-03-17 18:09 ` marxin at gcc dot gnu.org
2021-03-17 22:45 ` hjl.tools at gmail dot com
19 siblings, 0 replies; 21+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-17 18:09 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section
2021-03-16 13:11 [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
` (18 preceding siblings ...)
2021-03-17 18:09 ` marxin at gcc dot gnu.org
@ 2021-03-17 22:45 ` hjl.tools at gmail dot com
19 siblings, 0 replies; 21+ messages in thread
From: hjl.tools at gmail dot com @ 2021-03-17 22:45 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 21+ messages in thread