aprantl added inline comments.
================ Comment at: lldb/include/lldb/Symbol/Function.h:304 +public: + CallEdge(const char *mangled_name, lldb::addr_t return_pc); + ---------------- 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. https://reviews.llvm.org/D50478 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
