[llvm-dev] DebugInfo work contribution and update.

[Sourabh Singh Tomar via llvm-dev]

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>