[llvm] [RFC] Emit dwarf data for signature-changed or new functions (PR #157349)

Vladislav Dzhidzhoev via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 2 14:07:07 PDT 2025


dzhidzhoev wrote:

> > So in my opinion, having two DW_TAG_subprogram's at the same level with identical func name probably will break some tools. WDYT?
> 
> I don't think this is a problem, especially when functions have different signatures. For example, DWARF in [0] has two DW_TAG_subprograms at the same level with the same DW_AT_names, and I think the majority of tools will easily process it.
> 
> >

A quick note on that. I remembered the message from the discussion in https://github.com/llvm/llvm-project/pull/127855:
> > One possible alternate solution is to have an attribute on the `DW_TAG_subprogram` DIE that points to a function type DIE from the original source.
> 
> Seems like it'd be a substantial diversion from existing practice - now the primary subprogram wouldn't reflect the source anymore & debuggers unaware of the extra attribute/content would render something confusing to the user (describing the function to the user in a way that doesn't match the source) - overload resolution and other features in the debugger might behave in unexpected ways.

I think, having two functions with the same DW_AT_name but different formal parameters may indeed interfere with debugger name resolution (users will be able to call the function with the signature not matching the signature from the source code). 
Probably, DW_TAG_subprogram with the final list of parameters (`0x01c2663c:   DW_TAG_subprogram` in your example) should have DW_AT_artifical to prevent that (it can be emitted by raising DIFlagArtificial in the corresponding DISubprogram).


https://github.com/llvm/llvm-project/pull/157349


More information about the llvm-commits mailing list