Re: [lldb-dev] [Release-testers] LLVM 7.1.0-final has been tagged

[Diana Picus via lldb-dev]

ARM looks good too:
bac0c55c1943ee4e4eece850e18cc9cbd638e5c84f397b8897c0a8486f73431b
clang+llvm-7.1.0-armv7a-linux-gnueabihf.tar.xz

Cheers,
Diana

On Mon, 15 Apr 2019 at 10:33, Diana Picus  wrote:
>
> AArch64 looks good:
> b7369d91279cfc470f82528c23318b902adea8e345b7d64a59332c7f6900acfe
> clang+llvm-7.1.0-aarch64-linux-gnu.tar.xz
>
> ARM coming up later.
>
> Cheers,
> Diana
>
> On Fri, 12 Apr 2019 at 02:00, Tom Stellard via Release-testers
>  wrote:
> >
> > Hi,
> >
> > I've just tagged LLVM 7.1.0-final.  Testers, please upload the final 
> > binaries.
> >
> > Thanks,
> > Tom
> > ___
> > Release-testers mailing list
> > release-test...@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

[Pavel Labath via lldb-dev]

Hello all,

some llvm classes, are so well-known and widely used, that qualifying 
them with "llvm::" serves no useful purpose and only adds visual noise. 
I'm thinking here mainly of ADT classes like String/ArrayRef, 
Optional/Error, etc. I propose we stop explicitly qualifying these classes.


We can implement this proposal the same way as clang solved the same 
problem, which is by creating a special LLVM.h 
 
header in the Utility library. This header would adopt these classes 
into the lldb_private namespace via a series of forward and "using" 
declarations.


I think clang's LLVM.h is contains a well-balanced collection of adopted 
classes, and it should cover the most widely-used classes in lldb too, 
so I propose we use that as a starting point.


What do you think?

regards,
pavel

PS: I'm not proposing any wholesale removal of "llvm::" qualifiers from 
these types, though I may do some smaller-scale removals if I'm about to 
substantially modify a file.

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

[lldb-dev] [RFC] Having common Python OS Plug-in

[Alexander Polyakov via lldb-dev]

Hi lldb-dev,

The last few months, I was implementing a LLDB OS Python plug-in. It seems
that there are functionality that is duplicated across many OS plug-ins. I
think we can change that by, for example, upstreaming to LLDB an OS python
plug-in which can be used by all clients and may contain a lot of utility
functions and useful mechanisms like logging, type summaries and so on.

What is your opinion on this?

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

Re: [lldb-dev] [Release-testers] LLVM 7.1.0-final has been tagged

[Dimitry Andric via lldb-dev]

On 12 Apr 2019, at 02:00, Tom Stellard via Release-testers 
 wrote:
> 
> I've just tagged LLVM 7.1.0-final.  Testers, please upload the final binaries.

