[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
Mon Dec 16 12:34:54 PST 2019


dblaikie added a comment.

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

> > Hmm, maybe this feature/suggestion is broken or at least not exactly awesome when it comes to auto-returning functions that are eventually void-returning functions? Now the function definition has no DW_AT_type to override the unspecified_type in the declaration... :/ that's unfortunate (@probinson - thoughts?)
>
> Normally, the DW_AT_specification on the definition would mean, look at the declaration for additional attributes, such as DW_AT_type.  However, the declaration's unspecified_type means, look at the definition.  The definition omits DW_AT_type, therefore the return type is "void".
>  It's a wee bit circular, but I think it's not unreasonable to expect the consumer to figure this out.


Fair enough. I think that's pretty awkward, but don't feel strongly enough to say that's bad/wrong - it's what GCC does, it's probably what GDB understands, etc.

Test cases/functionality need to be fixed here, because currently the deduced type isn't being carried on the function definition (it just "works out" for the limited testing provided - because the test is testing void return, but adding/changing the test to test non-void return should expose the bug)

Also - I think this probably should be enabled even pre-DWARFv5. GDB does that and unspecified_type is available pre-v5 & it saves having a divergence in the frontend for v5 generation which I think is probably good (I don't think we have that as a hard line, but I'd tend to think it's a direction we should generally lean in - where the DWARF version is handled by the metadata attribute and the backend for the most part/where possible).


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

https://reviews.llvm.org/D70524





More information about the llvm-commits mailing list