[lldb-dev] porting lldb for a VLIW architecture

[Greg Clayton]

On Aug 27, 2012, at 2:39 AM, chansarav <chansarav at gmail.com> wrote:

> Hi,
> 
> I am to port lldb for a VLIW architecture. I am entirely new to lldb. But have some experience in porting gdb for the same architecture.
> 
> Somemore insight on my problem of porting lldb for the VLIW architecture. The lldb is to connect the (VLIW architecture) simulator remotely. Both the lldb and the simulator are to run on the linux machine. (the host machine is the linux machine - Ubuntu).
> 
> The simulator already has the RSP server support with it (which already worked well with my 'gdb port for this architecture'). Now I want lldb in place of gdb.

When you say "The simulator already has the RSP server support", does this mean the port implements the GDB remote protocol? Or a custom debug protocol?

> 
> On searching for a starting point on lldb port, I found very few references in the form of few mails at lldb-dev mailing list.
> 
> lists.cs.uiuc.edu/pipermail/lldb-dev/2012-January/000770.html
> 
> With this I got the below understanding on my lldb porting tasks to that VLIW architecture. 
> 
> 1. To port lldb for the VLIW architecture, it is must to have the llvm ported to that VLIW architecture. This is because lldb uses few modules of llvm for some functionalities such as expressions evaluation, disassembling.

Yes.

> 2. With llvm ported for the VLIW architecture, in my case following are the lldb modules I have to consider for porting:
>     a. Platform plug-in
>     b. ABI plug-in
>     c. Process plug-in

Yes, unless the port to your simulator uses the GDB remote protocol, it which case you can skip step 'c' above. If your simulator does implement the GDB remote protocol, let me know, else, you will need to subclass "lldb_private::Process" into a new process plug-in. This plug-in will also subclass lldb_private::Thread.

> 
> 3. Platform refers to the host OS on which the lldb runs. In my case I am to run the lldb on linux platform. And since lldb has the support for linux platform, I am not required to do anything on this.

Platform plug-ins do a few things:
- locate paths for files mentioned during a remote debug session.
- locate debug symols for executable files (in case they are separate)
- upload/download files
- install applications (which is an extension of uploading a file as you might have to register the application with the OS)
- list processes
- attach and launch processes
- more

The main thing to note is if you have version 1.2.3 of linux on your local machine and you debug a binary on a 2.3.4 version of linux, you might be asked to locate "/usr/lib/libfoo.so" on your system. If you have a complete copy of the binaries on your local system for the remote 2.3.4 machine, the platform plug-in will be responsible for mapping "/usr/lib/libfoo.so" to "/users/jsmith/src/linux/2.3.4/root/usr/lib/libfoo.so". 

The platform also gets to state which architectures it supports so that the platform can be auto selected when given a binary that doesn't match the current host. For example:

% lldb --arch armv6 a.out
Current executable set to 'a.out' (armv6).
(lldb) target list
Current targets:
* target #0: /Volumes/work/gclayton/Documents/devb/attach/a.out ( arch=armv6-apple-ios, platform=remote-ios )

This was run on an x86_64 Mac, but since the binary "a.out" didn't contain "x86_64" or "i386" architectures, LLDB used the currently installed platforms to determine which platform to use. In this case it was "remote-ios". It knew this becauase the "remote-ios" is the only platform that supports the arm architecture currently. The target triple can be further filled out to ensure the propper plug-ins (platform + process + dynamic loader + os plug-in + abi) get selected.

So if you started your LLDB with:

% lldb --arch vliw-<vendor>-<os> a.out

We can select the correct plugins. Is there a vendor and os for the VLIW target? If not, you can always specify "vliw-unknown-unknown" which means, no vendor and no OS, and this can still help the plug-ins to determine which plug-ins will be selected.



> 
> Doubt: Under the Platform plug-in, I see there is a folder "gdb-server". I don't understand the significance of this. Should I consider this for my case? 

Not unless you want to implement a "lldb-platform" plug-in that runs on the VLIW simulator that implements all of the functionality of the Platform plug-ins.

> 
> 4. ABI refers to the target architecture description such as the register information, call frame information etc. So I have to create a class for my VLIW architecture (which is a sub-class of lldb_private::ABI). 

ABI is for calling convention stuff like when making function calls with simple arguments, where (which register or stack offset) will the arguments be? Also what name mangling is used for the VLIW ABI? If it is the Itanium, you can probably subclass the existing Itanium ABI plug-in for VLIW.

> 
> 5. Process refers to the module that connects lldb to the remote module. lldb has gdb-remote already supported. And hence I am not required to do anything on this.
> 
> Can someone help me to go further on this?

If your simulator supports the GDB remote protocol, you should be ready to try and connect once you get the "vliw" architecture added to LLVM and into LLDB. 

Let me know what other questions you have,

Greg Clayton