> So try using "S11" to start with, but quickly transition over to using > "T11thread:XXXX;key:value;..." if you can
I went with "T11thread:XXXX;..". It worked. Thanks a lot. On Wed, Sep 26, 2012 at 12:18 AM, Greg Clayton <[email protected]> wrote: > The problem stems from the "S00" being returned in response to the "?" > packet. If you can return "S11" for the first stop, this should fix your > issue. The problem is the "S00" currently means "there is no important reason > why we stopped". Usually the debugger only stops due to a breakpoint, > exception, watchpoint, exit, or other exceptional event. So currently when > you stop for no apparent reason, we just continue. If it is hard to return > "S11" only for the first stop, you can always return it until you can provide > a better stop reply packet with more info. An example stop reply packet from > x86_64 is: > > > $T11thread:1c03;qaddr:a0;threads:1c03;02:0000000000000000;03:0000000000000000;04:0000000000000000;05:0000000000000000;06:0000000000000000;07:40f8bf5fff7f0000;08:0000000000000000;09:0000000000000000;10:2810c05fff7f0000;11:0002000000000000;metype:5;mecount:2;medata:10003;medata:11;#00 > > Breaking this down: > > # Stop for thread with signal SIGSTOP > T11 > > # The thread this stop info is for > thread:1c03; > > # the full thread list in stop reply which is enabled by replying "OK" to > "QListThreadsInStopReply" > threads:1c03; > > # expedited register values > 02:0000000000000000; > 03:0000000000000000; > 04:0000000000000000; > 05:0000000000000000; > 06:0000000000000000; > 07:40f8bf5fff7f0000; > 08:0000000000000000; > 09:0000000000000000; > 10:2810c05fff7f0000; > 11:0002000000000000; > > # mach specific exception info that no one else needs to emit > metype:5; > mecount:2; > medata:10003; > medata:11; > > #00 > > > So try using "S11" to start with, but quickly transition over to using > "T11thread:XXXX;key:value;..." if you can > > On Sep 24, 2012, at 8:47 PM, chansarav <[email protected]> wrote: > >>> 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
