Re: [lldb-dev] When should ArchSpecs match?

[Jason Molenda via lldb-dev]

Oh sorry I missed that.  Yes, I think a value added to the OSType for NoOS or 
something would work.  We need to standardize on a textual representation for 
this in a triple string as well, like 'none'.  Then with arm64-- and arm64-*-* 
as UnknownVendor + UnknownOS we can have these marked as "compatible" with any 
other value in the case Adrian is looking at.


> On Dec 6, 2018, at 4:05 PM, Zachary Turner  wrote:
> 
> That's what I mean though, perhaps we could add a value to the OSType 
> enumeration like BareMetal or None to explicitly represent this.  the 
> SubArchType enum has NoSubArch, so it's not without precedent.  As long as 
> you can express it in the triple format, the problem goes away.  
> 
> On Thu, Dec 6, 2018 at 3:55 PM Jason Molenda  wrote:
> There is genuinely no OS in some cases, like people who debug the software 
> that runs in a keyboard or a mouse.  And to higher-level coprocessors in a 
> modern phones; the SOCs on all these devices have a cluster of processors, 
> and only some of them are running an identifiable operating system, like iOS 
> or Android.
> 
> I'll be honest, it's not often that we'll be debugging an arm64-apple-none 
> target and have to decide whether an arm64-apple-ios binary should be loaded 
> or not.  But we need some way to express this kind of environment.
> 
> 
> > On Dec 6, 2018, at 3:50 PM, Zachary Turner  wrote:
> > 
> > Is there some reason we can’t define vendors, environments, arches, and 
> > oses for all supported use cases? That way “there is no os” would not ever 
> > be a thing.
> > On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev 
> >  wrote:
> > 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 
> > >  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
> > > 

Re: [lldb-dev] When should ArchSpecs match?

[Zachary Turner via lldb-dev]

That's what I mean though, perhaps we could add a value to the OSType
enumeration like BareMetal or None to explicitly represent this.  the
SubArchType enum has NoSubArch, so it's not without precedent.  As long as
you can express it in the triple format, the problem goes away.

On Thu, Dec 6, 2018 at 3:55 PM Jason Molenda  wrote:

> There is genuinely no OS in some cases, like people who debug the software
> that runs in a keyboard or a mouse.  And to higher-level coprocessors in a
> modern phones; the SOCs on all these devices have a cluster of processors,
> and only some of them are running an identifiable operating system, like
> iOS or Android.
>
> I'll be honest, it's not often that we'll be debugging an arm64-apple-none
> target and have to decide whether an arm64-apple-ios binary should be
> loaded or not.  But we need some way to express this kind of environment.
>
>
> > On Dec 6, 2018, at 3:50 PM, Zachary Turner  wrote:
> >
> > Is there some reason we can’t define vendors, environments, arches, and
> oses for all supported use cases? That way “there is no os” would not ever
> be a thing.
> > On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > 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
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] When should ArchSpecs match?

[Jason Molenda via lldb-dev]

There is genuinely no OS in some cases, like people who debug the software that 
runs in a keyboard or a mouse.  And to higher-level coprocessors in a modern 
phones; the SOCs on all these devices have a cluster of processors, and only 
some of them are running an identifiable operating system, like iOS or Android.

I'll be honest, it's not often that we'll be debugging an arm64-apple-none 
target and have to decide whether an arm64-apple-ios binary should be loaded or 
not.  But we need some way to express this kind of environment.


> On Dec 6, 2018, at 3:50 PM, Zachary Turner  wrote:
> 
> Is there some reason we can’t define vendors, environments, arches, and oses 
> for all supported use cases? That way “there is no os” would not ever be a 
> thing.
> On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev 
>  wrote:
> 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 
> >  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

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] When should ArchSpecs match?

[Zachary Turner via lldb-dev]

Is there some reason we can’t define vendors, environments, arches, and
oses for all supported use cases? That way “there is no os” would not ever
be a thing.
On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> 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
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] When should ArchSpecs match?

[Jim Ingham via lldb-dev]

I agree with Davide.  Particularly if there’s code that is relying on the 
“IsExactMatch” not behaving like the function name makes clear it obviously 
should behave, we should straighten that out.  Otherwise reasoning about this 
will be too confusing.

Jim


> On Dec 6, 2018, at 3:26 PM, Davide Italiano via lldb-dev 
>  wrote:
> 
> On Thu, Dec 6, 2018 at 3:20 PM Adrian Prantl via lldb-dev
> mailto: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.
> 
> Yes.
> 
>> - ArchSpec("x86_64").IsExactMatch("x86_64-apple-macosx10.14") should be 
>> false.
> 
> I'm at a loss trying to understand how this could not be false.
> It would mean that when we instantiate a Triple and we don't have an
> arch we believe it's a Mach-O binary.
> This sounds really wrong, and if there's code in lldb living under the
> assumption this is true, we might consider getting rid of it (or
> fixing it).
> 
>> - ArchSpec("x86_64-*-*").IsCompatibleMath("x86_64-apple-macosx") should be 
>> true.
>> 
> Yes.
> 
> --
> Davide
> ___
> 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

