<div dir="ltr">Hi Everybody,<div><br></div><div>Just wanted to drop a note regarding status debug_macro DWARFv5 section. </div><div>I've started looking into debug_macro section. </div><div>Soon incremental patches will follow.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div>Should we stop emitting this ?? this is on purpose.</div><div>Note: this behavior persists, even when specifying "-fno-debug-macro" option explicitly.</div><div><br></div><div>sourabh@llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-clang -ggdb min_macro.c<br>sourabh@llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-llvm-readelf -S a.out | awk /debug/<br> [23] .debug_info PROGBITS 0000000000000000 0030bc 00005a 00 0 0 1<br> [24] .debug_abbrev PROGBITS 0000000000000000 003116 000043 00 0 0 1<br> [25] .debug_line PROGBITS 0000000000000000 003159 000045 00 0 0 1<br> [26] .debug_str PROGBITS 0000000000000000 00319e 0000a5 01 MS 0 0 1<br> [27] .debug_macinfo PROGBITS 0000000000000000 003243 000001 00 0 0 1</div><div><br>sourabh@llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-llvm-dwarfdump -debug-macro a.out<br>a.out: file format ELF64-x86-64<br>.debug_macinfo contents:<br></div><div><br></div><div>sourabh@llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-llvm-readelf -x.debug_macinfo a.out<br>Hex dump of section '.debug_macinfo':<br>0x00000000 00<br></div><div><br></div><div>Thanks,</div><div>Sourabh.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 1:58 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Ah, thanks for the list - mostly I'm interested in cases where Clang's<br>
> output is not valid DWARFv5 when requested - the new features DWARFv5<br>
> enables/allows but doesn't require are lower priority to me. Which I<br>
> don't think too much is left - DWARFv5 loclists in split DWARF is one<br>
> I know of & might get to if someone else doesn't do it before me - I'm<br>
> currently improving loclist emission (quality of implementation - using<br>
> fewer address pool entries & just general code cleanup to share some of<br>
> teh implementation with rnglist emission, not a compliance issue)<br>
<br>
You might want to look at default location entry then; particularly if a <br>
variable moves around but has a stack home, it can reduce the number of <br>
entries and maybe eliminate some .debug_addr references.<br></blockquote><div><br>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.<br><br>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).<br><br>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.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
--paulr<br>
<br>
</blockquote></div></div>
</blockquote></div>