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

[Sebastien Metrot]

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

S.


On Jul 9, 2013, at 00:29 , Greg Clayton <gclayton at apple.com> wrote:

> 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
> 
> 
> On Jul 8, 2013, at 11:38 AM, Sebastien Metrot <meeloo at gmail.com> wrote:
> 
>> 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?
>> 
>> S.
>> 
>> 
>> 
>> On Jul 8, 2013, at 19:48 , Greg Clayton <gclayton at apple.com> wrote:
>> 
>>> 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.
>>> 
>>> Greg
>>> 
>>> On Jul 5, 2013, at 12:31 PM, meeloo at gmail.com wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Is there something I should do to have this patch proposal reviewed?
>>>> 
>>>> Thanks,
>>>> 
>>>> S.
>>>> 
>>>> On Jul 2, 2013, at 19:47 , bugzilla-daemon at llvm.org wrote:
>>>> 
>>>>> 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 at cs.uiuc.edu
>>>>> Reporter	meeloo at 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.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> S.
>>>>> 
>>>>> 
>>>>> You are receiving this mail because:
>>>>> 	• You are the assignee for the bug.
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev at cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>> 
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> 
>> 
>