[Lldb-commits] [lldb] r105714 - in /lldb/trunk/include/lldb: Core/Log.h Core/Mangled.h Core/RegularExpression.h Core/Section.h Core/UUID.h Target/ThreadPlan.h

[Jason Molenda]

On Jun 9, 2010, at 9:40 AM, Joseph Ranieri wrote:

>> Modified: lldb/trunk/include/lldb/Core/UUID.h
>> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/UUID.h?rev=105714&r1=105713&r2=105714&view=diff
>> ==============================================================================
>> --- lldb/trunk/include/lldb/Core/UUID.h (original)
>> +++ lldb/trunk/include/lldb/Core/UUID.h Wed Jun  9 03:57:38 2010
>> @@ -17,6 +17,8 @@
>> 
>> #include "lldb/lldb-private.h"
>> 
>> +struct uuid_t;
>> +
>> namespace lldb_private {
>> 
>> class UUID
> 
> This change seems to have broken the Mac OS X build by redefining
> uuid_t as a struct, where it was previously defined in unistd.h as:
> 
> #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
> #ifndef _UUID_T
> #define _UUID_T
> typedef __darwin_uuid_t         uuid_t;
> #endif /* _UUID_T */
> #endif /* (_POSIX_C_SOURCE && !_DARWIN_C_SOURCE) */
> 
> This is a bit ugly, but perhaps it could be wrapped in #ifndef _UUID_T?

This is one of those cases where porting from Mac OS X to anything else may hit some hiccups.  The uuid_t definition itself is nothing special, uint8_t [16], but the use of them is probably going to be specific to the Mac.  On our platform we tag every binary the linker creates with a 128 bit number.  We keep the DWARF debug information in a separate file (it isn't processed by ld) and the same 128 bit number as the binary is encoded in the DWARF.  We use these UUIDs to locate the separate DWARF file (the "dSYM"), to tie together matching versions of binary and debug information, and to uniquely identify a binary regardless of file pathnames.  It's a handy little system but I don't think other platforms have anything equivalent - we may have code that assumes that UUIDs are always present which needs to be refactored.

J