DavidSpickett added a comment.
I'm not familiar with this mechanism but just out of curiosity: `ld.so loads
the main executable and any dependent shared libraries and wants to update the
"_r_debug" structure, but it now finds "_r_debug" in the a.out program and
updates the state in this other copy`
Is this some undefined behaviour or is there a good use case for this? From the
program's point of view.
================
Comment at:
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp:260-266
+ // the dynamic loader. The problem happens as soon as the executable or
+ // shared library that exports another "_r_debug" is loaded by the dynamic
+ // loader due to the way symbols are found using the shared library search
+ // paths will mean that the new copy takes precedence over the one in the
+ // dynamic loader and the dynamic loader will be updating the other copy
+ // somewhere else that we won't find and that copy will have the
+ // eConsistent state.
----------------
Can we split this sentence just for readability? Bullet points of each step
might be clearer.
================
Comment at:
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py:22
+ @no_debug_info_test
+ @skipIf(oslist=["linux"], archs=["arm"])
+ def test(self):
----------------
Any specific reason for this? Not that it really matters, it'll get plenty of
testing elsewhere.
================
Comment at:
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py:28
+ exe = self.getBuildArtifact("a.out")
+ print(exe)
+ target = self.dbg.CreateTarget(exe)
----------------
Leftover debug print.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D158583/new/
https://reviews.llvm.org/D158583
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
