[PATCH] D70524: Support DebugInfo generation for auto return type for C++ functions.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 6 10:03:25 PST 2019


dblaikie added a comment.

In D70524#1772961 <https://reviews.llvm.org/D70524#1772961>, @probinson wrote:

> > Perhaps we should implement this mode under -fno-standalone-debug (or something more aggressive) since "standalone" is one of the only places I can think of where having the full class definition would be handy
>
> You'd also want it for type units, so they deduplicate more reliably?  And probably should be DWARF only, not CodeView?  But yeah, I'm down for it.


It'd basically remove the need for type units entirely (& the DWARF would end up looking quite similar to DWARF using type units, just without the type units (well, you'd move the member variables from the type DIE In the type unit to the "skeleton" type DIE in the CU - but the member function handling looks very similar (because the skeleton type DIE ends up needing all the declarations of member functions in defined in the CU anyway - so the out of line definitions can refer to the member function declarations, their parameters, etc (since you can't refer to specific DIEs other than the total type DIE in a type unit)))).

Yeah, only for DWARF/I have no idea what CodeView can/would do.

> This tactic would depend on the debuggers knowing they are unlikely to get a full class description and shouldn't throw away any class they've "already seen."  I remember that was an issue with, uh, one of those other debuggers that I never use.  They might take the first one they see, and shrug off any others as not contributing anything really important.  That would have to change.

My understanding with GDB is that it tends to treat the types in independent CUs as being potentially independent - you can violate the ODR and see that reflected in the type descriptions depending on where you print the type from (eg: print the type while you're debugging one function in one TU and you get that TU's view of the type, then step into a function in another TU and print the type and you get that TU's view of the type).

Yeah, it's not high on my list & starting with the DWARF consumers would be the right place.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70524/new/

https://reviews.llvm.org/D70524





More information about the llvm-commits mailing list