jimingham wrote: It's never the case on Darwin that you know nothing about a loaded shared library. You will always know at least its name, UUID, and load addresses. It doesn't matter whether the binary exists on disk or not, we will always be able to reconstruct at least a skeleton form from the loader's information.
So thinking just about Darwin, I'd opine that you should never totally omit information about a loaded library. If the loader tells you about it, you should at least make its presence available even if you can't reconstruct much information from it. The ELF behavior surprises me, I would have definitely though it was a bug that the absence of the library on disk would cause the library to totally disappear from a debug session that was clearly using it. That seems to me like information we really should try to surface the user. I really haven't played around with ELF much so I'm not up on how lossy it can be. In the case where you've deleted the library on disk is there really NOTHING that lldb can tell you about that loaded library? Jim > On Feb 18, 2025, at 12:15 AM, Pavel Labath ***@***.***> wrote: > > > labath > left a comment > (llvm/llvm-project#127153) > I'm not convinced of that this change needs to be happen in ScriptedProcess > ... May be we could have a setting to not discard all modules loaded in case > 1 of them failed to load that would also work with other Process plugins. > @jimingham what do you think ? > > I'm confused. Isn't that already what happens for non-scripted processes? > > $ lldb -n a.out -o "image list" -b > (lldb) process attach --name "a.out" > Process 11191 stopped > * thread #1, name = 'a.out', stop reason = signal SIGSTOP > frame #0: 0x00007f7083e088e4 libc.so.6`pause + 20 > libc.so.6`pause: > -> 0x7f7083e088e4 <+20>: cmpq $-0x1000, %rax ; imm = 0xF000 > 0x7f7083e088ea <+26>: ja 0x7f7083e08920 ; <+80> > 0x7f7083e088ec <+28>: retq > 0x7f7083e088ed <+29>: nopl (%rax) > Executable module set to "/tmp/X/a.out". > Architecture set to: x86_64-pc-linux-gnu. > (lldb) image list > [ 0] 171A52C4 0x000056532dec0000 /tmp/X/a.out > [ 1] 421DCFD2-138A-B321-D6F1-7AFD7B7FC999-F79CA445 0x00007ffdeb3a5000 [vdso] > (0x00007ffdeb3a5000) > [ 2] 838926F7 0x00007f7083f45000 libb.so <====== LIBB.SO HERE > [ 3] C88DE6C8 0x00007f7083d1f000 /lib64/libc.so.6 > /usr/lib/debug/lib64/libc.so.6.debug > [ 4] D626A570 0x00007f7083f4c000 /lib64/ld-linux-x86-64.so.2 > $ rm libb.so <========= FILE DELETED > $ lldb -n a.out -o "image list" -b > (lldb) process attach --name "a.out" > Process 11191 stopped > * thread #1, name = 'a.out', stop reason = signal SIGSTOP > frame #0: 0x00007f7083e088e4 libc.so.6`pause + 20 > libc.so.6`pause: > -> 0x7f7083e088e4 <+20>: cmpq $-0x1000, %rax ; imm = 0xF000 > 0x7f7083e088ea <+26>: ja 0x7f7083e08920 ; <+80> > 0x7f7083e088ec <+28>: retq > 0x7f7083e088ed <+29>: nopl (%rax) > Executable module set to "/tmp/X/a.out". > Architecture set to: x86_64-pc-linux-gnu. > (lldb) image list <===== LIBB.SO MISSING (BUT OTHER MODULES STILL THERE) > [ 0] 171A52C4 0x000056532dec0000 /tmp/X/a.out > [ 1] 421DCFD2-138A-B321-D6F1-7AFD7B7FC999-F79CA445 0x00007ffdeb3a5000 [vdso] > (0x00007ffdeb3a5000) > [ 2] C88DE6C8 0x00007f7083d1f000 /lib64/libc.so.6 > /usr/lib/debug/lib64/libc.so.6.debug > [ 3] D626A570 0x00007f7083f4c000 /lib64/ld-linux-x86-64.so.2 > I got this on linux. On darwin, the module might still be present because it > might be read from process memory directly. Still, if that failed for some > reason (perhaps because instead of a live process we were dealing with a core > file -- one which does not include the module contents in the dump), I would > expect other modules to be present. > > Rejecting all of them because one couldn't be found seems to go against our > "do our best to keep going with limited info" philosophy. > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you were mentioned. > > <https://github.com/jimingham> > <https://github.com/llvm/llvm-project/pull/127153#issuecomment-2664898119> > <https://github.com/notifications/unsubscribe-auth/ADUPVW72PO3RURTHZHULBDD2QLT3NAVCNFSM6AAAAABXDQPSSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRUHA4TQMJRHE> > > labath > left a comment > (llvm/llvm-project#127153) > <https://github.com/llvm/llvm-project/pull/127153#issuecomment-2664898119> > I'm not convinced of that this change needs to be happen in ScriptedProcess > ... May be we could have a setting to not discard all modules loaded in case > 1 of them failed to load that would also work with other Process plugins. > @jimingham <https://github.com/jimingham> what do you think ? > > I'm confused. Isn't that already what happens for non-scripted processes? > > $ lldb -n a.out -o "image list" -b > (lldb) process attach --name "a.out" > Process 11191 stopped > * thread #1, name = 'a.out', stop reason = signal SIGSTOP > frame #0: 0x00007f7083e088e4 libc.so.6`pause + 20 > libc.so.6`pause: > -> 0x7f7083e088e4 <+20>: cmpq $-0x1000, %rax ; imm = 0xF000 > 0x7f7083e088ea <+26>: ja 0x7f7083e08920 ; <+80> > 0x7f7083e088ec <+28>: retq > 0x7f7083e088ed <+29>: nopl (%rax) > Executable module set to "/tmp/X/a.out". > Architecture set to: x86_64-pc-linux-gnu. > (lldb) image list > [ 0] 171A52C4 0x000056532dec0000 /tmp/X/a.out > [ 1] 421DCFD2-138A-B321-D6F1-7AFD7B7FC999-F79CA445 0x00007ffdeb3a5000 [vdso] > (0x00007ffdeb3a5000) > [ 2] 838926F7 0x00007f7083f45000 libb.so <====== LIBB.SO HERE > [ 3] C88DE6C8 0x00007f7083d1f000 /lib64/libc.so.6 > /usr/lib/debug/lib64/libc.so.6.debug > [ 4] D626A570 0x00007f7083f4c000 /lib64/ld-linux-x86-64.so.2 > $ rm libb.so <========= FILE DELETED > $ lldb -n a.out -o "image list" -b > (lldb) process attach --name "a.out" > Process 11191 stopped > * thread #1, name = 'a.out', stop reason = signal SIGSTOP > frame #0: 0x00007f7083e088e4 libc.so.6`pause + 20 > libc.so.6`pause: > -> 0x7f7083e088e4 <+20>: cmpq $-0x1000, %rax ; imm = 0xF000 > 0x7f7083e088ea <+26>: ja 0x7f7083e08920 ; <+80> > 0x7f7083e088ec <+28>: retq > 0x7f7083e088ed <+29>: nopl (%rax) > Executable module set to "/tmp/X/a.out". > Architecture set to: x86_64-pc-linux-gnu. > (lldb) image list <===== LIBB.SO MISSING (BUT OTHER MODULES STILL THERE) > [ 0] 171A52C4 0x000056532dec0000 /tmp/X/a.out > [ 1] 421DCFD2-138A-B321-D6F1-7AFD7B7FC999-F79CA445 0x00007ffdeb3a5000 [vdso] > (0x00007ffdeb3a5000) > [ 2] C88DE6C8 0x00007f7083d1f000 /lib64/libc.so.6 > /usr/lib/debug/lib64/libc.so.6.debug > [ 3] D626A570 0x00007f7083f4c000 /lib64/ld-linux-x86-64.so.2 > I got this on linux. On darwin, the module might still be present because it > might be read from process memory directly. Still, if that failed for some > reason (perhaps because instead of a live process we were dealing with a core > file -- one which does not include the module contents in the dump), I would > expect other modules to be present. > > Rejecting all of them because one couldn't be found seems to go against our > "do our best to keep going with limited info" philosophy. > > — > Reply to this email directly, view it on GitHub > <https://github.com/llvm/llvm-project/pull/127153#issuecomment-2664898119>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADUPVW72PO3RURTHZHULBDD2QLT3NAVCNFSM6AAAAABXDQPSSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRUHA4TQMJRHE>. > You are receiving this because you were mentioned. > https://github.com/llvm/llvm-project/pull/127153 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
