Hi everyone, a few quick questions:
1. Is someone already planning on adding an LLVM-compatible build
system so that I can just stick lldb into llvm/tools/lldb and run
make?
2. What else is necessary to get this running on Linux, at least to
the point where it can parse an executable?
3. Is there some sort of overview of the architecture written up? I'm
finding it very hard to figure out what is where.
4. Are there plans to put up doxygen pages on the website?
-Eli
I just talked to Chris on IRC about this; apparently, nobody is
working on it, so I decided to take it on. I'll send messages as I
run into issues.
-Eli
Hi Eli,
Hi everyone, a few quick questions:
1. Is someone already planning on adding an LLVM-compatible build
system so that I can just stick lldb into llvm/tools/lldb and run
make?
Chris' answer is correct - no one is working on this right now, we've been using Xcode to build lldb. We'd be happy to have a makefile build setup.
2. What else is necessary to get this running on Linux, at least to
the point where it can parse an executable?
There's an ELF object file reader over at source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp but I don't know if Greg has tried running it on actual elf binaries yet. You'd want to look at include/lldb/Symbol/ObjectFile.h to see the ObjectFile interface that it is implementing.
Launching a process on Linux will involve a lot more work. lldb is designed to support multiple OSes/architectures/ABIs/etc but so far it has only been implemented on one; I'm sure there are unintentional Mac OS X assumptions. We are all very interested in seeing lldb ported to linux but I don't want to understate how much work would be involved in this.
3. Is there some sort of overview of the architecture written up? I'm
finding it very hard to figure out what is where.
Not much, we need to work on that. The header files are pretty descriptive; look in the include/lldb/ directory to start. The top level concepts to start with are Target, Module, and Process.
4. Are there plans to put up doxygen pages on the website?
I see no problem with that if it's helpful to people.
J
Hi Eli,
Hi everyone, a few quick questions:
1. Is someone already planning on adding an LLVM-compatible build
system so that I can just stick lldb into llvm/tools/lldb and run
make?
Chris' answer is correct - no one is working on this right now, we've been using Xcode to build lldb. We'd be happy to have a makefile build setup.
2. What else is necessary to get this running on Linux, at least to
the point where it can parse an executable?
There's an ELF object file reader over at source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp but I don't know if Greg has tried running it on actual elf binaries yet - it may just be a sketch of how that file needs to look. You'd want to look at include/lldb/Symbol/ObjectFile.h to see the ObjectFile interface that it is implementing.
Launching a process on Linux will involve a lot more work. lldb is designed to support multiple OSes/architectures/ABIs/etc but so far it has only been implemented on one; I'm sure there are unintentional Mac OS X assumptions. We are interested in seeing lldb ported to linux but I don't want to understate how much work would be involved in this -- and it's important to note that lldb is still early in its development and there are still large-scale internal reorganizations/reworkings/rethinkings happening on a regular basis; it may be a bit early to start porting it to other OSes. Or rather, it will be less difficult when the sources are a bit more mature.
3. Is there some sort of overview of the architecture written up? I'm
finding it very hard to figure out what is where.
Not much, we need to work on that. The header files are pretty descriptive; look in the include/lldb/ directory to start. The top level concepts to start with are Target, Module, and Process.
4. Are there plans to put up doxygen pages on the website?
I see no problem with that if it's helpful to people.
J
3. Is there some sort of overview of the architecture written up? I'm
finding it very hard to figure out what is where.Not much, we need to work on that. The header files are pretty descriptive; look in the include/lldb/ directory to start. The top level concepts to start with are Target, Module, and Process.
After WWDC is over, hopefully we can get some more high level docs into the tree.
4. Are there plans to put up doxygen pages on the website?
I see no problem with that if it's helpful to people.
Please ping me (and tanya) next week, this should be straight-forward to hook up on the server.
-Chris
Hi everyone, a few quick questions:
1. Is someone already planning on adding an LLVM-compatible build
system so that I can just stick lldb into llvm/tools/lldb and run
make?
You already have a great start on that Eli, thanks for heading this up.
2. What else is necessary to get this running on Linux, at least to
the point where it can parse an executable?
For linux I would first start by doing the following:
1 - ObjectFileELF.cpp
Fill in as many lldb_private::ObjectFile pure virtual function contents
as possible to make sure we get correct answers. Below are the important
ones with comments explaining what will need to be done:
// Look at the the ELF header "e_machine" and try and return a correct
// value for this whenever possible
virtual size_t
GetAddressByteSize () const = 0;
// Do ELF files have any notion of the other shared libraries that
// an executable ELF file or a shared library ELF file depend upon?
// If this can be determined, just fill in the file list. Else, don't
// worry about it (clear the file list and return zero).
virtual uint32_t
GetDependentModules (FileSpecList& file_list) = 0;
// Look at the the ELF header "e_machine" and try and return a correct
// value for this whenever possible. Any other info in the ELF file that
// can help determine the target triple for the current object file
// can help. If this can be determined, return false.
virtual bool
GetTargetTriple(ConstString &target_triple) = 0;
// Sections in LLDB are hierarchical and can contain other sections.
// This is currently implemented, and shouldn't need to be modified,
// though it would be good to load a linix ELF file and then check
// what was parsed using the lldb command:
// (lldb) imaage dump sections
// Just make sure eveything looks ok.
virtual SectionList *
GetSectionList () = 0;
// Make sure the symbol tables are being parsed correctly and that all
// symbols are being properly classified (see enum SymbolType and try
// to associate all symbols with a correct eSymbolTypeXXXX enumeration).
//
// Why? This helps us do more intelligent things with symbols and helps
// us limit the number of symbols we need to look through when looking
// for things by address (see Symtab::InitAddressIndexes() in Symtab.cpp).
//
// Many times we can tell what a symbol is just by the sections it is in,
// or many times the symbols themselves have a type in the native symbol
// table entry. Correctly classifying symbols allow users to grab all
// symbols of a particular type and index them all by name or by address.
virtual Symtab *
GetSymtab () = 0;
// Does linux store any UUID in ELF files? If not, feel free to return
// the md5 checksum of the ELF file itself.
virtual bool
GetUUID (UUID* uuid) = 0;
2 - After you have symbols loading, you will want to make a SymbolVendor for
linux. SymbolVendor objects know how to locate debug symbols for a given
executable. I am not sure how linux does this. Does linux have the DWARF
build into the ELF file? Does it store it somewhere else? The symbol vendor
is used by our lldb_private::Module class to provide all debug symbols for
a module. There is a default implementation that just uses the executable file
as the symbol file, but you might want to override this for linux if the
symbols are located in another file.
3 - Modify the DWARF plug-in to be able to find the DWARF in an ELF file.
MacOSX uses different section names for the DWARF "__debug_info" instead
of ".debug_info", "__debug_abbrev" instead of ".debug_abbrev", etc.
SymbolFileDWARF::GetAbilities ()
The above function will need to be modified to be able to check for both
styles of section names within an executable.
Once the correct ".debug_XXX" sections are being found, you should have
DWARF parsing. To test this parsing, you can load an executable that
contains debug info and do anything that involves debug symbols such as
setting a breakpoint by name:
(lldb) breakpoint set --name main
This will cause the DWARF to be parsed for all currently loaded modules
(your executable and any dependent shared libraries).
After you have object files and symbol files going it will be time to
create your lldb_private::Process and lldb_private::Thread subclasses
so you can start a debug session. Make a new plugin folder inside:
lldb/source/Plugins/Process/linux-user
And then check out ProcessMacOSX and ThreadMacOSX. There are many pure
virtual functions that need to be filled in from lldb_private::Process and
lldb_private::Thread.
That should be a great start to getting things going on linux. If you have
any questions, let me know.
3. Is there some sort of overview of the architecture written up? I'm
finding it very hard to figure out what is where.
That is in the works and will be up on the website as soon as we can get it
written up. Might be a few days before this is up, but I will try and get
it done ASAP.
4. Are there plans to put up doxygen pages on the website?
Yes, we need to update the header doc in many files and then we will try
and get this posted...
We're going to need to create a target OS plugin class that provides information like this soon. If we #ifdef it we'll be adding impediments to lldb doing cross-host debugging, e.g. debugging a Linux process from a Mac OS X box.
J
I wasn't suggesting #ifdef'ing anything, I was suggesting looking for a section named "__debug_info" and if not found, then look for ".debug_info" all from within the DWARF parsing plug-in.
Jim Ingham and I discussed how we wanted to fix this properly. I think adding enumerations for common sections that one might want to extract from an object file would be a good idea:
typedef enum CommonSectionType
{
eCommonSectionTEXT,
eCommonSectionDATA,
eCommonSectionBSS,
eCommonSectionDWARFDebugInfo,
eCommonSectionDWARFDebugAbbrev,
...
};
Then we have a way for the section list or the object file to return the section for by this enumeration. This will abtract us from the various file formats and their section naming quirks.
Greg Clayton