https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #44 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 25 Jul 2018, iains at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 > > --- Comment #43 from Iain Sandoe <iains at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #42) > > (In reply to Iain Sandoe from comment #40) > > > Created attachment 44417 [details] > > > Patch series to enable copying of early debug data. > > < snip> > (not ignoring the other options - but let's look at the possibilities to do it > a better way) > > > > - we seem to be jumping through quite a few hoops here, presumably > > > because > > > it's too complex to emit the relevant data as markup into the LTO stream > > > directly? > > > > The issue is that we'd have to distribute _all_ early debug to _each_ > > LTRANS unit with late debug. That's N-fold duplication that I wanted > > to avoid... but yes, with the assembly scheme from above you could > > "prepend" each LTRANS unit with the "merged" early debug assembly. > > (at least N is limited by --param lto-partitions which defaults to 32...) > > hmm... > > > > Note that doing the assembling of the early debug during compile-time > > and then have the linker at the final link pick up that debug from the > > original objects as would have been my prefered way would be still the > > best for compile-time and disk-space usage. But of course it wouldn't > > work for DARWIN w/o assembler changes to support this kind of relocations. > > Darwin's assembler supports < undef symbol >+offset as a relocation. That's actually what we want... > with > "actual_target" the address we want > "< undef symbol >" the LTO "_sinus.c.f4d7e603" type symbol we emit > > I'm not too well up on DWARF specifics, probably time to RTFM... is the > intention of <undef symbol>+offset-Lcurrent_section_start a PC-rel form? (i.e. > does the "offset" roll any more in than the actual_target-< undef symbol >)? The -Lcurrent_section_start is zero because .debug_info gets relocated to zero. That is, we want the offset in the final .debug_info section where <undef symbol> points somewhere into it and offset is relative to that symbol. One of my "hacks" was to simply elide the minus in darwin_asm_output_dwarf_offset, if the section is a DWARF one. ISTR that worked "fine" (it fixed the assembler messages) but I didn't check the result further. > Normally, as I noted above, Darwin does things like > set $foo Ltarget_sym-Lcurrent_section_start > .long $foo > to render the inter-section-offset as an absolute value (i.e. eliding the > reloc.) which dsymutil can understand because it knows the section starts > already. So set $foo < undef symbol > - Lcurrent_section_start makes $foo + offset work as a relocation? > ==== > > So .. if we can > * copy the LTO early debug (renaming as now) > * omit ld -r operation on these (which will just produce 0 output) > * make the external refs into < undef symbol >+offset (where offset is > actual_target-symbol) > * defer the linking of the early debug copied objects until the final link. > > Then, since there will be references to the debug symbols in objects with > non-zero text/data, presumably the linker has to honour those. (I don't know > if it will, but it seems it should). > > this seems like something worth trying, before heading into the more > complicated stuff. > > maybe I can fake the steps by hand and try it .. > > WDYT? If the relocation issue can be solved then yes, we should be able to handle this. The ld -r step was just to avoid explosion in the number of input files for the final link - it currently doesn't save us very much on ELF either because .debug_str isn't string-merged by ld -r. So I think we can simply remove this step alltogether.
