llvm dev - Oct 2019 - DebugInfo work contribution and update.

On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <paul.robinson at sony.com>
wrote:
> > Ah, thanks for the list - mostly I'm interested in cases where
Clang's
> > output is not valid DWARFv5 when requested - the new features DWARFv5
> > enables/allows but doesn't require are lower priority to me. Which
I
> > don't think too much is left - DWARFv5 loclists in split DWARF is
one
> > I know of & might get to if someone else doesn't do it before
me - I'm
> > currently improving loclist emission (quality of implementation -
using
> > fewer address pool entries & just general code cleanup to share
some of
> > teh implementation with rnglist emission, not a compliance issue)
>
> You might want to look at default location entry then; particularly if a
> variable moves around but has a stack home, it can reduce the number of
> entries and maybe eliminate some .debug_addr references.
>
I don't think it'd reduce debug_addr references - I'm setting it up
to only
use the base address of the function start and everything's offset pairs
from there, so loclists shouldn't create any addr entries, only using
existing ones needed for the function's low_pc/CU's ranges, etc.

I don't know what our current variable location tracking would ever likely
manage to preserve the location information enough for it to cover the
whole scope (or at least not often) & then pick a default location as the
most common used location across that scope. (I'm guessing almost any
optimizations will cause some part of the address range of the enclosing
scope to lose locations).

If we do actually hit that case (probably would be worth building a DWARF
statistic (even a temporary one) that tests whether a location list
describes the entire address range of the enclosing scope - I'm guessing
that happens roughly never at the moment) we could look into improving the
DWARF emission to be more compact by using the default.

- Dave

> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191010/9dc1e31d/attachment.html>

Hi Everybody,

Just wanted to drop a note regarding status debug_macro DWARFv5 section.
I've started looking into debug_macro section.
Soon incremental patches will follow.

One query regarding clang behavior for debug_macinfo section -- Now, I
understand that to enable macro information and for gdb able to expand
macros, clang needs "-fdebug-macro". Default is not to emit debug info
for
macros.

But consider below dump, is this Okay to have a empty{Size 1 byte}
debug_macinfo section to be emitted ?? when we are not emitting macro info
at all.
Should we stop emitting this ?? this is on purpose.
Note: this behavior persists, even when specifying "-fno-debug-macro"
option explicitly.

sourabh at llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-clang -ggdb
min_macro.c
sourabh at llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-llvm-readelf -S a.out
| awk /debug/
  [23] .debug_info       PROGBITS        0000000000000000 0030bc 00005a 00
     0   0  1
  [24] .debug_abbrev     PROGBITS        0000000000000000 003116 000043 00
     0   0  1
  [25] .debug_line       PROGBITS        0000000000000000 003159 000045 00
     0   0  1
  [26] .debug_str        PROGBITS        0000000000000000 00319e 0000a5 01
 MS  0   0  1
  [27] .debug_macinfo    PROGBITS        0000000000000000 003243 000001 00
     0   0  1

sourabh at llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-llvm-dwarfdump
-debug-macro a.out
a.out:  file format ELF64-x86-64
.debug_macinfo contents:

sourabh at llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-llvm-readelf
-x.debug_macinfo a.out
Hex dump of section '.debug_macinfo':
0x00000000 00

Thanks,
Sourabh.

On Fri, Oct 11, 2019 at 1:58 AM David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <paul.robinson at
sony.com>
> wrote:
>
>> > Ah, thanks for the list - mostly I'm interested in cases where
Clang's
>> > output is not valid DWARFv5 when requested - the new features
DWARFv5
>> > enables/allows but doesn't require are lower priority to me.
Which I
>> > don't think too much is left - DWARFv5 loclists in split DWARF
is one
>> > I know of & might get to if someone else doesn't do it
before me - I'm
>> > currently improving loclist emission (quality of implementation -
using
>> > fewer address pool entries & just general code cleanup to
share some of
>> > teh implementation with rnglist emission, not a compliance issue)
>>
>> You might want to look at default location entry then; particularly if
a
>> variable moves around but has a stack home, it can reduce the number of
>> entries and maybe eliminate some .debug_addr references.
>>
>
> I don't think it'd reduce debug_addr references - I'm setting
it up to
> only use the base address of the function start and everything's offset
> pairs from there, so loclists shouldn't create any addr entries, only
using
> existing ones needed for the function's low_pc/CU's ranges, etc.
>
> I don't know what our current variable location tracking would ever
likely
> manage to preserve the location information enough for it to cover the
> whole scope (or at least not often) & then pick a default location as
the
> most common used location across that scope. (I'm guessing almost any
> optimizations will cause some part of the address range of the enclosing
> scope to lose locations).
>
> If we do actually hit that case (probably would be worth building a DWARF
> statistic (even a temporary one) that tests whether a location list
> describes the entire address range of the enclosing scope - I'm
guessing
> that happens roughly never at the moment) we could look into improving the
> DWARF emission to be more compact by using the default.
>
> - Dave
>
>
>> --paulr
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191018/412fd854/attachment.html>

> One query regarding clang behavior for debug_macinfo section -- Now, I
> understand that to enable macro information and for gdb able to expand
> macros, clang needs "-fdebug-macro". Default is not to emit debug
info
> for macros.
>
> But consider below dump, is this Okay to have a empty{Size 1 byte}
> debug_macinfo section to be emitted ?? when we are not emitting macro
> info at all. 
> Should we stop emitting this ?? this is on purpose.
> Note: this behavior persists, even when specifying
"-fno-debug-macro"
> option explicitly.
I believe we set up all the sections internally regardless of options,
just for simpler bookkeeping, and then emit only the ones we actually 
want to produce.  Emitting an essentially empty .debug_macinfo section 
with -fno-debug-macro would be a bug.
--paulr