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 <[email protected]> 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 <[email protected]> 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, [email protected] wrote:
>>
>>> Hi,
>>>
>>> Is there something I should do to have this patch proposal reviewed?
>>>
>>> Thanks,
>>>
>>> S.
>>>
>>> On Jul 2, 2013, at 19:47 , [email protected] 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 [email protected]
>>>> Reporter [email protected]
>>>> 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
>>>> [email protected]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> [email protected]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
