Thank you. I worked further with your guidance. Kindly see my response
> 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
Yes, simulator implements the GDB remote 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.
> 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.
> 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
My simulator implements the GDB remote protocol. So I can skip step 'c'.
> 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
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
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
* 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.
No and hence I shall specify "vliw-unknown-unknown". And in this case,
i saw the lldb taking the PlatformLinux plugin.
> 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
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
> 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
As said above my simulator supports the GDB remote protocol. Also the
"vliw" architecture has llvm supported already.
I added the "vliw" architecture to the lldb. (Updated the files -
lldb/Core/ArchSpec.h, lldb/lib/Makefile, llvm/tools/source/lldb.cpp.
Now on running "lldb --arch vliw app.elf" I get the following error:
error: '/home/chandra/app01/workplace/app.elf' doesn't contain the
On debugging I found the error is while resolving the executable
-- cut --
error = ModuleList::GetSharedModule (resolved_exe_file,
if (exe_module_sp->GetObjectFile() == NULL)
error.SetErrorStringWithFormat ("'%s%s%s' doesn't contain the architecture %s",
exe_file.GetDirectory() ? "/" : "",
-- cut --
I am further checking with the method "ModuleList::GetSharedModule ()".
Is there something i could have missed with lldb porting?