labath accepted this revision. labath added a comment. This revision is now accepted and ready to land.
In D134518#3811382 <https://reviews.llvm.org/D134518#3811382>, @alvinhochun wrote: > In D134518#3811218 <https://reviews.llvm.org/D134518#3811218>, @labath wrote: > >> Ok, so is there any harm in keeping them this way? >> >> The symbols may not be very useful, but I would not say that they are >> useless. If, for whatever reason, the user finds himself inspecting the part >> of the memory covered by the forwarder string, then with this symbol, that >> memory would symbolicate as `forwarded_symbol+X`, which seems nice. > > I guess you're right, we can keep these symbols. Though do you think it make > sense to synthesize a demangled name for the symbol, let's say `ExportName > (forwarded to kernel32.LoadLibrary)`? Possibly. Are these basically the same as "undefined" (i.e., defined by another shared library) symbols on ELF? If so, then it may make sense to mark them as eSymbolTypeUndefined, in case some generic algorithm wants to do something with them. I believe MachO also has this notion of forwarding a symbol to a particular shared library (I think they call it "two-level namespacing"), so you may want to look at how those are represented. But overall, I don't think this is particularly important, and we can change this later if we have a need for it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134518/new/ https://reviews.llvm.org/D134518 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