Unfortunately in the 7.x branch, r345199 was not merged, which reverted commits 
r333103 ("Teach __libcpp_is_floating_point that __fp16 and _Float16 are 
floating-point types") and r333108 ("Do not define template specialization 
__libcpp_is_floating_point<__fp16> if the compiler is not clang").

This leads to compile errors when building libunwind, similar to:

In file included from 
/home/dim/llvm/7.1.0/final/llvm.src/projects/libunwind/src/libunwind.cpp:18:
In file included from 
/home/dim/llvm/7.1.0/final/llvm.src/projects/libcxx/include/new:91:
In file included from 
/home/dim/llvm/7.1.0/final/llvm.src/projects/libcxx/include/exception:83:
/home/dim/llvm/7.1.0/final/llvm.src/projects/libcxx/include/type_traits:740:56: 
error: _Float16 is not supported on this target
template <>  struct __libcpp_is_floating_point<_Float16>: public 
true_type {};
   ^

Therefore I have patched my libcxx sources with r345199, after which the 
complete build successfully finished, at least.

Main test results on amd64-freebsd11:

 Expected Passes: 52437 (rc1: 52441)
 Expected Failures  :   232 (rc1:   232)
 Unsupported Tests  :  3687 (rc1:  3687)
 Unexpected Passes  : 1 (rc1: 1)
 Unexpected Failures:   499 (rc1:   495)

Test suite results on amd64-freebsd11:

 Expected Passes:   903 (rc1:   903)
 Unexpected Failures: 3 (rc1: 3)

Main test results on i386-freebsd11:

 Expected Passes: 50254 (rc1: 50252)
 Expected Failures  :   226 (rc1:   226)
 Unsupported Tests  :  2502 (rc1:  2502)
 Unexpected Failures:   274 (rc1:   276)

As before, the test suite fails to compile on i386, due to an SSE requirement.

Uploaded:

SHA256 (clang+llvm-7.1.0-amd64-unknown-freebsd11.tar.xz) = 
183c7949fcd0db5638ed471c138a594b7176d53ff2a6558754e703f4075acb80
SHA256 (clang+llvm-7.1.0-i386-unknown-freebsd11.tar.xz) = 
d43471d32bc2cadd77a6a61e15316a9870a4b2825b3a73b9b362cc063e4a8ae1

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Having common Python OS Plug-in

[Jim Ingham via lldb-dev]

If you want to undertake such a thing, that would be great.  The other fairly 
complex OS plugin that exists in the wild is the one that ships with the Darwin 
Kernel Debug Kit.  You can get this from 
http://developer.apple.com/download/more - you need a free ADC account to get 
this, though if that's a problem I can also get you a copy of the Python code 
for the OS plugin.  If you're going to make some common utilities you might 
have a look at what that one does if you haven't already.

Jim


> On Apr 17, 2019, at 11:37 AM, Alexander Polyakov via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
> 
> The last few months, I was implementing a LLDB OS Python plug-in. It seems 
> that there are functionality that is duplicated across many OS plug-ins. I 
> think we can change that by, for example, upstreaming to LLDB an OS python 
> plug-in which can be used by all clients and may contain a lot of utility 
> functions and useful mechanisms like logging, type summaries and so on.
> 
> What is your opinion on this?
> 
> -- 
> Alexander
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] [RFC] Having common Python OS Plug-in

[Alexander Polyakov via lldb-dev]

It seems that I need a Apple ID to create an account, can you please share
the code?

I want common OS plug-in to be similar to Apple's lldbmacros (link
), but it
should be with support of multiple architectures and operating systems,
logging and so on. I've created such a plug-in for Zephyr OS, maybe I'll be
able to also share the code to show how common plug-in might look like.

On Wed, Apr 17, 2019 at 10:40 PM Jim Ingham  wrote:

> If you want to undertake such a thing, that would be great.  The other
> fairly complex OS plugin that exists in the wild is the one that ships with
> the Darwin Kernel Debug Kit.  You can get this from
> http://developer.apple.com/download/more - you need a free ADC account to
> get this, though if that's a problem I can also get you a copy of the
> Python code for the OS plugin.  If you're going to make some common
> utilities you might have a look at what that one does if you haven't
> already.
>
> Jim
>
>
> > On Apr 17, 2019, at 11:37 AM, Alexander Polyakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi lldb-dev,
> >
> > The last few months, I was implementing a LLDB OS Python plug-in. It
> seems that there are functionality that is duplicated across many OS
> plug-ins. I think we can change that by, for example, upstreaming to LLDB
> an OS python plug-in which can be used by all clients and may contain a lot
> of utility functions and useful mechanisms like logging, type summaries and
> so on.
> >
> > What is your opinion on this?
> >
> > --
> > Alexander
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>

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

Re: [lldb-dev] [RFC] Having common Python OS Plug-in

[Jim Ingham via lldb-dev]

The os plugin in the KDK's is just a packaged up version of what's in the link 
you referenced, so the KDK wouldn't add anything.

Jim