Re: [lldb-dev] When should ArchSpecs match?

[Jason Molenda via lldb-dev]

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 
>  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

Re: [lldb-dev] When should ArchSpecs match?

[Davide Italiano via lldb-dev]

On Thu, Dec 6, 2018 at 3:20 PM Adrian Prantl via lldb-dev
 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.

Yes.

> - ArchSpec("x86_64").IsExactMatch("x86_64-apple-macosx10.14") should be false.

I'm at a loss trying to understand how this could not be false.
It would mean that when we instantiate a Triple and we don't have an
arch we believe it's a Mach-O binary.
This sounds really wrong, and if there's code in lldb living under the
assumption this is true, we might consider getting rid of it (or
fixing it).

> - ArchSpec("x86_64-*-*").IsCompatibleMath("x86_64-apple-macosx") should be 
> true.
>
Yes.

--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] When should ArchSpecs match?

[Adrian Prantl via lldb-dev]

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

Re: [lldb-dev] [cfe-dev] ASTImporter patches and improvements, please help

[Davide Italiano via lldb-dev]

On Thu, Dec 6, 2018 at 6:39 AM Gábor Márton  wrote:
>
> Hi Davide,
>
> Thank you for your email.
>
> > In particular, what's the error you get when lldb fails immediately running 
> > the tests?
> > Also, have you checked libcxx and libcxx-abi in your build? We might
> > consider making that a mandatory dependency for the Cmake build.
>
> Finally I could run the test suite ("ninja check-lldb) on our macOS without 
> errors. Here are my findings:
> 1) "sudo /usr/sbin/DevToolsSecurity --enable" is a must.
> 2) I indeed did not checked out libcxx. (libcxx-abi was not needed to have a 
> successful run). Would be great to make that a mandatory dependency.
> 3) Besides that I recognized that "ninja check-lldb" target does not build 
> all it's dependencies. E.g. lldb-server tests failed until I executed "ninja 
> debugserver" before "ninja check-lldb". I am not sure, but I think "ninja 
> obj2yaml" and "ninja llvm-pdbutil" are also prerequisites (and these targets 
> seem not to be built by a simple "ninja" command).
>

Any chance you can submit fixes for this? Or, if you can't just open a
PR and I'll take a look.

--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

[Bruce Mitchener via lldb-dev]

I like this a lot!

I commented on the patch since I didn't see this thread at the time, but
it'd be interesting to perhaps replace Epydoc with Sphinx as well.

 - Bruce


On Fri, Dec 7, 2018 at 12:02 AM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi everyone,
>
> The current LLDB website is written in HTML which is hard to maintain. We
> have quite a bit of HTML code checked in which can make it hard to
> differentiate between documentation written by us and documentation
> generated by a tool. Furthermore I think text/RST files provide a lower
> barrier for new or casual contributors to fix or update.
>
> In line with the other LLVM projects I propose generating the
> documentation with Sphix. I created a patch (
> https://reviews.llvm.org/D55376) that adds a new target docs-lldb-html
> when -DLLVM_ENABLE_SPHINX:BOOL is enabled. I've ported over some pages to
> give an idea of what this would look like in-tree. Before continuing with
> this rather tedious work I'd like to get feedback form the community.
>
> Initially I started with the theme used by Clang because it's a default
> theme and doesn't require configuration. If we want to keep the sidebar we
> could use the one used by LLD.
>
> Please let me know what you think.
>
> Thanks,
> Jonas
> ___
> 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

[lldb-dev] [RFC] Using Sphinx to generate documentation

[Jonas Devlieghere via lldb-dev]

Hi everyone,

The current LLDB website is written in HTML which is hard to maintain. We have 
quite a bit of HTML code checked in which can make it hard to differentiate 
between documentation written by us and documentation generated by a tool. 
Furthermore I think text/RST files provide a lower barrier for new or casual 
contributors to fix or update.

In line with the other LLVM projects I propose generating the documentation 
with Sphix. I created a patch (https://reviews.llvm.org/D55376 
) that adds a new target docs-lldb-html when 
-DLLVM_ENABLE_SPHINX:BOOL is enabled. I've ported over some pages to give an 
idea of what this would look like in-tree. Before continuing with this rather 
tedious work I'd like to get feedback form the community.

Initially I started with the theme used by Clang because it's a default theme 
and doesn't require configuration. If we want to keep the sidebar we could use 
the one used by LLD.

Please let me know what you think.

Thanks,
Jonas
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] ASTImporter patches and improvements, please help

