[Lldb-commits] [lldb] r185366 - Split symbol support for ELF and Linux.

[Jason Molenda]

On Jul 2, 2013, at 8:25 AM, Ed Maste <emaste at freebsd.org> wrote:

> On 2 July 2013 11:18, Malea, Daniel <daniel.malea at intel.com> wrote:
>> What's UUID used for? Is it just used by LLDB to determine when an
>> executable has changed, or does it have other implications? If it's just
>> for detecting changed executables, is there any reason to not just compute
>> an MD5 sum of the binary (in the case UUID is missing) instead?
> 
> For the standalone debug files the GNU spec includes a crc32 of the
> main binary's contents, used to make sure the two files match.  I
> don't know of all of the UUID use cases within lldb, but it looks like
> Michael's patch uses the first four bytes of the UUID to store this
> crc.


For what it's worth, on Mac OS X every binary has a 128-bit UUID generated by the linker (in the LC_UUID Mach-O load command), it is some hash of the text and maybe the data in the binary (compiling the same source twice with the same tools results in the same UUID by default).

The DWARF on Mac OS X is stored in a separate file (a "dSYM bundle") and the same UUID value is stored in the dSYM.  This way we can unambiguously match the correct debug information with the correct executable.

The UUID is also used for various sampling and crash reporting tools -- a crash log will include the UUIDs & load addresses of all the libraries in the process for correct symbolication of the addresses in the crash backtrace.

We also have mechanisms to search for debug info (the dSYM) based on a UUID.  lldb is debugging a process, a library is loaded, it will get the UUID of the library and do a quick search for a matching dSYM on the local system.