[Bug 16526] New: New API to scan executable for architectures before creating a target

Bug ID 16526
Summary New API to scan executable for architectures before creating a target
Product lldb
Version unspecified
Hardware All
OS All
Status NEW
Severity enhancement
Priority P
Component All Bugs
Assignee lldb-dev@cs.uiuc.edu
Reporter meeloo@meeloo.net
Classification Unclassified

Created attachment 10807 [details]
Diff to add lldb::SBDebugger::GetAvailableArchsFromFile

As I haven't found a way to scan available architectures from executables I'd
like to add that to the API. For now the only way to do somehow do that is to
loop over all known archs and try to create the SBTarget. Depending on its
success we mark the arch as valid or not. As you can guess this is very slow
and can be made mauch better as lldb already has all the code needed to get
this information without loading the full target. 

The public API for this could be added to SBDebugger:
static lldb::SBStringList lldb::SBDebugger::GetAvailableArchsFromFile(const
char* filename);

I have attached a patch implementing this feature.




Is there something I should do to have this patch proposal reviewed?



Your change currently allows architectures to be enumerated, but not .o files in a .a file. If you look closely at what the internal code is doing when it enumerates the module specifications, it can get a list of all architectures _and_ all .o files. If we expose this publicly, I would rather see a new SBModuleSpec and SBModuleSpecList class be created, and then we should be able to add a static function to SBModule that returns a SBModuleSpecList:

static SBModuleSpecList
SBModule::GetModuleSpecifications (const char *path);

This way we could take a universal .a file and get back a bunch of SBModuleSpec objects that represent the arch/objects in the .a file. Then we would need to have a function on SBTarget to add a module to a target using a SBModuleSpec.


Hi Greg,

I understand your point. My use-case was not to enable parsing the module list but rather to be able to detect which archs are available in order to display a GUI control that let's the user choose which archs it wants to run on (and detect archs that we don't support right away such as ARM binaries on x86_64). That's why I tried to get the available archs for the executable module only.

What is the best way to reconcile both approaches?


This should work for you:

% svn commit
Sending include/lldb/API/SBDefines.h
Sending include/lldb/API/SBFileSpec.h
Sending include/lldb/API/SBModule.h
Adding include/lldb/API/SBModuleSpec.h
Sending include/lldb/API/SBStream.h
Sending include/lldb/API/SBTarget.h
Sending include/lldb/Core/ModuleSpec.h
Sending include/lldb/Core/UUID.h
Sending lldb.xcodeproj/project.pbxproj
Sending scripts/Python/build-swig-Python.sh
Sending scripts/Python/interface/SBModule.i
Adding scripts/Python/interface/SBModuleSpec.i
Sending scripts/Python/interface/SBTarget.i
Sending scripts/Python/python-extensions.swig
Sending scripts/lldb.swig
Sending source/API/SBFileSpec.cpp
Sending source/API/SBModule.cpp
Adding source/API/SBModuleSpec.cpp
Sending source/API/SBTarget.cpp
Sending source/Core/UUID.cpp
Transmitting file data ....................
Committed revision 185877.

I have exposed SBModuleSpec and SBModuleSpecList.

You will want to use the static function:

SBModuleSpecList specs = SBModuleSpecList::GetModuleSpecifications("/usr/lib/dyld");

This will give you a list back and you can then get the size and enumerate:

const size_t count = specs.GetSize();
for (size_t i=0; i<count; ++i)
    ModuleSpec module_spec = specs.GetSpecAtIndex(i);
    const char *triple = module_spec.GetTriple();

This properly exposes module specifications so we can enumerate items within a file, and I have also added ways to create a SBModule from a SBModuleSpec:

SBModule module = SBModule (module_spec);

Or you can add a module to a target by given it a module specification:

SBModule module = target.AddModule (module_spec);

This also prepares us for being able to enumerate all .o file in a .a file (though I need to complete the ObjectContainerBSDArchive::GetModuleSpecifications(...) function.

Let me know if this works well for you and if we can mark your bug as fixed.

Greg Clayton

It works fine for my use-case. Thank you!


Sebastien Metrot changed bug 16526