It’s been a while since our team is investigating DebugInfo in LLVM, we’re looking forward to contribute and enhance in LLVM DebugInfo.
We,'ve been investigating mostly on DWARF-5 aspects – couple of them to mention–
Language aspects
Location mostly optimized out ones
DebugInfo conformance to DWARF-5
To avoid getting conflicted with some body else’s work and avoiding redundancy. We would like to know the over-all state of current community developments happening WRT DWARF-5.
As of now, we’re working on –
PR 43263, 43622 – reported today {Just Now}
we’ll be up-streaming patches for these.
Please let us know your thoughts, and anything else that’s relevant that we need to aware of before picking up.
+some other debugger people (Pavel - wasn’t sure which email address you prefer, feel free to let me know (privately or publicly) for future reference)
I work at Google & we’re certainly interested in DWARFv5 compliance - I’m currently working on improving debug_loclist emission to share more address pool entries ( https://reviews.llvm.org/D68620 ) which includes some improvements to llvm-dwarfdump to go with that. (Pavel’s working on further improvements https://reviews.llvm.org/D68271 )
I haven’t looked at/started on the loclist issue (PR43622) - so if you want to look at that, that’s fine by me.
Are you also interested in the debugger side of things? GDB’s DWARFv5 support is pretty incomplete & Ali’s already looking at some of that, and I might get to the debug_loclist improvements necessary - but if someone else wants to do that before me, I won’t complain.
Not sure of any other major holes in LLVM’s DWARFv5 support, but they might be out there, for sure.
Regarding, mail address, can use anyone{@gmail or @amd}. but sourav0311@gmail.com works best for me for mailing lists related stuff.
Regarding, GDB side of DWARFv5 side of things, we’ve testing GDB-8.3 WRT DWARFv5 clang and gcc binaries to get better idea of debuggability of clang generated binaries with GDB.
Primary motivation being GDB better handling of gcc generated binaries, compared to clang.
We’ve been also tracking Ali’s patches in gdb mailing list. Jini can update you better on, this one. Will ask her share update on this one.
There are many bits of DWARF-5 that haven’t been implemented. I know there is currently no big push within Sony to “fill in the corners” for v5, as we have been more focused on quality of debug info for optimized code (not losing information or reporting incorrect information) and the Dexter tool. There is no shortage of ways in which debug info for optimized code could be better; in general we are trying to post bug reports for anything we find that we’re not working on right away.
I think you are doing the right thing as far as coordinating with other people: Watch the llvm-commits and cfe-commits lists to notice when people are posting patches; post your own patches; and ask on the dev lists. If you decide to work on something that was reported as a bug, post a note there or assign the bug to yourself.
I looked up the two PRs you cited; PR43622 is likely a simple oversight that should be easy to fix. PR43263 doesn’t appear to be related to debug info, was that a typo?
There are many bits of DWARF-5 that haven’t been implemented.
Got a short list, by chance?
I can't say I've been keeping track of all that has gone in, but based
on the list that I came up with when I was sizing the initial DWARF 5
work, things that might not be done include:
Default location entry
Inline namespace attribute
Reference-qualified member functions
"auto" return type
Type/item alignment
Defaulted template parameter
Atomic type modifier
DW_OP_implicit_pointer
.debug_macro section
Typed expressions
Supplementary objects
Things I have noticed going in recently:
Call-site and entry-value stuff (is that complete?)
New language/dialect codes
Deleted/defaulted members is in progress
"noreturn" functions is in progress
I can't remember whether split-DWARF is fully v5 compliant...
If any items above are in fact done, my apologies and VERY happy to be
corrected.
--paulr
There are many bits of DWARF-5 that haven’t been implemented.
Got a short list, by chance?
I can't say I've been keeping track of all that has gone in, but based
on the list that I came up with when I was sizing the initial DWARF 5
work, things that might not be done include:
Default location entry
Inline namespace attribute
I think we may have this one already!
commit dbfda63695272c2d12a6a61b18b52d3961d8e1a8
Author: Adrian Prantl <aprantl@apple.com>
Add DWARF debug info support for C++11 inline namespaces.
This implements the DWARF 5 DW_AT_export_symbols feature: DWARF Issue: DW_AT_export_symbols
Yes, we are interested in the gdb side of things too – as Sourabh said, we have been following Ali’s patches. I think we will co-ordinate with Ali to see what gdb support for DWARF5 we can add so that we don’t tread on each other’s toes.
Yes, we are interested in the gdb side of things too – as Sourabh said, we have been following Ali’s patches. I think we will co-ordinate with Ali to see what gdb support for DWARF5 we can add so that we don’t tread on each other’s toes.
Thanks for the list, Paul. This is quite helpful. DW_OP_implicit_pointer is something that we are looking into currently. I believe that “Reference-qualified member functions” has also been implemented.
Like David said I am currently looking at the consumption side of debug_loclists, and my main angle is being able to reuse that parser in lldb (which has its own dwarf parser for the most part, but it is trying to move away from that). However, I've been busy with other stuff lately and so I haven't done much work there, but hopefully things will clear up now.
There are many bits of DWARF-5 that haven’t been implemented.
Got a short list, by chance?
I can’t say I’ve been keeping track of all that has gone in, but based
on the list that I came up with when I was sizing the initial DWARF 5
work, things that might not be done include:
Default location entry
Inline namespace attribute
Reference-qualified member functions
“auto” return type
Type/item alignment
Defaulted template parameter
Atomic type modifier
DW_OP_implicit_pointer
.debug_macro section
Typed expressions
Supplementary objects
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)
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.
--paulr
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.
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.
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
Yeah, there are a few places/times/situation where LLVM’s emitted empty DWARF sections - minor bug imho. (yes, a bug, but no one’s highest priority/pretty benign in the grand scheme of things - certainly if anyone wants to clean them up, that’s great, makes reading dumps easier, etc)