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