[lldb-dev] porting lldb for a VLIW architecture

[chansarav]

On Tue, Sep 11, 2012 at 6:22 PM, chansarav <chansarav at gmail.com> wrote:
> 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?
>

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


>
>> Let me know what other questions you have,
>>
>> Greg Clayton
>>