[lldb-dev] porting lldb for a VLIW architecture

[chansarav]

> 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 <gclayton at apple.com> 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 <chansarav at gmail.com> 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 <gclayton at apple.com> 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
>>>
>