It works fine for my use-case. Thank you! S.
On Jul 9, 2013, at 00:29 , Greg Clayton <[email protected]> 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 <[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
