[Bug target/82005] Early lto debug not implemented on Darwin

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005

--- Comment #45 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #44)
> 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.

> > > 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.

OK .. so I should resurrect a version of that that applies only for the LTO
cases (since the "normal" cases are expecting the optimisation below).

> 
> > 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?

When the consumer is dsymutil (or some other tool that expects this
optimisation, at least some versions of GDB can consume mach-o .o files)

It does what you'd expect - encodes the offset as an absolute value.

dsymutil (the debug linker) is walking the debug structures; so at each point
it knows what the offset relates to, thus avoiding the object storage and extra
time for the relocs.

ld64 does understand at least some of this (it has to handle at minimum FDEs) -
but I don't know without checking if it will ignore the debug relocs or not
(not been in that code recently).

> 
> > ====
> > 
> > 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.

OK.. it's on my TODO to try and simulate this by hand (at least I now have the
simple-object part done)