> To work around the issues above, first you want to launch lldb (or "target > create") with > a full triple: > > lldb --arch vliw-unknown-unknown /home/chandra/app01/workplace/app.elf > > Then you can specify the process plug-in to use: > > (lldb) process connect --plugin gdb-remote connect://localhost:51000 > > If you specify the "gdb-remote" plug-in by name, you won't end up trying to > launch with > the "ProcessLinux" plug-in which doesn't support remote connections. It will > use the > ProcessGDBRemote plugin. > > Let me know if this help/works.
We did as you said above. And we faced following error as shown below: $lldb --arch vliw-unknown-unknown /home/chandra/app01/workplace/app.elf Current executable set to '/home/chandra/app01/workplace/app.elf' (vliw). (lldb) process connect --plugin gdb-remote connect://localhost:51000 error: Unable to find process plug-in for remote URL 'process connect'. Please specify a process plug-in name with the --plugin option, or specify an object file using the "file" command. For resolving the above error, we included the following line in method "lldb_private::Initialize ()" - ProcessGDBRemote::Initialize(); Now the connection is established. But the process exits immediately as shown below: $lldb --arch vliw-unknown-unknown /home/chandra/app01/workplace/app.elf Current executable set to '/home/chandra/app01/workplace/app.elf' (vliw). (lldb) process connect --plugin gdb-remote connect://localhost:51000 Process 1 exited with status = -1 (0xffffffff) lost connection This is because, after establishing the connection, lldb sends the 'c' packet to the gdb server (with the simulator). Which in-turn executes the application in the simulator. I have given the communication between lldb and gdb server (with the simulator). Send Packet: QThreadSuffixSupported Read Packet: Send Packet: qHostInfo Read Packet: cputype:201;cpusubtype:-2;ostype:unknown;vendor:unknown;endian:little;ptrsize:4; Send Packet: vCont? Read Packet: Send Packet: qC Read Packet: QC1 Send Packet: ? Read Packet: S00 Send Packet: qRegisterInfo0 Read Packet: name:r0;alt-name:sp;bitsize:32;offset:0;encoding:uint;format:hex;set:General Purpose Registers;gcc:0;dwarf:0;generic:sp; Send Packet: qRegisterInfo1 Read Packet: name:r1;alt-name:RT;bitsize:32;offset:8;encoding:uint;format:hex;set:General Purpose Registers;gcc:1;dwarf:1;generic:ra; Send Packet: qRegisterInfo2 Read Packet: name:r2;alt-name:P0;bitsize:32;offset:16;encoding:uint;format:hex;set:General Purpose Registers;gcc:2;dwarf:2;generic:arg1; .. .. .. Send Packet: qRegisterInfo53 Read Packet: name:r83;alt-name:NPC;bitsize:32;offset:664;encoding:uint;format:hex;set:General Purpose Registers;gcc:83;dwarf:83;generic:pc; Send Packet: qRegisterInfo54 Read Packet: E45 Send Packet: qfThreadInfo Read Packet: m1 Send Packet: qsThreadInfo Read Packet: l Send Packet: qThreadStopInfo1 Unrecognized packet: ignored Send Packet: Hg1 Read Packet: OK Send Packet: p53 Read Packet: 08010120 Send Packet: Hc-1 Read Packet: OK Send Packet: c <=========== this enables the application execution on simulator I hope 'process connect' is to establish the remote connection. And it should wait for further commands (break-point, run etc.). But here it starts the execution of the application. Now I am analyzing on this. Could you please help me on this? On Thu, Sep 13, 2012 at 3:05 AM, Greg Clayton <[email protected]> wrote: >> >> I fixed this. Actually there was a problem with the e_machine name >> with my elf file. >> >> And now on running the lldb, >> >> lldb --arch vliw /home/chandra/app01/workplace/app.elf >> Current executable set to '/home/chandra/app01/workplace/app.elf' (vliw). >> (lldb) target list >> Current targets: >> * target #0: /home/chandra/app01/workplace/app.elf ( >> arch=vliw-pc-linux-gnu, platform=localhost ) >> >> I see the platform selected is being shown as "localhost". I hope the >> platform selected should be "PlatformLinux". > >> >> And I face error on connecting the lldb with the simulator. >> >> (lldb) process connect connect://localhost:51000 >> error: remote connections are not supported > > This is probably because you have the PlatformLinux selected and it is trying > to connect to the current host linux in order to debug your program. > > If you don't have any specific platform needs (no special needs in locating > files, executables, upload/download files, etc) then you probably want no > platform plug-in selected, or make one up for VLIW. You are having trouble > launching because the local linux platform is selected and it is trying to > debug your program on the current linux host. > > When you create a target TargetList::CreateTarget() is called. It will try > and find an platform that goes with your executable and the triple you > specified. You want to step through this code and make sure that when > "PlatformLinux::CreateInstance()" is called, that it doesn't claim it is the > appropriate platform for your executable. > > To work around the issues above, first you want to launch lldb (or "target > create") with a full triple: > > lldb --arch vliw-unknown-unknown /home/chandra/app01/workplace/app.elf > > Then you can specify the process plug-in to use: > > (lldb) process connect --plugin gdb-remote connect://localhost:51000 > > If you specify the "gdb-remote" plug-in by name, you won't end up trying to > launch with the "ProcessLinux" plug-in which doesn't support remote > connections. It will use the ProcessGDBRemote plugin. > > Let me know if this help/works. > > Greg Clayton > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