> On Apr 17, 2019, at 12:50 PM, Alexander Polyakov  
> wrote:
> 
> It seems that I need a Apple ID to create an account, can you please share 
> the code?
> 
> I want common OS plug-in to be similar to Apple's lldbmacros (link), but it 
> should be with support of multiple architectures and operating systems, 
> logging and so on. I've created such a plug-in for Zephyr OS, maybe I'll be 
> able to also share the code to show how common plug-in might look like.
> 
> On Wed, Apr 17, 2019 at 10:40 PM Jim Ingham  wrote:
> If you want to undertake such a thing, that would be great.  The other fairly 
> complex OS plugin that exists in the wild is the one that ships with the 
> Darwin Kernel Debug Kit.  You can get this from 
> http://developer.apple.com/download/more - you need a free ADC account to get 
> this, though if that's a problem I can also get you a copy of the Python code 
> for the OS plugin.  If you're going to make some common utilities you might 
> have a look at what that one does if you haven't already.
> 
> Jim
> 
> 
> > On Apr 17, 2019, at 11:37 AM, Alexander Polyakov via lldb-dev 
> >  wrote:
> > 
> > Hi lldb-dev,
> > 
> > The last few months, I was implementing a LLDB OS Python plug-in. It seems 
> > that there are functionality that is duplicated across many OS plug-ins. I 
> > think we can change that by, for example, upstreaming to LLDB an OS python 
> > plug-in which can be used by all clients and may contain a lot of utility 
> > functions and useful mechanisms like logging, type summaries and so on.
> > 
> > What is your opinion on this?
> > 
> > -- 
> > Alexander
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> -- 
> Alexander

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

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

[Jonas Devlieghere via lldb-dev]

Hey Pavel,

Sounds like a good idea. I don't have a strong opinion on this matter, but
I'm always in favor of improving readability.

Cheers,
Jonas

On Wed, Apr 17, 2019 at 3:38 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hello all,
>
> some llvm classes, are so well-known and widely used, that qualifying
> them with "llvm::" serves no useful purpose and only adds visual noise.
> I'm thinking here mainly of ADT classes like String/ArrayRef,
> Optional/Error, etc. I propose we stop explicitly qualifying these classes.
>
> We can implement this proposal the same way as clang solved the same
> problem, which is by creating a special LLVM.h
> <
> https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/LLVM.h>
>
> header in the Utility library. This header would adopt these classes
> into the lldb_private namespace via a series of forward and "using"
> declarations.
>
> I think clang's LLVM.h is contains a well-balanced collection of adopted
> classes, and it should cover the most widely-used classes in lldb too,
> so I propose we use that as a starting point.
>
> What do you think?
>
> regards,
> pavel
>
> PS: I'm not proposing any wholesale removal of "llvm::" qualifiers from
> these types, though I may do some smaller-scale removals if I'm about to
> substantially modify a file.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

[Adrian McCarthy via lldb-dev]

I don't have a strong opinion, but I lean against the idea for two reasons:

1.  The `llvm::` prefixes don't really hinder readability for me.  They're
like `std::` prefixes on all the C++ standard library types, which I'm
perfectly happy to type and read--moreso than using declarations.  Sure,
anybody who's been here a while knows which classes come from LLVM, but new
folks might build that knowledge by seeing the prefixes.

2.  I'm not a fan of forward declaring types provided by other parts of the
code, as it requires intimate knowledge of implementation details.  In
practice this may not matter much for the types we're considering.  If it
grew more widespread, however, I'd be more concerned.  (Somewhere I've
written a long explanation of this opinion.  I'll go search for it if
anyone cares.  The Google style guide discourages forward declarations, but
the rationale given there isn't as persuasive.)

On Wed, Apr 17, 2019 at 4:18 PM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hey Pavel,
>
> Sounds like a good idea. I don't have a strong opinion on this matter, but
> I'm always in favor of improving readability.
>
> Cheers,
> Jonas
>
> On Wed, Apr 17, 2019 at 3:38 AM Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hello all,
>>
>> some llvm classes, are so well-known and widely used, that qualifying
>> them with "llvm::" serves no useful purpose and only adds visual noise.
>> I'm thinking here mainly of ADT classes like String/ArrayRef,
>> Optional/Error, etc. I propose we stop explicitly qualifying these
>> classes.
>>
>> We can implement this proposal the same way as clang solved the same
>> problem, which is by creating a special LLVM.h
>> <
>> https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/LLVM.h>
>>
>> header in the Utility library. This header would adopt these classes
>> into the lldb_private namespace via a series of forward and "using"
>> declarations.
>>
>> I think clang's LLVM.h is contains a well-balanced collection of adopted
>> classes, and it should cover the most widely-used classes in lldb too,
>> so I propose we use that as a starting point.
>>
>> What do you think?
>>
>> regards,
>> pavel
>>
>> PS: I'm not proposing any wholesale removal of "llvm::" qualifiers from
>> these types, though I may do some smaller-scale removals if I'm about to
>> substantially modify a file.
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev