[lldb-dev] Questions from a Linux user

[Greg Clayton]

On Jun 8, 2010, at 10:01 PM, Eli Friedman wrote:

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

> 
> -Eli
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev