[lldb-dev] porting lldb for a VLIW architecture
chansarav at gmail.com
Tue Sep 11 05:52:02 PDT 2012
Thank you. I worked further with your guidance. Kindly see my response
On Tue, Aug 28, 2012 at 2:49 AM, Greg Clayton <gclayton at apple.com> wrote:
> 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
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.
> > 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.
> > 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.
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
> - 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
> 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.
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
> > 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
> > 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?
> Let me know what other questions you have,
> Greg Clayton
More information about the lldb-dev