public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/88878] .debug_pubnames/types empty with -flto
[not found] <bug-88878-4@http.gcc.gnu.org/bugzilla/>
@ 2020-07-29 12:40 ` jan.kratochvil at redhat dot com
2020-07-29 12:51 ` rguenth at gcc dot gnu.org
2020-07-29 13:20 ` jan.kratochvil at redhat dot com
2 siblings, 0 replies; 3+ messages in thread
From: jan.kratochvil at redhat dot com @ 2020-07-29 12:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878
Jan Kratochvil <jan.kratochvil at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jan.kratochvil at redhat dot com
--- Comment #7 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
Hello, @rguenth could you suggest what problem does -fdebug-types-section -flto
still have?
When I remove the use_debug_types's "&& !in_lto_p" part it looks to me as
working fine. (I haven't done any non-trivial debuginfo testing.)
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Version: 4
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x0): GNU GIMPLE 10.2.1
20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -g -g -fno-openmp
-fno-openacc -fno-pie -fdebug-types-section -fltrans
<11> DW_AT_name : (indirect string, offset: 0xa8): <artificial>
Compilation Unit @ offset 0xc9:
Version: 4
<0><d4>: Abbrev Number: 11 (DW_TAG_compile_unit)
<d5> DW_AT_producer : (indirect string, offset: 0x35a): GNU C++14
10.2.1 20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -g
-fdebug-types-section -flto
<da> DW_AT_name : (indirect string, offset: 0x20e): main.C
<1><e6>: Abbrev Number: 12 (DW_TAG_class_type)
<e9> DW_AT_signature : signature: 0xf1df7e53d0fa1d2e
Compilation Unit @ offset 0x15a:
Version: 4
<0><165>: Abbrev Number: 11 (DW_TAG_compile_unit)
<166> DW_AT_producer : (indirect string, offset: 0x35a): GNU C++14
10.2.1 20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -g
-fdebug-types-section -flto
<16b> DW_AT_name : (indirect string, offset: 0x479): lib.C
Contents of the .debug_types section:
Compilation Unit @ offset 0x0:
Version: 4
Signature: 0xf1df7e53d0fa1d2e
Type Offset: 0x25
<0><17>: Abbrev Number: 1 (DW_TAG_type_unit)
<19> DW_AT_GNU_odr_signature: 0xddd94cb16fdd687a
<1><25>: Abbrev Number: 2 (DW_TAG_class_type)
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug debug/88878] .debug_pubnames/types empty with -flto
[not found] <bug-88878-4@http.gcc.gnu.org/bugzilla/>
2020-07-29 12:40 ` [Bug debug/88878] .debug_pubnames/types empty with -flto jan.kratochvil at redhat dot com
@ 2020-07-29 12:51 ` rguenth at gcc dot gnu.org
2020-07-29 13:20 ` jan.kratochvil at redhat dot com
2 siblings, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-07-29 12:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Kratochvil from comment #7)
> Hello, @rguenth could you suggest what problem does -fdebug-types-section
> -flto still have?
> When I remove the use_debug_types's "&& !in_lto_p" part it looks to me as
> working fine. (I haven't done any non-trivial debuginfo testing.)
The .debug_types section isn't supposed to be output when in_lto_p
(that's for the LTRANS units where we generally do not output any
types into DWARF). Instead .debug_types has to be output during
dwarf2out_early_finish when we write the declaration dwarf units,
the "early" debug info. That should now be done. What's still missing
is pubnames/pubtypes I think, -fdebug-types-section works fine now.
But -gpubnames is not.
You can verify with a small testcase and -gpubnames [-flto] where
with -flto both .debug_pubtype and .debug_pubnames are missing.
But nobody complained in years so I gues -gpubnames is unused.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug debug/88878] .debug_pubnames/types empty with -flto
[not found] <bug-88878-4@http.gcc.gnu.org/bugzilla/>
2020-07-29 12:40 ` [Bug debug/88878] .debug_pubnames/types empty with -flto jan.kratochvil at redhat dot com
2020-07-29 12:51 ` rguenth at gcc dot gnu.org
@ 2020-07-29 13:20 ` jan.kratochvil at redhat dot com
2 siblings, 0 replies; 3+ messages in thread
From: jan.kratochvil at redhat dot com @ 2020-07-29 13:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878
--- Comment #9 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
(In reply to Richard Biener from comment #8)
> The .debug_types section isn't supposed to be output when in_lto_p
> (that's for the LTRANS units where we generally do not output any
> types into DWARF). Instead .debug_types has to be output during
> dwarf2out_early_finish when we write the declaration dwarf units,
> the "early" debug info. That should now be done.
Thanks for the explanation, I see -fdebug-types-section -flto does work with
trunk without any patch, great!
> You can verify with a small testcase and -gpubnames [-flto] where
> with -flto both .debug_pubtype and .debug_pubnames are missing.
I do not think anyone is interested in those, for DWARF-5 they are officially
removed:
http://www.dwarfstd.org/doc/DWARF5.pdf
* Replace the .debug_pubnames and .debug_pubtypes sections with a single and
more functional name index section, .debug_names .
And for DWARF-4 those were replaced by GNU .gdb_index .
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-07-29 13:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-88878-4@http.gcc.gnu.org/bugzilla/>
2020-07-29 12:40 ` [Bug debug/88878] .debug_pubnames/types empty with -flto jan.kratochvil at redhat dot com
2020-07-29 12:51 ` rguenth at gcc dot gnu.org
2020-07-29 13:20 ` jan.kratochvil at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).