I reproduced the test you suggested and got following output: build/bin/lldb-mi --synchronous a.out < llvm/tools/lldb/lit/tools/lldb-mi/exec/lldb-mi-fail.test (gdb) -file-exec-and-symbols "a.out" ^done (gdb) ^done (gdb) =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0" ^done (gdb) ^done (gdb) ^done (gdb) ^done (gdb) ^done (gdb) ^done (gdb) ^done (gdb) ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"} (gdb) =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"} (gdb) ^done (gdb) ^running =thread-group-started,id="i1",pid="5075" (gdb) =thread-created,id="1",group-id="i1" =thread-selected,id="1" (gdb) =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ ld-2.23.so",loaded_addr="-",size="0" (gdb) =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x00007ffff7ffa000",size="0" (gdb) =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0" (gdb) =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ libc-2.23.so",loaded_addr="-",size="0" (gdb) =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ libc-2.23.so",loaded_addr="-",size="0" (gdb) =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1",exit-code="0" *stopped,reason="exited-normally" (gdb) ^done (gdb) ^done (gdb) ^error,msg="Resume timed out." (gdb) ^done (gdb)
As a command that needs a breakpoint to be hit I chose the -exec-next --thread 1. It's the same error which is seen on the bots. сб, 11 авг. 2018 г. в 6:27, Adrian Prantl <apra...@apple.com>: > That't interesting. Where you able to simulate the error seen on the bots > by inserting a sleep() unto the debugged program? > > -- adrian > > On Aug 10, 2018, at 5:06 PM, Александр Поляков <polyakov....@gmail.com> > wrote: > > It seems that lldb-mi in such a situation just hangs: > > build/bin/lldb-mi --synchronous bash > (gdb) > -file-exec-and-symbols "bash" > ^done > (gdb) > > =library-loaded,id="/bin/bash",target-name="/bin/bash",host-name="/bin/bash",symbols-loaded="0",loaded_addr="-",size="0" > -exec-run > ^C^C > exit > > It doesn't react to Ctrl+C and exit command. > > сб, 11 авг. 2018 г. в 2:54, Adrian Prantl <apra...@apple.com>: > >> >> >> On Aug 10, 2018, at 4:50 PM, Александр Поляков <polyakov....@gmail.com> >> wrote: >> >> One important question: what do you mean talking about "block"? Does it >> mean that SBTarget::Launch blocks the process and the user can't continue >> working with this process until it stops? >> >> >> Pretty much. The same way as the interactive (lldb) command line >> interface behaves: You enter "run" and you won't get a prompt again until >> the process stops. I'm imagining (but haven't verified) that synchronous >> mode behaves like that. >> >> -- adrian >> >> > > -- > Alexander > > > -- Alexander
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev