I think the confusing thing is when "unspecified" means "there is no OS" or
"there is no vendor" versus "vendor/OS is unspecified".
Imagine debugging a firmware environment where we have a cpu arch, and we may
have a vendor, but we specifically do not have an OS. Say armv7-apple-none (I
make up "none", I don't think that's valid). If lldb is looking for a binary
and it finds one with armv7-apple-ios, it should reject that binary, they are
incompatible.
As opposed to a triple of "armv7-*-*" saying "I know this is an armv7 system
target, but I don't know anything about the vendor or the OS" in which case an
armv7-apple-ios binary is compatible.
My naive reading of "arm64-*-*" means vendor & OS are unspecified and should
match anything.
My naive reading of "arm64" is that it is the same as "arm64-*-*".
I don't know what a triple string looks like where we specify "none" for a
field. Is it armv7-apple-- ? I know Triple has Unknown enums, but "Unknown"
is ambiguous between "I don't know it yet" versus "It not any Vendor/OS".
Some of the confusion is the textual representation of the triples, some of it
is the llvm Triple class not having a way to express (afaik) "do not match this
field against anything" aka "none".
> On Dec 6, 2018, at 3:19 PM, Adrian Prantl via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>
> I was puzzled by the behavior of ArchSpec::IsExactMatch() and
> IsCompatibleMatch() yesterday, so I created a couple of unit tests to
> document the current behavior. Most of the tests make perfect sense, but a
> few edge cases really don't behave like I would have expected them to.
>
>> {
>> ArchSpec A("arm64-*-*");
>> ArchSpec B("arm64-apple-ios");
>> ASSERT_FALSE(A.IsExactMatch(B));
>> // FIXME: This looks unintuitive and we should investigate whether
>> // this is the desired behavior.
>> ASSERT_FALSE(A.IsCompatibleMatch(B));
>> }
>> {
>> ArchSpec A("x86_64-*-*");
>> ArchSpec B("x86_64-apple-ios-simulator");
>> ASSERT_FALSE(A.IsExactMatch(B));
>> // FIXME: See above, though the extra environment complicates things.
>> ASSERT_FALSE(A.IsCompatibleMatch(B));
>> }
>> {
>> ArchSpec A("x86_64");
>> ArchSpec B("x86_64-apple-macosx10.14");
>> // FIXME: The exact match also looks unintuitive.
>> ASSERT_TRUE(A.IsExactMatch(B));
>> ASSERT_TRUE(A.IsCompatibleMatch(B));
>> }
>>
>
> Particularly, I believe that:
> - ArchSpec("x86_64-*-*") and ArchSpec("x86_64") should behave the same.
> - ArchSpec("x86_64").IsExactMatch("x86_64-apple-macosx10.14") should be false.
> - ArchSpec("x86_64-*-*").IsCompatibleMath("x86_64-apple-macosx") should be
> true.
>
> Does anyone disagree with any of these statements?
>
> I fully understand that changing any of these behaviors will undoubtedly
> break one or the other edge case, but I think it would be important to build
> on a foundation that actually makes sense if we want to be able to reason
> about the architecture matching logic at all.
>
> let me know what you think!
> -- adrian
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
