[Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames

[Vedant Kumar via Phabricator via lldb-commits]

vsk added inline comments.


================
Comment at: lldb/include/lldb/Symbol/Function.h:304
+public:
+  CallEdge(const char *mangled_name, lldb::addr_t return_pc);
+
----------------
aprantl wrote:
> vsk wrote:
> > vsk wrote:
> > > aprantl wrote:
> > > > Does this also work for C functions? If yes, would `symbol_name` be a more accurate description?
> > > > 
> > > > Is this pointer globally unique in the program, or can two mangled names appear in a legal C program that don't refer to the same function?
> > > Yes, C functions are handled. I'll use "symbol_name", hopefully that makes it clearer.
> > Great question. No, a symbol name is not necessarily globally unique. Prior to C11, the one-definition-rule doesn't apply. Even with the ODR, a private symbol in a shared library may have the same name as a strong definition in the main executable.
> > 
> > I haven't tried to disambiguate ODR conflicts in this patch. What happens when a conflict occurs is: `FindFunctionSymbols` prioritizes the symbol in the main executable, and if the call edge's return PC doesn't exactly match what's in the register state we decline to create any artificial frames. I.e. in the presence of ODR conflicts, we only present artificial frames when we're 100% sure they are accurate.
> > 
> > Handling ODR conflicts is a 'to do', though. I'll make an explicit note of that here.
> Thanks! It might be interesting to grep through an XNU dsym to see just how common conflicts are in typical C code.
Of a total of ~27,000 function names in xnu, 140 names were duplicates. In every case I spot-checked, a subprogram with a duplicate AT_name had a unique AT_linkage_name. So, well under 0.5% in that project.


https://reviews.llvm.org/D50478