[lldb-dev] Stopping "stop reason = exec"
Hi all, Is there anything I can put into my lldb init script to prevent LLDB from stopping on exec? Every time I run a program I get this super irritating behavior: Thanks for any help! -Chris Process 20310 launched: '/Users/clattner/Projects/build/Xcode-ReleaseAssert+swift-DebugAssert/swift-macosx-x86_64/Debug/bin/swift' (x86_64) Process 20310 stopped * thread #2, stop reason = exec frame #0: 0x00010984f000 dyld`_dyld_start dyld`_dyld_start: -> 0x10984f000 <+0>: popq %rdi 0x10984f001 <+1>: pushq $0x0 0x10984f003 <+3>: movq %rsp, %rbp 0x10984f006 <+6>: andq $-0x10, %rsp Target 0: (swift) stopped. (lldb) ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Stopping "stop reason = exec"
There isn't a setting to auto-continue from exec. Definitely should be. If somebody wants to try their hand at it, just add a setting in parallel to stop-on-sharedlibrary-events and then add a ShouldStop to the StopInfoExec (StopInfo.cpp) that checks this setting. The StopInfoSignal does something equivalent, should be able to copy that. For macOS, you can also just do: (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld Breakpoint 2: where = dyld`_dyld_start, address = 0x0001b19c (lldb) b com add -o continue either in your .lldbinit or in your debug session. If you are using TOT lldb you can do: (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld --auto-continue 1 Jim > On Dec 4, 2017, at 3:29 PM, Chris Lattner via lldb-dev > wrote: > > Hi all, > > Is there anything I can put into my lldb init script to prevent LLDB from > stopping on exec? Every time I run a program I get this super irritating > behavior: > > Thanks for any help! > > -Chris > > > Process 20310 launched: > '/Users/clattner/Projects/build/Xcode-ReleaseAssert+swift-DebugAssert/swift-macosx-x86_64/Debug/bin/swift' > (x86_64) > Process 20310 stopped > * thread #2, stop reason = exec >frame #0: 0x00010984f000 dyld`_dyld_start > dyld`_dyld_start: > -> 0x10984f000 <+0>: popq %rdi >0x10984f001 <+1>: pushq $0x0 >0x10984f003 <+3>: movq %rsp, %rbp >0x10984f006 <+6>: andq $-0x10, %rsp > Target 0: (swift) stopped. > (lldb) > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Stopping "stop reason = exec"
> On Dec 4, 2017, at 3:50 PM, Jim Ingham wrote: > There isn't a setting to auto-continue from exec. Definitely should be. Yeah, I assumed that I could redefine my “r” alias to include this, but there is no flag to process launch. > > If somebody wants to try their hand at it, just add a setting in parallel to > stop-on-sharedlibrary-events and then add a ShouldStop to the StopInfoExec > (StopInfo.cpp) that checks this setting. The StopInfoSignal does something > equivalent, should be able to copy that. > > For macOS, you can also just do: > > (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld > Breakpoint 2: where = dyld`_dyld_start, address = 0x0001b19c > (lldb) b com add -o continue > either in your .lldbinit or in your debug session. This doesn’t appear to work, I tried both lldb and in a debug session. I’m starting lldb with “lldb -- swiftc … “ if that matters. (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld Breakpoint 1: where = dyld`_dyld_start, address = 0x1000 (lldb) b com add -o continue Breakpoint 2: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. > If you are using TOT lldb you can do: > (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld --auto-continue 1 I’m not :( -Chris ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Stopping "stop reason = exec"
> On Dec 4, 2017, at 4:25 PM, Chris Lattner wrote: >> For macOS, you can also just do: >> >> (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld >> Breakpoint 2: where = dyld`_dyld_start, address = 0x0001b19c >> (lldb) b com add -o continue >> either in your .lldbinit or in your debug session. > > This doesn’t appear to work, I tried both lldb and in a debug session. I’m > starting lldb with “lldb -- swiftc … “ if that matters. > > (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld > Breakpoint 1: where = dyld`_dyld_start, address = 0x1000 > (lldb) b com add -o continue > Breakpoint 2: no locations (pending). > WARNING: Unable to resolve breakpoint to any actual locations. I realize that this is probably because you’re not using the standard ‘b’ alias. When I use ‘br’, the command succeeds, but I still stop on launch: (lldb) br com add -o continue (lldb) r There is a running process, kill it and restart?: [Y/n] y Process 24049 exited with status = 9 (0x0009) Process 24054 launched: '/Users/clattner/Projects/build/Xcode-ReleaseAssert+swift-DebugAssert/swift-macosx-x86_64/Debug/bin/swiftc' (x86_64) Process 24054 stopped * thread #2, stop reason = exec frame #0: 0x000109852000 dyld`_dyld_start dyld`_dyld_start: -> 0x109852000 <+0>: popq %rdi 0x109852001 <+1>: pushq $0x0 0x109852003 <+3>: movq %rsp, %rbp 0x109852006 <+6>: andq $-0x10, %rsp Target 0: (swiftc) stopped. Thank you for the help, I appreciate it! -Chris ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] gdb-remote incompatibility with gdbserver?
My apologizes if this is mentioned somewhere already, couldn't find anything on the subject; it seems that gdb-remote doesn't work very well (or at all in my tests) with gdbserver. Tim Hammerquist was also able to reproduce issues when attempting to use gdb-remote with gdbserver. (Test with freebsd/gdbserver, freebsd/lldb38, freebsd/gdbserver, and macos/lldb-900.0.57.) Could we document this somewhere? It's not a large issue since there's alternatives like lldb-server and Facebook's ds2, but it's a bit confusing to new users who fairly expect a command called "gdb-remote" to work with gdbserver. root@17e840390f4d:~# lldb-3.8 date (lldb) target create "date" Current executable set to 'date' (x86_64). (lldb) # In another terminal: gdbserver localhost: /tmp/date (lldb) gdb-remote localhost: Process 6593 stopped * thread #1: tid = 6593, stop reason = signal SIGTRAP frame #0: 0x (lldb) c Process 6593 resuming Process 6593 stopped * thread #1: tid = 6593, stop reason = signal SIGTRAP frame #0: 0x (lldb) c Process 6593 resuming Process 6593 stopped * thread #1: tid = 6593, stop reason = signal SIGSEGV frame #0: 0x (lldb) c Process 6593 resuming Process 6593 exited with status = 11 (0x000b) Thanks, David Manouchehri ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] gdb-remote incompatibility with gdbserver?
lldb doesn't know what register set exists - if you do 'register read' you'll see that there are no registers. Maybe gdbserver doesn't implement the target.xml request (it's their packet definition! c'mon!) Download the x86_64 target def file from http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/ and load it in your .lldbinit file or on the cmd line lldb -O 'settings set plugin.process.gdb-remote.target-definition-file /path/to/def-file.py' > On Dec 4, 2017, at 5:56 PM, David Manouchehri via lldb-dev > wrote: > > My apologizes if this is mentioned somewhere already, couldn't find > anything on the subject; it seems that gdb-remote doesn't work very > well (or at all in my tests) with gdbserver. > > Tim Hammerquist was also able to reproduce issues when attempting to > use gdb-remote with gdbserver. (Test with freebsd/gdbserver, > freebsd/lldb38, freebsd/gdbserver, and macos/lldb-900.0.57.) > > Could we document this somewhere? It's not a large issue since there's > alternatives like lldb-server and Facebook's ds2, but it's a bit > confusing to new users who fairly expect a command called "gdb-remote" > to work with gdbserver. > > root@17e840390f4d:~# lldb-3.8 date > (lldb) target create "date" > Current executable set to 'date' (x86_64). > (lldb) # In another terminal: gdbserver localhost: /tmp/date > (lldb) gdb-remote localhost: > Process 6593 stopped > * thread #1: tid = 6593, stop reason = signal SIGTRAP >frame #0: 0x > (lldb) c > Process 6593 resuming > Process 6593 stopped > * thread #1: tid = 6593, stop reason = signal SIGTRAP >frame #0: 0x > (lldb) c > Process 6593 resuming > Process 6593 stopped > * thread #1: tid = 6593, stop reason = signal SIGSEGV >frame #0: 0x > (lldb) c > Process 6593 resuming > Process 6593 exited with status = 11 (0x000b) > > Thanks, > > David Manouchehri > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Stopping "stop reason = exec"
Yup, apparently debugserver tells us the stop is for exec directly so we don't treat it as a breakpoint hit. That sorta makes sense, you don't want to trigger a breakpoint hit every time you find a thread at the pc of a breakpoint (might be a thread that hit a breakpoint, then didn't get to run till the next stop.) But it defeats the obvious method. Anyway, it is a program stop, so you can use a stop hook: (lldb) target stop-hook add -n _dyld_start -o continue That one does work, though the stop-hook output is a little ugly. It would also be nice to specify stop-hooks by stop reason too. But this method does work... Jim > On Dec 4, 2017, at 4:36 PM, Chris Lattner wrote: > >> On Dec 4, 2017, at 4:25 PM, Chris Lattner wrote: >>> For macOS, you can also just do: >>> >>> (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld >>> Breakpoint 2: where = dyld`_dyld_start, address = 0x0001b19c >>> (lldb) b com add -o continue >>> either in your .lldbinit or in your debug session. >> >> This doesn’t appear to work, I tried both lldb and in a debug session. I’m >> starting lldb with “lldb -- swiftc … “ if that matters. >> >> (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld >> Breakpoint 1: where = dyld`_dyld_start, address = 0x1000 >> (lldb) b com add -o continue >> Breakpoint 2: no locations (pending). >> WARNING: Unable to resolve breakpoint to any actual locations. > > I realize that this is probably because you’re not using the standard ‘b’ > alias. When I use ‘br’, the command succeeds, but I still stop on launch: > > (lldb) br com add -o continue > (lldb) r > There is a running process, kill it and restart?: [Y/n] y > Process 24049 exited with status = 9 (0x0009) > Process 24054 launched: > '/Users/clattner/Projects/build/Xcode-ReleaseAssert+swift-DebugAssert/swift-macosx-x86_64/Debug/bin/swiftc' > (x86_64) > Process 24054 stopped > * thread #2, stop reason = exec > frame #0: 0x000109852000 dyld`_dyld_start > dyld`_dyld_start: > -> 0x109852000 <+0>: popq %rdi > 0x109852001 <+1>: pushq $0x0 > 0x109852003 <+3>: movq %rsp, %rbp > 0x109852006 <+6>: andq $-0x10, %rsp > Target 0: (swiftc) stopped. > > > Thank you for the help, I appreciate it! > > -Chris > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] gdb-remote incompatibility with gdbserver?
Thanks, that did the trick! Should I add this information to https://llvm.org/viewvc/llvm-project/lldb/trunk/www/ and submit a review on Phabricator? root@13bfa9bdf1e7:/# lldb-5.0 /bin/date (lldb) target create "/bin/date" Current executable set to '/bin/date' (x86_64). (lldb) settings set plugin.process.gdb-remote.target-definition-file ./x86_64_linux_target_definition.py (lldb) gdb-remote localhost: (lldb) Process 5221 stopped * thread #1, stop reason = signal SIGTRAP frame #0: 0x2aaabc30 -> 0x2aaabc30: movq %rsp, %rdi 0x2aaabc33: callq 0x2aaac9b0 0x2aaabc38: movq %rax, %r12 0x2aaabc3b: movl 0x225037(%rip), %eax For those who run into this message in the future, here's the exact commands I ran to get gdbserver working: wget -O - http://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add - sudo apt-add-repository "deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-5.0 main" sudo apt-get update sudo apt-get -y install lldb-5.0 gdbserver wget https://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py # In another terminal run: gdbserver localhost: /bin/date lldb-5.0 /bin/date settings set plugin.process.gdb-remote.target-definition-file ./x86_64_linux_target_definition.py gdb-remote localhost: ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