[Gábor Márton via lldb-dev]

Hi Davide,

Thank you for your email.

> In particular, what's the error you get when lldb fails immediately
running the tests?
> Also, have you checked libcxx and libcxx-abi in your build? We might
> consider making that a mandatory dependency for the Cmake build.

Finally I could run the test suite ("ninja check-lldb) on our macOS without
errors. Here are my findings:
1) "sudo /usr/sbin/DevToolsSecurity --enable" is a must.
2) I indeed did not checked out libcxx. (libcxx-abi was not needed to have
a successful run). Would be great to make that a mandatory dependency.
3) Besides that I recognized that "ninja check-lldb" target does not build
all it's dependencies. E.g. lldb-server tests failed until I executed
"ninja debugserver" before "ninja check-lldb". I am not sure, but I think
"ninja obj2yaml" and "ninja llvm-pdbutil" are also prerequisites (and these
targets seem not to be built by a simple "ninja" command).

Thanks,
Gabor


On Sat, Dec 1, 2018 at 9:40 PM Davide Italiano 
wrote:

> On Sat, Dec 1, 2018 at 8:00 AM Gábor Márton via cfe-dev
>  wrote:
> >
> > Dear LLDB Developers,
> >
> > There is an ongoing activity to improve ASTImporter in Clang to make it
> support
> > C++ (and C) completely and correctly.  Our team works on cross
> translation unit
> > (CTU) static analysis where we use the in-tree Clang static analyzer in
> > combination with the ASTImporter (via the scan-build.py script or
> CodeChecker).
> > In the past 18 months we have committed more than 70 patches to make the
> > ASTImporter better.  Our primary target is Linux and we do run the LLDB
> tests
> > on Linux before we commit.  Unfortunately, quite recently 3 of these
> patches
> > broke the LLDB macOS buildbots (green.lab.llvm.org/green/view/LLDB) and
> this
> > caused some turmoil.  We are very sorry about this and we are making
> actions to
> > avoid such inconveniences in the future: We ordered a Mac Mini, until it
> > arrives we are using a borrowed Mac Book. We are going to create a CI
> job which
> > will execute the macOS LLDB test suite for a specific patch. Besides
> this, for
> > every patch we are going to monitor the macOS buildbots once they are
> > committed.
> >
> > However, we are experiencing problems both with the buildbots and with
> the LLDB
> > tests, therefore we are asking help from the LLDB community in the
> following:
> >
> > (1) Apparently, the green lab macOS buildbots are not displayed in the
> build
> > bot console (http://lab.llvm.org:8011/console). More importantly they
> are not
> > capable of sending emails to the authors of the commit in case of
> failure.
> > Would it be possible to setup the these buildbots to send out the emails
> for
> > the authors?
> >
>
> Thanks for reporting this problem. I cc:ed Mike, as he owns the bots,
> and he should be able to help us with this.
> (I do have access to the Jenkins configuration but I don't feel
> confident enough to make the change myself).
>
> > (2) We are facing difficulties with the LLDB lit tests both on macOS and
> on
> > Linux. E.g. on a fresh macOS mojave install, checking out master LLVM,
> Clang,
> > LLDB and then executing ninja check-lldb fails immediately.  On Linux we
> > experienced that some tests fail because they try to read a non-existent
> > register. Some tests fail non-deterministically because they can't kill a
> > process or a timeout is not long enough. Some tests fail because of a
> linker
> > error of libcxx. We would like to address all these issues. Would you
> like to
> > discuss these issues on lldb-dev or should we create a bugzilla ticket
> for
> > each?
> >
>
> I think either of them is fine. If you're willing to spend some time
> on this, I'm sure people on the LLDB side will consider helping you.
> In particular, what's the error you get when lldb fails immediately
> running the tests?
> Also, have you checked libcxx and libcxx-abi in your build? We might
> consider making that a mandatory dependency for the Cmake build.
>
> > (3) ASTImporter unit tests and lit tests in Clang for the LLDB specific
> usage
> > are very-very limited.  LLDB uses the so called "minimal" import, but
> none of
> > the unit tests exercises that (CTU uses the full import).  We should
> have a
> > unit test suite where the LLDB use cases are covered, e.g. after a
> minimal
> > import an `importDefinition` is called. Also, a test double which
> implements
> > the ExternalASTSource could be used.  I believe it would be possible to
> cover
> > with the unit tests all LLDB/macOS related scenarios and these tests
> could run
> > on Linux too.  We do something similar in case of windows: we execute
> all unit
> > tests with "-fdelayed-template-parsing" and with "-fms-compatibility"
> too. I
> > think, the more unit tests we have in Clang the sooner we catch the LLDB
> > specific importer errors.  I am asking the LLDB community's help here,
> because
> > we lack the domain knowledge in LLDB so we don't know what expectations
> should
> > we