[lldb-dev] porting lldb for a VLIW architecture

[chansarav]

Thank you. I worked further with your guidance. Kindly see my response
embedded below.


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

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

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
> "/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.
>

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

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.
Added Plugins/ABI/SysV-vliw)

Now on running "lldb --arch vliw app.elf" I get the following error:

error: '/home/chandra/app01/workplace/app.elf' doesn't contain the
architecture vliw

On debugging I found the error is while resolving the executable

-- cut --

if (exe_arch.IsValid())
{
    error = ModuleList::GetSharedModule (resolved_exe_file,
					 exe_arch,
					 NULL,
					 NULL,
					 0,
					 exe_module_sp,
					 NULL,
					 NULL);

    if (exe_module_sp->GetObjectFile() == NULL)
    {
	exe_module_sp.reset();
	error.SetErrorStringWithFormat ("'%s%s%s' doesn't contain the architecture %s",
					exe_file.GetDirectory().AsCString(""),
					exe_file.GetDirectory() ? "/" : "",
					exe_file.GetFilename().AsCString(""),
					exe_arch.GetArchitectureName());
    }
}

-- cut --
file: lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
Method: PlatformLinux::ResolveExecutable()

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
>