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