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

[Oleksiy Vyalov]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150220/9a6fe2b6/attachment.html>