[lldb-dev] porting lldb for a VLIW architecture

[chansarav]

> 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
>