On 02/10/2018 06:34 AM, Richard Biener wrote:
> On February 10, 2018 1:53:41 PM GMT+01:00, Alexandre Oliva
> <aol...@redhat.com> wrote:
>> I was shocked when you, richi, reported huge debug info growth after
>> the
>> LVU and IEPM patches went in. At first, I suspected IEPM, due to
>> possibly keeping more lexical blocks around, but my investigation
>> showed
>> a lot of the growth was actually due to switching from asm-generated
>> line number sections to gcc-generated ones, which we do when locviews
>> are requested but the assembler has no support for view assignments in
>> .loc directives.
>>
>> It then occurred to me that we could compute view numbers on the side,
>> and I jumped at it before recalling there were complications I was
>> already familiar with, namely that .loc directives (without views)
>> don't
>> necessarily bind to '.': they bind to the next instruction, which might
>> even be in a different section. This makes for some complications,
>> verbosely described in comments in dwarf2out.c. I'm reasonably happy
>> with the result, that passed visual inspection on some reasonably
>> tricky
>> cases, but there's unfortunately no way I can think of to test
>> mechanically that the views we get from gas-generated line number
>> programs correspond to the views we compute from the labels introduced
>> by the patch. Although we might get view numbers wrong in some unknown
>> cases, that we'll only notice for real once we have loc view support in
>> debuggers, since actual insns are sync (reset) points for views, odds
>> are they will be in sync at most points of interest.
>>
>> So, do you think the far more compact debug_line sections are worth the
>> risk of some out-of-sync view counts, for those who already use gas,
>> just not 2.30? Or should we instead default to disabling views when
>> the
>> assembler doesn't have native support for them, as you had suggested?
>>
>> (I haven't looked yet into the other debug_info growth, most certainly
>> caused by IEPM-preserved lexical blocks; that's next up, but I'll need
>> another sleep cycle first, I'm afraid)
>>
>> WDYT?
>
> I think it makes sense to disable them by default if gas doesn't support them
> with that ability to override the auto detection by a configure switch (get
> the GCC generated ones). The patch looks too heavy for this stage and as you
> say we lack support on the consumer side anyways. We can revisit this patch
> for GCC 9 or simply document the recommendation of using gas 2.30 or newer.
Seems reasonable to me as well.
jeff
