Its good to know you had a file specified. Now you will need to start higher up and step down through the launch starting in lldb_private::Process::Launch() and see where things go wrong.
Greg On Aug 23, 2013, at 7:56 AM, chansarav <[email protected]> wrote: > > IS this what is going on? If so, just give lldb the executable file: > > No. I initiated lldb with the arguments "--arch vliw-unknown-unknown > workplace/app.elf". But I haven't mentioned in my previous mail. > > $lldb > (lldb) log enable gdb-remote packets > (lldb) target create --arch vliw-unknown-unknown workplace/app.elf > Current executable set to 'workplace/app.elf' (vliw). > (lldb) process connect --plugin gdb-remote connect://localhost:51000 > < 1> send packet: + > history[1] tid=0xb1cbe9d0 < 1> send packet: + > < 19> send packet: $QStartNoAckMode#b0 > < 1> read packet: + > < 4> read packet: $#00 > < 1> send packet: + > < 26> send packet: $QThreadSuffixSupported#e4 > < 1> read packet: + > < 4> read packet: $#00 > < 1> send packet: + > < 27> send packet: $QListThreadsInStopReply#21 > < 1> read packet: + > < 4> read packet: $#00 > < 1> send packet: + > < 13> send packet: $qHostInfo#9b > < 1> read packet: + > < 84> read packet: > $cputype:201;cpusubtype:-2;ostype:unknown;vendor:unknown;endian:little;ptrsize:4;#90 > < 1> send packet: + > < 10> send packet: $vCont?#49 > < 1> read packet: + > < 15> read packet: $vCont[;c;s]#0e > < 1> send packet: + > < 27> send packet: $qVAttachOrWaitSupported#38 > < 1> read packet: + > < 4> read packet: $#00 > < 1> send packet: + > < 6> send packet: $qC#b4 > < 1> read packet: + > > < 7> read packet: $QC0#c4 > < 1> send packet: + > (lldb) process launch > > I debugged lldb to check the "ProcessGDBRemote::DoLaunch()" method. But the > execution didn't reach this function for the above said communication. > > Actually after the "process connect" the state is set to "eStateConnected". > So the "process launch" should call the "DoLaunch()" method of "gdb-remote" > process plugin. But lldb hangs on the last line of the following code snip. > > (snip start) > if (error.Success()) > { > const char *archname = > exe_module->GetArchitecture().GetArchitectureName(); > > //result.AppendMessageWithFormat ("Process %llu launched: '%s' > (%s)\n", process->GetID(), filename, archname); > result.SetDidChangeProcessState (true); > if (m_options.launch_info.GetFlags().Test(eLaunchFlagStopAtEntry) > == false) > { > result.SetStatus (eReturnStatusSuccessContinuingNoResult); > StateType state = process->WaitForProcessToStop (NULL); > (snip end) > file: lldb/source/Commands/CommandObjectProcess.cpp > method: CommandObjectProcessLaunch::DoExecute() > > > On Thu, Aug 22, 2013 at 10:21 PM, Greg Clayton <[email protected]> wrote: > You probably didn't give LLDB a file with "target create". If you look at the > "ProcessGDBRemote::DoLaunch (...)" function, it gets the object file from the > target's executable module to ensure there is something to launch: > > > ObjectFile * object_file = exe_module->GetObjectFile(); > if (object_file) > { > > ... send 'A' packet > > } > > > It really doesn't make sense to run a program that has no executable and has > no arguments. If you have a simulator that is debugging something already, > then you must reply with a non-zero PID to the "qC" packet. Below your > packets were: > > < 6> send packet: $qC#b4 > < 1> read packet: + > < 7> read packet: $QC0#c4 > < 1> send packet: + > > This is telling us, we are connected, but aren't debugging anything yet. > There is a bug in LLDB right now if this is the case where we aren't > propagating an error back from Process::Launch() correctly stating the 'A' > packet can't be sent without a valid executable. > > IS this what is going on? If so, just give lldb the executable file: > > (lldb) target create --arch <ARCH> /path/to/local/copy/of/sim/exe/a.out > (lldb) process connect --plugin gdb-remote connect://localhost:51000 > > On Aug 21, 2013, at 10:14 PM, chansarav <[email protected]> wrote: > > > Thanks for the reply. > > > > I enabled the packet logging in LLDB. > > > > (lldb) log enable gdb-remote packets > > (lldb) process connect --plugin gdb-remote connect://localhost:51000 > > < 1> send packet: + > > history[1] tid=0xb1d819d0 < 1> send packet: + > > < 26> send packet: $QThreadSuffixSupported#e4 > > < 1> read packet: + > > < 4> read packet: $#00 > > < 1> send packet: + > > < 27> send packet: $QListThreadsInStopReply#21 > > < 1> read packet: + > > < 7> read packet: $E01#a6 > > < 1> send packet: + > > < 10> send packet: $vCont?#49 > > < 1> read packet: + > > < 15> read packet: $vCont[;c;s]#0e > > < 1> send packet: + > > < 27> send packet: $qVAttachOrWaitSupported#38 > > < 1> read packet: + > > > > < 6> send packet: $qC#b4 > > < 1> read packet: + > > < 7> read packet: $QC0#c4 > > < 1> send packet: + > > (lldb) run > > > > After this lldb just hangs. lldb doesn't send any packet after the 'run' > > command. I debugged by inserting a breakpoint in lldb's code which sends > > the 'A' packet. And that breakpoint was not hit. > > > > > > > > On Wed, Aug 21, 2013 at 10:31 PM, Greg Clayton <[email protected]> wrote: > > The "process launch" command should send the 'A' packet, and it is waiting > > for a stop reply response from the 'A' packet. Try enabling the packet > > logging in LLDB: > > > > (lldb) log enable gdb-remote packets > > (lldb) process connect ... > > (lldb) run > > > > My guess is that the 'A' packet isn't responding with a stop reply packet. > > > > On Aug 21, 2013, at 7:47 AM, chansarav <[email protected]> wrote: > > > > > Hi, > > > > > > I am connecting lldb with my simulator through 'gdb-remote' process > > > plugin. After extablishing the connection, I want to issue the 'process > > > launch' command in lldb which should send the arguments packet 'A' to > > > simulator asking it to launch the program. > > > > > > I am facing the problem while issuing the 'process launch' command in > > > lldb. When I give the 'process launch' command, lldb hangs and there is > > > no communication with simulator. When I debugged with gdb, I got the > > > backtrace as follows: > > > > > > #2 0xb6703a6f in lldb_private::Condition::Wait (this=0x8077dac, > > > mutex=..., abstime=0x0, timed_out=0xbfffaa9f) at > > > /home/chandra/llvm-3.1/tools/lldb/source/Host/common/Condition.cpp:92 > > > #3 0xb662768d in lldb_private::Predicate<bool>::WaitForValueEqualTo > > > (this=0x8077d90, value=true, abstime=0x0, timed_out=0xbfffaa9f) at > > > /home/chandra/llvm-3.1/tools/lldb/source/Core/../../include/lldb/Host/Predicate.h:317 > > > #4 0xb662b03f in lldb_private::Listener::WaitForEventsInternal > > > (this=0x8077d3c, timeout=0x0, broadcaster=0xadb0179c, > > > broadcaster_names=0x0, num_broadcaster_names=0, event_type_mask=3, > > > event_sp=...) at > > > /home/chandra/llvm-3.1/tools/lldb/source/Core/Listener.cpp:409 > > > #5 0xb662b1f7 in > > > lldb_private::Listener::WaitForEventForBroadcasterWithType > > > (this=0x8077d3c, timeout=0x0, broadcaster=0xadb0179c, event_type_mask=3, > > > event_sp=...) at > > > /home/chandra/llvm-3.1/tools/lldb/source/Core/Listener.cpp:440 > > > #6 0xb69421ec in lldb_private::Process::WaitForStateChangedEvents > > > (this=0xadb01788, timeout=0x0, event_sp=...) at > > > /home/chandra/llvm-3.1/tools/lldb/source/Target/Process.cpp:1069 > > > #7 0xb6941f2c in lldb_private::Process::WaitForProcessToStop > > > (this=0xadb01788, timeout=0x0) at > > > /home/chandra/llvm-3.1/tools/lldb/source/Target/Process.cpp:977 > > > #8 0xb6587d98 in CommandObjectProcessLaunch::DoExecute (this=0x80813d0, > > > launch_args=..., result=...) at > > > /home/chandra/llvm-3.1/tools/lldb/source/Commands/CommandObjectProcess.cpp:220 > > > #9 0xb672c999 in lldb_private::CommandObjectParsed::Execute > > > (this=0x80813d0, args_string=0xb4d667bc "", result=...) at > > > /home/chandra/llvm-3.1/tools/lldb/source/Interpreter/CommandObject.cpp:856 > > > #10 0xb67215d3 in lldb_private::CommandInterpreter::HandleCommand > > > (this=0x8077fc8, command_line=0x883a614 "process launch", > > > lazy_add_to_history=lldb_private::eLazyBoolYes, result=..., > > > override_context=0x0, repeat_on_empty_command=true, > > > no_context_switching=false) at > > > /home/chandra/llvm-3.1/tools/lldb/source/Interpreter/CommandInterpreter.cpp:1571 > > > #11 0xb64e0ced in lldb::SBCommandInterpreter::HandleCommand > > > (this=0xbfffc2cc, command_line=0x883a614 "process launch", result=..., > > > add_to_history=true) at > > > /home/chandra/llvm-3.1/tools/lldb/source/API/SBCommandInterpreter.cpp:97 > > > #12 0x0805a103 in Driver::HandleIOEvent (this=0xbfffec7c, event=...) at > > > /home/chandra/llvm-3.1/tools/lldb/tools/driver/Driver.cpp:996 > > > #13 0x0805b516 in Driver::MainLoop (this=0xbfffec7c) at > > > /home/chandra/llvm-3.1/tools/lldb/tools/driver/Driver.cpp:1430 > > > #14 0x0805bbf2 in main (argc=4, argv=0xbfffede4, envp=0xbfffedf8) at > > > /home/chandra/llvm-3.1/tools/lldb/tools/driver/Driver.cpp:1562 > > > > > > Though I am analyzing on this, Can someone help me in finding out what > > > goes wrong while trying to launch a program in simulator through > > > 'gdb-remote' process plugin? > > > > > > > > > Following is the communication between lldb and simulator for the > > > "process connect --plugin gdb-remote connect://localhost:51000" command. > > > > > > Send Packet: QStartNoAckMode: 15 chars > > > Read Packet: > > > Send Packet: QThreadSuffixSupported: 22 chars > > > Read Packet: > > > Send Packet: QListThreadsInStopReply: 23 chars > > > Read Packet: E01 > > > Send Packet: qHostInfo: 9 chars > > > Read Packet: > > > cputype:201;cpusubtype:-2;ostype:unknown;vendor:unknown;endian:little;ptrsize:4; > > > Send Packet: vCont?: 6 chars > > > Read Packet: vCont[;c;s] > > > Send Packet: qVAttachOrWaitSupported: 23 chars > > > Read Packet: > > > Send Packet: qC: 2 chars > > > Read Packet: QC0 > > > > > > LLDB sets the status as connected after this communication. > > > (snip start) > > > if (pid == LLDB_INVALID_PROCESS_ID) > > > { > > > // We don't have a valid process ID, so note that we are connected > > > // and could now request to launch or attach, or get remote > > > process > > > // listings... > > > SetPrivateState (eStateConnected); > > > } > > > (snip end) > > > function: ProcessGDBRemote::DoConnectRemote () > > > > > > Thanks, > > > Chandra Kumar R. > > > _______________________________________________ > > > lldb-dev mailing list > > > [email protected] > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
