This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Allow target to emit LTO early debug to a separate LTO file.


> On 23 Aug 2018, at 12:37, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> On Thu, Aug 23, 2018 at 1:19 PM Tom de Vries <tdevries@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.

Thanks for looking at this, apologies my question was phrased badly
 (I was trying to make sure that it was conceptually sound, i.e that the
FAT portion of the asm output could be handled distinctly from the LTO).

It seemed to make sense, since the LTO stuff can stand alone.

This is still experimental; it’s not clear if it will provide a mechanism to 
solve the problems, but your suggestions are noted and I’ll incorporate
in my next update.

thanks
Iain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]