[Lldb-commits] [PATCH] Make TestHelloWorld.py to pass remotely on Linux.

[Greg Clayton]

> On Feb 11, 2015, at 4:59 PM, Oleksiy Vyalov <ovyalov at google.com> wrote:
> 
> In http://reviews.llvm.org/D7574#122311, @clayborg wrote:
> 
>> looks good.
>> 
>> By the way: on MacOSX we have UUIDs in all of our binaries, so our IDE just gives us all of the files that it builds by adding them to our target. They first create a target, then they add all built modules using:
>> 
>>  lldb::SBModule module = target.AddModule (const char *path, const char *triple, const char *uuid_cstr, const char *symfile);
>> 
>> 
>> 
>> Then when we run, we discover, via the dynamic loader, that we need some binary whose UUID is 1234. Since we were given the local copy of the binary already, we can just match it up and not worry about search paths. Any files that we weren't given binaries for, we expect them to be in the sys root of the platform (where all the /usr/lib binaries are cached, etc). So we expect any binaries that were locally built to be supplied to us (which can be done in the test suite for example) and all others to be in the SDK and the platform plug-in will locate them.
> 
> 
> Thank you for context. UUID in some way does simplify correct symbols discovery.
> Does it mean that every time you re-build a binary it gets a new UUID assigned (if it's a part of compilation or linker stage)?

No, it our UUID values are a MD5 checksum of carefully selected parts of the binary. We skip around the parts that have debug info or source file paths in it. So the text and data sections, parts of the symbol table that aren't debug or source related and a few more parts.