================
@@ -162,7 +164,17 @@ class Symbol : public SymbolContextScope {
bool SetReExportedSymbolSharedLibrary(const FileSpec &fspec);
- Symbol *ResolveReExportedSymbol(Target &target) const;
+ /// Find the symbol this re-exported symbol resolves to.
+ ///
+ /// The library recorded on the symbol is searched first. If
+ /// \p containing_module_sp is provided, the libraries re-exported by that
+ /// module (ObjectFile::GetReExportedLibraries()) are then searched in
+ /// order. This matches the DT_FILTER / DT_AUXILIARY behavior in ELF, where
+ /// a filter library may reference multiple filtees and the dynamic linker
+ /// searches them in the order they appear in the dynamic section.
----------------
DavidSpickett wrote:
So in other words, we make lldb act like the dynamic linker?
Just checking I understand this. Because:
> This matches the DT_FILTER / DT_AUXILIARY behavior in ELF
Makes it sound like the behaviour is in the ELF or in these DT_ whatever, but
it's really how the dynamic linker treats those things.
So another way to put it is that LLDB treats ELF DT_... the same way as dynamic
linkers do. Which is ...
What you've written is fine as it is, just want to make sure I understand it as
it's not the way I would have phrased it myself.
https://github.com/llvm/llvm-project/pull/208905
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
