[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #14 from Richard Guenther --- Ok, so let me try to revive the discussion and view the needs from a "need plugin support" angle. What I need is the linker to allow the plugin to claim only a subset of the sections of the input files (those not containing the early debug LTO sections) and direct the linker to feed the remaining sections (or a specially set of marked sections) to the final link, including the possibility to have it "rename" those sections. I am "abusing" the linker script syntax to direct the linker to do the renaming and selecting the set of sections we do not claim. So with that view on the issue how would you suggest to implement this plugin-API wise? (using linker script syntax in a plugin output like the BFD linker already accepts still looks appealing to me) Also when the user passes -g0 at the link command linke we should be able to drop those early debug sections and do not link them. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org --- The descripion in comment #12 is mostly correct as to the design and its constraints. Slight corrections below. At compile-stage with -flto we generate early-debug information to be consumed by the LTRANS output link. We also generate a separate set of full debug (early+late) for the FAT part of the compile-stage object. Yes, the LTO parts are supposed to be dropped when doing a FAT link, and yes, this was one reason to choose the .gnu.lto_ prefix. As for using a linker script to do the job of extracting and renaming the early-debug sections from the compile-stage objects I was hoping to avoid extra I/O and direct the linker to do that job when it links the LTRANS output objects. GNU ld seems to be happy to take a linker script as linker-plugin output (but we run into that section flag issue at least). Now for the current workaround I still use a linker-script and a partial link to do the section copying/renaming (but I still can't get rid of the 'E'xclude flag other than by linking an artifical object with debug-info sections not containing that flag - GNU ld seems to make sure a non-'E'xclude flag prevails if present on any input). Of course doing that partial link separate from the LTRANS object link involves extra I/O and disk-space. Note that going this far wasn't very difficult - in fact the approaches simplicity is why I chose it. The approach was also extensively discussed last year in the discussion about early-debug. Now if those implementation issues wouldn't exist... esp. that 'E'xclude flag as puts in on the section drives me crazy. I think I can fix the linker script doing the incremental link to also work with gold but it would of course be nice to avoid creating that extra (large) output file. As for using split-dwarf I did not want to start going on the route to effectively split the compile-time objects because I am sure we'll run into tooling issues with existing makefiles when we start doing that. Note that an additional constraint on the setup is that incrementally linking the compile-time objects has to work (the kernel does that), not sure what happens to split-dwarf here. split-dwarf is also not generated early but together with late debug. And we'd still need to link the .dwo files back into the executable because split dwarf is not something we can force to all of our users. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org --- This might be related to bug # 18835 - gas setting the 'E' flag on .gnu.lto_ sections (but not when explicitely stating MS). Can't find a way to make the script doing the partial link remove that flag. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Guenther from comment #3) Yes, They are not the same kind of IR as linker has seen so far. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org --- (In reply to H.J. Lu from comment #7) (In reply to Richard Guenther from comment #4) the extra sections contain early debug-info which gets refered to by LTRANS unit .debug_info. So it needs to be linked into the final executable / shared object and there get its mangled section name unmangled. I think they should have different section names. I assume that they can't be merged with normal .debug_xxx sections. On the contrary - they should be merged with the normal .debug_xxx sections emitted in the LTRANS assembly. The early-debug part of an example looks like 0166: Abbrev Number: 1 (DW_TAG_compile_unit) 167 DW_AT_producer: (indirect string, offset: 0x163): GNU C11 6.0.0 20150813 (experimental) -mtune=generic -march=x86-64 -g -flto -ffat-lto-objects 16b DW_AT_language: 12 (ANSI C99) 16c DW_AT_name: t.c 170 DW_AT_comp_dir: (indirect string, offset: 0x1c1): /abuild/rguenther/trunk-g/gcc 1174: Abbrev Number: 2 (DW_TAG_variable) 175 DW_AT_name: a 177 DW_AT_decl_file : 1 178 DW_AT_decl_line : 1 179 DW_AT_type: 0x17d 17d DW_AT_external: 1 117d: Abbrev Number: 3 (DW_TAG_base_type) 17e DW_AT_byte_size : 4 17f DW_AT_encoding: 5 (signed) 180 DW_AT_name: int 1184: Abbrev Number: 4 (DW_TAG_subprogram) 185 DW_AT_external: 1 185 DW_AT_name: (indirect string, offset: 0x1df): main 189 DW_AT_decl_file : 1 18a DW_AT_decl_line : 2 18b DW_AT_type: 0x17d and the LTRANS unit .debug_info parts refer to it like 019b: Abbrev Number: 1 (DW_TAG_compile_unit) 19c DW_AT_producer: 19d DW_AT_language: 12 (ANSI C99) 19e DW_AT_low_pc : 0x4004e6 1a6 DW_AT_high_pc : 0xc 1ae DW_AT_stmt_list : 0xe8 11b2: Abbrev Number: 2 (DW_TAG_imported_unit) 1b3 DW_AT_import : 0x166 [Abbrev Number: 1] 11b7: Abbrev Number: 3 (DW_TAG_subprogram) 1b8 DW_AT_abstract_origin: 0x184 1bc DW_AT_low_pc : 0x4004e6 1c4 DW_AT_high_pc : 0xc 1cc DW_AT_frame_base : 1 byte block: 9c(DW_OP_call_frame_cfa) 1ce DW_AT_GNU_all_call_sites: 1 11ce: Abbrev Number: 4 (DW_TAG_variable) 1cf DW_AT_abstract_origin: 0x174 1d3 DW_AT_location: 9 byte block: 3 3c 10 60 0 0 0 0 0 (DW_OP_addr: 60103c) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #10 from rguenther at suse dot de --- On Mon, 17 Aug 2015, hjl.tools at gmail dot com wrote: https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Guenther from comment #8) (In reply to H.J. Lu from comment #7) (In reply to Richard Guenther from comment #4) the extra sections contain early debug-info which gets refered to by LTRANS unit .debug_info. So it needs to be linked into the final executable / shared object and there get its mangled section name unmangled. I think they should have different section names. I assume that they can't be merged with normal .debug_xxx sections. On the contrary - they should be merged with the normal .debug_xxx sections emitted in the LTRANS assembly. The early-debug part of an example looks like Have you tried the debug_xxx.gnu.lto_ section name? That will merge with the FAT object part .debug_xxx which is not intended. It also does not share the property of .gnu.lto_* as being discarded by a non-LTO link via the default BFD linker script. Richard. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |WAITING CC||hjl.tools at gmail dot com --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- .gnu.lto_.* sections are special and should only be used for LTO IR. Are you using them to store LTO IR? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- *** Bug 18835 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org --- Yes, -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Guenther from comment #4) the extra sections contain early debug-info which gets refered to by LTRANS unit .debug_info. So it needs to be linked into the final executable / shared object and there get its mangled section name unmangled. I think they should have different section names. I assume that they can't be merged with normal .debug_xxx sections. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com --- (In reply to rguenther from comment #10) That will merge with the FAT object part .debug_xxx which is not intended. It also does not share the property of .gnu.lto_* as being discarded by a non-LTO link via the default BFD linker script. I think you should write down exactly what you need so that we can take a look at what linker, linker plugin and assembler should do. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836
Cary Coutant ccoutant at gmail dot com changed:
What|Removed |Added
CC||ccoutant at gmail dot com
--- Comment #12 from Cary Coutant ccoutant at gmail dot com ---
I think you should write down exactly what you need so that we can
take a look at what linker, linker plugin and assembler should do.
I agree. This discussion also applies (at least in part) to PR gold/18834 and
PR gold/18837, so for the time being, lets talk about all three PRs here.
Here's my understanding of what you're trying to do; please correct me where
I've got it wrong:
It sounds like you want to emit early and full debug in an LTO intermediate --
either fat or slim -- and then emit only late debug info in the LTRANS output.
(a) If you're linking with fat LTO objects and no LTO, you want to ignore the
early debug info, and link only the full debug info. Thus, you're putting the
early debug info into .gnu.lto_ sections, so they get ignored by default in a
non-LTO link.
(b) If you're linking with LTO, you want to go pick up the early debug info
from the LTO intermediate (without picking up any other sections from that
object), and add to that the late debug info from the LTRANS output.
For (b) to work, you seem to be hoping that writing a linker script with
something like this in it will pick up *just* the early debug info from t.o:
SECTIONS {
.debug_info : { t.o(.gnu.lto_.debug_info) }
.debug_abbrev : { t.o(.gnu.lto_.debug_abbrev) }
.debug_str : { t.o(.gnu.lto_.debug_str) }
}
Sorry, but I don't think that's going to do what you think it will do.
According to the linker manual, even if t.o isn't listed on the command line,
ld will link t.o as if it had been named on the command line. As a result,
you'll link all sections from t.o, including the fat text and data sections.
(Not to mention that gold does not implement this particular misfeature -- if
t.o isn't named on the command line, gold will not add it to the list of input
files.)
In order to get the early debug info from the LTO intermediate, you're going to
have to copy it into one of the LTRANS output .o files, and rename the section
such that it doesn't get excluded by default.
Using a linker script for this seems like a bad idea anyway. It would be a lot
cleaner to extend the plugin API to add whatever features you need, and we
probably should have been discussing that before you got this far.
Stepping back a bit, it sounds to me like you should be using split DWARF
instead. With split DWARF, the debug info in the .dwo sections, which gets
split into separate .dwo files, is pretty much all early debug info. The parts
remaining in the .o are late debug info, so the split has already been done,
and there's no need to try to get the linker to extract individual sections
from an LTO intermediate.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
