[Lldb-commits] [PATCH] Add qModuleInfo request in order to get module information (uuid, triple, ..) by module path from remote platform.

[Greg Clayton]

Yes. Also note that the ObjectFile::GetModuleSpecifications() fills in the file offset in each ModuleSpec using ModuleSpec::SetObjectOffset(...). We can add the object size as well to ModuleSpec if needed so that we can return it correctly for this qModuleInfo command. I would modify:

void
ModuleSpec::SetObjectOffset (uint64_t object_offset);

to be

void
ModuleSpec::SetObjectOffset (uint64_t object_offset, uint64_t object_size);

and add a "uint64_t m_object_size;" to the ModuleSpec.

> On Feb 20, 2015, at 4:28 PM, Oleksiy Vyalov <ovyalov at google.com> wrote:
> 
> Greg,
> 
> I grabbed fat headers for /usr/lib/libc++.1.dylib:
> 
> $ otool -f /usr/lib/libc++.1.dylib
> 
> Fat headers
> 
> fat_magic 0xcafebabe
> 
> nfat_arch 2
> 
> architecture 0
> 
>     cputype 16777223
> 
>     cpusubtype 3
> 
>     capabilities 0x0
> 
>     offset 4096
> 
>     size 708080
> 
>     align 2^12 (4096)
> 
> architecture 1
> 
>     cputype 7
> 
>     cpusubtype 3
> 
>     capabilities 0x0
> 
>     offset 712704
> 
>     size 692592
> 
>     align 2^12 (4096)\
> 
> If, for example, we download a slice of libc++ for architecture 0 [4096, 4096  + 708080] from a target, will it sufficient for lldb on host side to load libc++correctly (resolve all symbols,..) using this slice? 
> 
> 
> 
> 
> 
> 
> On Fri, Feb 20, 2015 at 3:22 PM, Greg Clayton <clayborg at gmail.com> wrote:
> 
> > On Feb 20, 2015, at 2:56 PM, Oleksiy Vyalov <ovyalov at google.com> wrote:
> >
> > Hi Vince,
> >
> > In http://reviews.llvm.org/D7709#127748, @vharron wrote:
> >
> >> Hi all,
> >>
> >> In this instance, we are using this uuid to determine if the module is already cached on the host, right?
> >
> >
> > yes, the plan to have local cache on host side with UUID used a key.
> >
> >> If a fat binary has multiple architectures in a single file and each arch has it's own uuid, wouldn't we just combine (add/xor/whatever) the uuids to get a single uuid for the entire file?
> >
> >
> > My understanding that in case of a fat binary with multiple architectures there is still a single UUID that represents a whole module's binary file, i.e. UUID shouldn't be tied to an architecture.
> 
> That is not correct for MacOSX. Each slice has its own UUID value. The qModuleInfo might be able to return the file offset and file set as well so we can download and cache only the slice we need?
> 
> >
> > http://reviews.llvm.org/D7709
> >
> > EMAIL PREFERENCES
> >  http://reviews.llvm.org/settings/panel/emailpreferences/
> >
> >
> 
> 
> 
> 
> -- 
> Oleksiy Vyalov | Software Engineer | ovyalov at google.com