A few things with respect to triple comparison:

The strings really shouldn't be compared, but the arch/vendor/os enums should 
be. You might also have a "unspecified 'unknown'" or a "specified 'unknown'".

For example if you type:

(lldb) file --arch x86_64 ...

The triple will be:

arch = x86_64
vendor = "unspecified 'unknown'"
os = "unspecified 'unknown'"

But if you type:


(lldb) file --arch x86_64-unknown-unknown ...

The triple will be:

arch = x86_64
vendor = "specified 'unknown'"
os = "specified 'unknown'"

The key is unknown will be returned as the enumeration in both the "specified 
'unknown'" and "unspecified 'unknown'", but the string for os and vendor will 
return empty "" for "unspecified 'unknown'" and will be "unknown" when it is 
"specified 'unknown'".

Any arch that is compared to another, I have been doing:

If exact match, then everything must match.

bool
ArchSpec::IsExactMatch (const ArchSpec& rhs) const

If exact match fails, you should fall back to 'compatible' matches:

bool
ArchSpec::IsCompatibleMatch (const ArchSpec& rhs) const

In these cases, any "unspecific 'unknown'" values will match anything else.

So when ever we can't properly determine a vendor or os, they should be 
"unspecified 'unknown'" so that the compatible matching can occur.

With a triple you can set the "unspecified 'unknown'" by just setting the 
vendor or os using an enumeration (don't use the string). For "specified 
'unknown'" set using the string.

So you your cases the triples:

llvm::Triple triple1 that is set to x86_64-unknown-freebsd9.1
llvm::Triple triple2 that is set to x86_64-unknown-freebsd10.0

should end up with triple1.getArch() == triple2.getArch()
triple1.getVendor() == triple2.getVendor()
triple1.getOS() == triple2.getOS()

Though the strings for the OS won't compare, I believe their getOS() enums 
should match.



> On Jun 26, 2014, at 12:49 PM, Todd Fiala <[email protected]> wrote:
> 
> I'm going to remove this part from the llgs branch and not focus on 
> cross-architecture debugging for the initial llgs update.  This is clearly 
> needs a little more time to work out a situation that doesn't break FreeBSD.  
> I was primarily working on this since it was a necessary part to enabling 
> cross Linux/MacOSX lldb/llgs to work (Linux x86_64 llgs with MacOSX lldb).  
> But that element is not critical for getting llgs Linux x86_64 upstreamed.
> 
> http://reviews.llvm.org/D4302
> 
> 
> 
> _______________________________________________
> lldb-commits mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits

_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits

Reply via email to