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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
