On Tue, Sep 11, 2012 at 6:22 PM, chansarav <[email protected]> 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 <[email protected]> wrote: >> >> >> On Aug 27, 2012, at 2:39 AM, chansarav <[email protected]> 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 >> _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
