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

Reply via email to