On Thu, Aug 23, 2018 at 1:19 PM Tom de Vries <tdevr...@suse.de> wrote: > > On 08/22/2018 10:09 PM, Iain Sandoe wrote: > > Hi Tom, Richi, > > > > This is something I was experimenting with to try and solve platform > > problems with early debug. > > > > Not a “finished patch” > > Hmm, not a building patch either. > > > (I’ve removed the Darwin back-end parts) but would like your comments on > > the central idea. > > > > This is to switch to the alternate LTO file (this process already exists > > for the actual LTO output) > > It took me a while to realize that you're talking about darwin here, > specifically the lto_start/end hooks. > > > before the early debug is started and switch back to the regular output > > file after. Therefore both the LTO early debug and the LTO streamed data > > end up in a separate file (this can be concatenated as we do now, > > guaranteeing that it appears after any referenced symbols, or could be > > handled in “some other way” if that was a useful solution). > > > > Now the second part of this delays the output of the .file directives until > > the “regular” output of the asm (it could be that this could be simplified > > now there there’s a start/end function pair). > > > > The idea is that the main output text is identical with/without the early > > debug (and, in fact, it’s broken without this change - since the .file > > directives would end up in the separate LTO stream). > > > > thoughts? > > Iain > > > > I found it hard to understand the above with something concrete to look > at. So I've written attach patch (targeted for my regular x86_64 linux > development platform) that adds comments in the assembly when > transitioning from one generation phase to another. > > So, the effect of the patch on vla-1.c -flto -g is: > ... > $ diff -I '\.section' -I '\.byte' -u 1 2 > --- 1 2018-08-23 12:24:37.426659159 +0200 > +++ 2 2018-08-23 12:26:46.886658665 +0200 > @@ -1,6 +1,6 @@ > .file "vla-1.c" > +# LTO_START > # DWARF2OUT_EARLY_FINISH START > - .file 1 > "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c" > .section .gnu.debuglto_.debug_info,"e",@progbits > .Ldebug_info0: > .hidden vla_1.c.1d3f9cc3 > @@ -330,15 +330,8 @@ > .byte 0 > .byte 0 > .byte 0x1 > - .ascii > "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/gual" > - .ascii "ity" > .byte 0 > .byte 0 > - .string "vla-1.c" > - .uleb128 0x1 > - .uleb128 0 > - .uleb128 0 > - .byte 0 > .LELTP0: > .LELT0: > .section .gnu.debuglto_.debug_str,"eMS",@progbits,1 > @@ -358,8 +351,9 @@ > .string > "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c" > .text > # DWARF2OUT_EARLY_FINISH END > +# LTO_END > # LTO_START > - .section .gnu.lto_.profile.b9a985e7cc2d09b4,"e",@progbits > + .section .gnu.lto_.profile.922c9ad53427823c,"e",@progbits > .string "x\234\343````\004b\006" > .string "" > .string "V" > @@ -635,6 +629,7 @@ > .type bar, @function > bar: > .LFB0: > + .file 1 > "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c" > .loc 1 7 1 > .cfi_startproc > .LVL0: > ... > > So, emitting the dwarf2 .file ALAP looks ok to me, and I think that can > be a separate patch. I wonder though if you really need a separate state > variable delay_emit_file to track this, and if you can't use > early_dwarf/early_dwarf_finished. > > As for adding lto_start/end around dwarf2out_early_finish, the lto_start > hook is defined as: > ... > Output to asm_out_file any text which the assembler expects to find at > the start of an LTO section. > ... > > Looking at the current implementation of this hook, adding this new call > pair shouldn't hurt, but perhaps we want to clarify in the documentation > that the "LTO section" can also be a debug LTO section?
I think we should adjust the documentation since they now called multiple times, bracketing LTO section output. So targets implementing the hook would need to take care of keeping track of whether it's the first call to lto_begin. Richard. > > Thanks, > - Tom
