Re: [lldb-dev] [4.0.0 Release] Release Candidate 3 has been tagged

[Mehdi Amini via lldb-dev]

Pushed: 

9bdd5788761d0b02cdc84104aafd6b0e835a2fc0  
rc3/clang+llvm-4.0.0-rc3-x86_64-apple-darwin.tar.xz


— 
Mehdi



> On Mar 2, 2017, at 2:12 PM, Hans Wennborg via lldb-dev 
>  wrote:
> 
> On Thu, Mar 2, 2017 at 11:47 AM, Hans Wennborg  wrote:
>> 4.0.0-rc3 was just tagged from the branch at r296762.
>> 
>> This is a release candidate in the real sense: if no major issues show
>> up with this one, it is the version that will be released.
>> 
>> Please let me know if you find any issues, including in release notes
>> or documentation, which will be on the pre-release web site later
>> today.
> 
> Source and docs are now ready: http://www.llvm.org/pre-releases/4.0.0/#rc3
> ___
> 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] LLVM GSOC Projects Criteria Consultation (before 2/28)

[Mehdi Amini via lldb-dev]

Hello all,

GSOC is around the corner, and the LLVM projects plans to participate again 
this year. For those who don’t know about GSOC, students are proposing a 
project that they will work on for 3 months. Amongst other, one goal for LLVM 
is to mentor students to become good developers and also contributors to the 
LLVM project (or user/advocate of LLVM for building other cool projects).

A key part of the process is about how do we select the projects. The way we’ve 
done it last year, is that the volunteer mentors shared an email thread and 
ultimately each one individually ranked the projects. We kept the average 
grading for each project to ranked them overall.

 In order to make the process more transparent to student applicants, we want 
to formalize and announce the criteria for ranking and selection project.

The purpose of this email is to gather community feedback about the criterion 
that mentors should apply when ranking projects, for example:

- Should we favor a student which has past contributions to LLVM compared to a 
newcomer? Is it more important or as equally important as the quality of the 
proposal?
- How should we rank (if any) “research or unbounded projects” vs “project with 
an immediate application”? Should we strive to keep a balance?
- What about “projects that touch LLVM/Clang/…” vs “projects that are building 
something on top of LLVM”? (For example this project was first proposed to be 
selected by LLVM before being rejected and finally picked by the Julia project 
directly: 
https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/ )?
- Should we ask that the work is done upstream all along? In the past there 
have been project developed on GitHub outside the community that have never 
been merged. The LLVM developer policy has a full section insisting on 
incremental development ( 
http://llvm.org/docs/DeveloperPolicy.html#incremental-development ).

Hopefully we should be able to provide a set of guidelines to student that 
would help them fill the best application, and avoid unfortunate surprise at 
the end of the process.

We should have this discussion before receiving the projects proposals, which 
opens on 2/28.

Best,

-- 
Mehdi

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

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Release Candidate 2 has been tagged

[Mehdi Amini via lldb-dev]

(stage-3 check-all fails on macOS around libcxxabi but I think it is usual).

I pushed:

9df4d8a9c74ccb1aaaf934f19a48d003917c9d81  
rc2/clang+llvm-4.0.0-rc2-x86_64-apple-darwin.tar.xz

— 
Mehdi


> On Feb 8, 2017, at 4:33 PM, Hans Wennborg via llvm-dev 
>  wrote:
> 
> Hello testers,
> 
> 4.0.0-rc2 was just tagged from the branch at r294535.
> 
> There are still open relase blocking bugs and merge requests, so this
> will not be the last release candidate, but we've had a lot of merges
> since the last one, and I'd like to see what the testing looks like.
> 
> The test-release.sh script was updated to also include lld. Make sure
> you're using the latest version of the script (ideally from the
> branch, but the trunk version is identical), and if lld causes any
> problems, pass the "-no-lld" flag.
> 
> Please build, test, and upload binaries to the sftp. Let me know what
> comes up, and I'll publish your binaries plus source and docs when
> they're ready.
> 
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] Navigating STL types

[Mehdi Amini via lldb-dev]

> On Jan 23, 2017, at 4:13 PM, Andreas Yankopolus  wrote:
> 
> Mehdi,
> 
>> Yes, this is a problem with our STL, we are forcing inlining and we need to 
>> fix this on libc++ side, it is scheduled, but we haven’t come to it yet.
> 
> Any guesstimate as to the timeframe?

Long time overdue, keep being punted because other higher priorities issues 
keep showing up, “soon” hopefully.

> Seems like being able to navigate STL types would be a useful thing.

I don’t think anyone would disagree :)

— 
Mehdi

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

Re: [lldb-dev] Navigating STL types

[Mehdi Amini via lldb-dev]

Yes, this is a problem with our STL, we are forcing inlining and we need to fix 
this on libc++ side, it is scheduled, but we haven’t come to it yet.

— 
Mehdi

> On Jan 23, 2017, at 3:58 PM, Andreas Yankopolus via lldb-dev 
>  wrote:
> 
> How can I navigate STL types using their overloaded operators and member 
> functions (e.g., “[]” and “.first()” for vectors) ? For example, take a C++ 
> source file with:
> 
> std::vector v;
> v.push_back("foo”);
> 
> Breaking after this statement in lldb and typing "p v[0]" would be reasonably 
> expected to return "foo", but it gives a symbol lookup error. Similarly, “p 
> v.first()” gives an error that there’s no member named “first”. I’m seeing 
> this issue with clang/llvm 3.9 and 4.0 nightlies on Ubuntu 16.10 and with 
> Apple’s versions on MacOS Sierra.
> 
> Internet rumor (e.g., this discussion 
> )
>  says this is aggressive inlining of STL code. I’m compiling in clang++ with 
> “-O0 -g -glldb”.
> 
> In comparison, gdb prints the value of v[0] just fine when compiled with gdb.
> 
> What am I doing wrong?
> ___
> 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] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Mehdi Amini via lldb-dev]

Hi,

FYI, I added a Green dragon job to build and test (stage 1 only right now) the 
release branch: 
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA-release-4/ 


— 
Mehdi

> On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev 
>  wrote:
> 
> Dear testers,
> 
> 4.0.0-rc1 was just tagged from the branch, with r292377.
> 
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.
> 
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the web site
> once their ready.
> 
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Mehdi Amini via lldb-dev]

Just pushed Darwin:

d93fca2905fece5b5392a0025c2f5f09f044a17c  
clang+llvm-4.0.0-rc1-x86_64-apple-darwin.tar.xz

— 
Mehdi

> On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev 
>  wrote:
> 
> Dear testers,
> 
> 4.0.0-rc1 was just tagged from the branch, with r292377.
> 
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.
> 
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the web site
> once their ready.
> 
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [cfe-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Mehdi Amini via lldb-dev]

> On Jan 18, 2017, at 7:45 AM, Hans Wennborg via cfe-dev 
>  wrote:
> 
> Dear testers,
> 
> 4.0.0-rc1 was just tagged from the branch, with r292377.
> 
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.
> 
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the web site
> once their ready.

I built successfully, it the something specific you do for testing?
Am I expected to upload clang+llvm-4.0.0-rc1-x86_64-apple-darwin.tar.xz 
somewhere? (I don’t what sftp you’re referring to above).

Pardon my ignorance, first time I participate in the release process :)

Thanks,

Mehdi

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Mehdi Amini via lldb-dev]

Looks like LLVM and clang are out-of-sync.

Using the script as Hans said worked for me:  test-release.sh -release 4.0.0 
-rc 1 -triple x86_64-apple-darwin
(Triple is likely gonna be different for you).

— 
Mehdi

> On Jan 18, 2017, at 12:28 PM, Andrew Kelley via cfe-dev 
>  wrote:
> 
> I tried to compile cfe 4.0.0-rc1 using llvm 4.0.0-rc1 and got this:
> 
> [ 63%] Building CXX object 
> lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o
> /home/andy/Downloads/cfe/rc1/lib/Serialization/ASTReader.cpp: In lambda 
> function:
> /home/andy/Downloads/cfe/rc1/lib/Serialization/ASTReader.cpp:1282:63: error: 
> invalid use of incomplete type ‘class llvm::Error’
>if (llvm::zlib::uncompress(Blob, Uncompressed, Record[0]) !=
>^
> In file included from 
> /home/andy/Downloads/cfe/rc1/lib/Serialization/ASTReader.cpp:73:0:
> /home/andy/local/include/llvm/Support/Compression.h:21:7: note: forward 
> declaration of ‘class llvm::Error’
>  class Error;
>^
> /home/andy/Downloads/cfe/rc1/lib/Serialization/ASTReader.cpp:1283:11: error: 
> ‘StatusOK’ is not a member of ‘llvm::zlib’
>llvm::zlib::StatusOK) {
>^
> lib/Serialization/CMakeFiles/clangSerialization.dir/build.make:86: recipe for 
> target 'lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o' 
> failed
> 
> 
> I added to AstReader.cpp:
> #include "llvm/Support/Error.h"
> 
> But there's still the other error.
> 
> On Wed, Jan 18, 2017 at 10:45 AM, Hans Wennborg via llvm-dev 
> > wrote:
> Dear testers,
> 
> 4.0.0-rc1 was just tagged from the branch, with r292377.
> 
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.
> 
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the web site
> once their ready.
> 
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
> 
> 
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Mehdi Amini via lldb-dev]

Hi Hans,

I can test it on macOS. Is there a doc to describe what to test? I remember you 
pointed me to a script once…
Anyone else involved in the release process on macOS?

Thanks,

— 
Mehdi




> On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev 
>  wrote:
> 
> Dear testers,
> 
> 4.0.0-rc1 was just tagged from the branch, with r292377.
> 
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.
> 
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the web site
> once their ready.
> 
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

[lldb-dev] Fwd: [cfe-dev] Your help needed: List of LLVM Open Projects 2017

[Mehdi Amini via lldb-dev]

LLDB Folks,

FYI, see below, the LLDB section is empty right now.

Best,

Mehdi



> Begin forwarded message:
> 
> From: Vassil Vassilev via cfe-dev 
> Subject: [cfe-dev] Your help needed: List of LLVM Open Projects 2017
> Date: January 16, 2017 at 5:18:21 AM PST
> To: llvm-dev , Clang Dev 
> Reply-To: Vassil Vassilev 
> 
> Hi folks,
> 
>  Happy new year!
> 
>  Last LLVM Developers' Meeting I had a BoF: 'Raising Next Generation LLVM 
> Developers'. It was suggested that we should update our open projects page 
> and possibly restructure it a little bit.
> 
>  I volunteered to do this work and I need your help.
> 
> 
>  Chandler and I started working on a google doc [1]. We pinged few code 
> owners asking them to list of work items we should get done in 2017 but we do 
> not have the manpower. Now we would like to ask for your input, too.
> 
>  I believe an up to date list can serve as a good entry point for students, 
> interns and new contributors.
> 
>  Feel free to propose a new item or comment under an existing one. I expect 
> to start gradually updating the page beginning of Feb.
> 
> -- Vassil
> 
> [1] 
> https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing
>  
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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

Re: [lldb-dev] [cfe-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Mehdi Amini via lldb-dev]

> On Dec 5, 2016, at 12:07 PM, Hans Wennborg via cfe-dev 
>  wrote:
> 
> On Mon, Dec 5, 2016 at 12:02 PM, Renato Golin  > wrote:
>> On 5 December 2016 at 19:56, Hans Wennborg  wrote:
>>> I'd like to avoid 4.1 because of the potential for confusion about
>>> whether it's a major release (as it would have been under the old
>>> scheme) or a patch release.
>> 
>> But if the versioning scheme is different, users will have to
>> understand what it means anyway.
>> 
>> Until now we had a weird and very unique logic, and we're moving to a
>> more sensible logic, because it's similar to what some other projects
>> are doing.
>> 
>> I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
>> that used to be weird before.
>> 
>> After a few releases everything will be clear anyway... I really don't
>> want to make the foreseeable future weird again to avoid a potential
>> misunderstanding for one or two releases.
>> 
>> Let's just be brutally clear in all release communications and
>> hopefully people will understand.
>> 
>> 
>>> The alternative would be:
>>> 
>>> 3.9.0
>>> 3.9.1
>>> 4.0.0
>>> 4.1.0 <-- Can't tell from the version number what kind of release this is.
>> 
>> No, that has a redundant zero, too.
>> 
>> The alternative is:
>> 
>> 3.9.0
>> 3.9.1
>> 4.0
>> 4.1
>> 5.0
>> 5.1
> 
> I'm worried that users will, with some reason, think that the 4.1 and
> 5.1 releases are the same kind as 2.1 and 3.1 :-/

+1, I haven’t seen yet the downside of keeping the minor to 0 and bumping only 
the patch number.

— 
Mehdi


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

Re: [lldb-dev] [llvm-dev] [RFC] Runtime checks for ABI breaking build of LLVM

[Mehdi Amini via lldb-dev]

> On Nov 18, 2016, at 3:45 PM, Mehdi Amini  wrote:
> 
> Hi,
> 
> I had to revert it, because it breaks building LLDB on MacOS.
> 
> It turns out it would break any client that is including llvm-config.h but 
> not linking to libLLVMSupport.
> So either:
> 
> - we shouldn’t allow to include llvm-config.h without linking to LLVM, in 
> which case I need to look a bit closer as of why lldb includes this header in 
> a context where they don’t link LLVM.
> - we should allow to include llvm-config.h without linking to LLVM (at least 
> libSupport). In which case we need a new solution for this feature: it can be 
> to use another header dedicated to this flag, that would be included only 
> from headers that contain the ABI break.

The second approach is implemented here:  https://reviews.llvm.org/D26876

I extracted the LLVM_ENABLE_ABI_BREAKING_CHECKS to its own header to have a 
fine granularity on which client needs to include the check.

— 
Mehdi




> 
> 
>> On Nov 16, 2016, at 12:12 PM, Mehdi Amini via llvm-dev 
>> > wrote:
>> 
>>> 
>>> On Nov 16, 2016, at 12:05 PM, Jonathan Roelofs >> > wrote:
>>> 
>>> 
>>> 
>>> On 11/16/16 11:48 AM, Mehdi Amini via llvm-dev wrote:
 Hi all,
 
 An issue that come up from time to time and has cost hours for debug for
 many of us and users of LLVM is that an assert build isn’t ABI
 compatible with a release build.
 
 The CMake flags that controls this behavior is LLVM_ABI_BREAKING_CHECKS (
 
 *LLVM_ABI_BREAKING_CHECKS*:STRING
Used to decide if LLVM should be built with ABI breaking checks or
not. Allowed values
are WITH_ASSERTS (default), FORCE_ON and FORCE_OFF.  WITH_ASSERTS turns
on ABI breaking checks in an assertion enabled
build.  FORCE_ON (FORCE_OFF) turns them on (off) irrespective of
whether normal (NDEBUG-based) assertions are enabled or not. A
version of LLVM built with ABI breaking checks is not ABI compatible
with a version built without it.
 
 
 I propose to add a runtime check to detect when we have incorrectly
 setup build.
 
 The idea is that every translation unit that includes such header will
 get a weak definition of a symbol with an initializer calling the
 runtime check. The symbol name would be different if the ABI break is
 enabled or not.
>>> 
>>> Can it be made into a link-time check instead? I'm imagining something like:
>> 
>> I’d love to, but didn’t find a universal solution unfortunately :(
>> 
>>>  #if LLVM_ENABLE_ABI_BREAKING_CHECKS
>>>  extern int EnableABIBreakingChecks;
>>>  __attribute__((weak)) int *VerifyEnableABIBreakingChecks = 
>>> 
>>>  #else
>>>  extern int DisableABIBreakingChecks;
>>>  __attribute__((weak)) int *VerifyDisableABIBreakingChecks = 
>>> 
>>>  #endif
>>> 
>>> in llvm-config.h.cmake, and:
>>> 
>>>  #if LLVM_ENABLE_ABI_BREAKING_CHECKS
>>>  int EnableABIBreakingChecks;
>>>  #else
>>>  int DisableABIBreakingChecks;
>>>  #endif
>>> 
>>> in Error.cpp.
>>> 
>>> Then it'll only link if Error.cpp's TU's setting of 
>>> LLVM_ENABLE_ABI_BREAKING_CHECKS matches that of the TU that includes 
>>> llvm-config.h
>> 
>> It seems that this work, I thought I tried exactly this but got lost on the 
>> whiteboard at some point!
>> 
>> Maybe because one drawback that I tried to avoid is that the export-list of 
>> a LLVM dylib would depend on the value of LLVM_ENABLE_ABI_BREAKING_CHECKS 
>> with this.
>> 
>> Thanks,
>> 
>> — 
>> Mehdi
>> 
>> 
>> 
>> 
>> 
>>> 
>>> 
 
 The runtime check maintains two boolean to track if it there is in the
 image at least a translation unit for each value of this flag. If both
 flags are set the process is aborted.
 
 The cost is *one* static initializer per DSO (or per image I believe).
 
 A straw-man patch (likely not windows compatible because of weak) is:
 
 diff --git a/llvm/include/llvm/Config/llvm-config.h.cmake
 b/llvm/include/llvm/Config/llvm-config.h.cmake
 index 4121e865ea00..4274c942d3b6 100644
 --- a/llvm/include/llvm/Config/llvm-config.h.cmake
 +++ b/llvm/include/llvm/Config/llvm-config.h.cmake
 @@ -80,4 +80,18 @@
 /* LLVM version string */
 #define LLVM_VERSION_STRING "${PACKAGE_VERSION}"
 
 +
 +#ifdef __cplusplus
 +namespace llvm {
 +bool setABIBreakingChecks(bool Enabled);
 +__attribute__((weak))
 +#if LLVM_ENABLE_ABI_BREAKING_CHECKS
 +bool
 +ABICheckEnabled = setABIBreakingChecks(true);
 +#else
 +bool ABICheckDisabled = setABIBreakingChecks(true);
>>> 
>>> Do you mean `false` here ^ ?
>>> 
 +#endif
 +}
 +#endif
 +
 #endif
 diff --git a/llvm/lib/Support/Error.cpp b/llvm/lib/Support/Error.cpp
 index 7436a1fd38ee..151fcdcbfb27 100644
 --- a/llvm/lib/Support/Error.cpp
 +++ 

Re: [lldb-dev] [llvm-dev] [RFC] Runtime checks for ABI breaking build of LLVM

[Mehdi Amini via lldb-dev]

Hi,

I had to revert it, because it breaks building LLDB on MacOS.

It turns out it would break any client that is including llvm-config.h but not 
linking to libLLVMSupport.
So either:

- we shouldn’t allow to include llvm-config.h without linking to LLVM, in which 
case I need to look a bit closer as of why lldb includes this header in a 
context where they don’t link LLVM.
- we should allow to include llvm-config.h without linking to LLVM (at least 
libSupport). In which case we need a new solution for this feature: it can be 
to use another header dedicated to this flag, that would be included only from 
headers that contain the ABI break.

— 
Mehdi



> On Nov 16, 2016, at 12:12 PM, Mehdi Amini via llvm-dev 
>  wrote:
> 
>> 
>> On Nov 16, 2016, at 12:05 PM, Jonathan Roelofs > > wrote:
>> 
>> 
>> 
>> On 11/16/16 11:48 AM, Mehdi Amini via llvm-dev wrote:
>>> Hi all,
>>> 
>>> An issue that come up from time to time and has cost hours for debug for
>>> many of us and users of LLVM is that an assert build isn’t ABI
>>> compatible with a release build.
>>> 
>>> The CMake flags that controls this behavior is LLVM_ABI_BREAKING_CHECKS (
>>> 
>>> *LLVM_ABI_BREAKING_CHECKS*:STRING
>>>Used to decide if LLVM should be built with ABI breaking checks or
>>>not. Allowed values
>>>are WITH_ASSERTS (default), FORCE_ON and FORCE_OFF.  WITH_ASSERTS turns
>>>on ABI breaking checks in an assertion enabled
>>>build.  FORCE_ON (FORCE_OFF) turns them on (off) irrespective of
>>>whether normal (NDEBUG-based) assertions are enabled or not. A
>>>version of LLVM built with ABI breaking checks is not ABI compatible
>>>with a version built without it.
>>> 
>>> 
>>> I propose to add a runtime check to detect when we have incorrectly
>>> setup build.
>>> 
>>> The idea is that every translation unit that includes such header will
>>> get a weak definition of a symbol with an initializer calling the
>>> runtime check. The symbol name would be different if the ABI break is
>>> enabled or not.
>> 
>> Can it be made into a link-time check instead? I'm imagining something like:
> 
> I’d love to, but didn’t find a universal solution unfortunately :(
> 
>>  #if LLVM_ENABLE_ABI_BREAKING_CHECKS
>>  extern int EnableABIBreakingChecks;
>>  __attribute__((weak)) int *VerifyEnableABIBreakingChecks = 
>> 
>>  #else
>>  extern int DisableABIBreakingChecks;
>>  __attribute__((weak)) int *VerifyDisableABIBreakingChecks = 
>> 
>>  #endif
>> 
>> in llvm-config.h.cmake, and:
>> 
>>  #if LLVM_ENABLE_ABI_BREAKING_CHECKS
>>  int EnableABIBreakingChecks;
>>  #else
>>  int DisableABIBreakingChecks;
>>  #endif
>> 
>> in Error.cpp.
>> 
>> Then it'll only link if Error.cpp's TU's setting of 
>> LLVM_ENABLE_ABI_BREAKING_CHECKS matches that of the TU that includes 
>> llvm-config.h
> 
> It seems that this work, I thought I tried exactly this but got lost on the 
> whiteboard at some point!
> 
> Maybe because one drawback that I tried to avoid is that the export-list of a 
> LLVM dylib would depend on the value of LLVM_ENABLE_ABI_BREAKING_CHECKS with 
> this.
> 
> Thanks,
> 
> — 
> Mehdi
> 
> 
> 
> 
> 
>> 
>> 
>>> 
>>> The runtime check maintains two boolean to track if it there is in the
>>> image at least a translation unit for each value of this flag. If both
>>> flags are set the process is aborted.
>>> 
>>> The cost is *one* static initializer per DSO (or per image I believe).
>>> 
>>> A straw-man patch (likely not windows compatible because of weak) is:
>>> 
>>> diff --git a/llvm/include/llvm/Config/llvm-config.h.cmake
>>> b/llvm/include/llvm/Config/llvm-config.h.cmake
>>> index 4121e865ea00..4274c942d3b6 100644
>>> --- a/llvm/include/llvm/Config/llvm-config.h.cmake
>>> +++ b/llvm/include/llvm/Config/llvm-config.h.cmake
>>> @@ -80,4 +80,18 @@
>>> /* LLVM version string */
>>> #define LLVM_VERSION_STRING "${PACKAGE_VERSION}"
>>> 
>>> +
>>> +#ifdef __cplusplus
>>> +namespace llvm {
>>> +bool setABIBreakingChecks(bool Enabled);
>>> +__attribute__((weak))
>>> +#if LLVM_ENABLE_ABI_BREAKING_CHECKS
>>> +bool
>>> +ABICheckEnabled = setABIBreakingChecks(true);
>>> +#else
>>> +bool ABICheckDisabled = setABIBreakingChecks(true);
>> 
>> Do you mean `false` here ^ ?
>> 
>>> +#endif
>>> +}
>>> +#endif
>>> +
>>> #endif
>>> diff --git a/llvm/lib/Support/Error.cpp b/llvm/lib/Support/Error.cpp
>>> index 7436a1fd38ee..151fcdcbfb27 100644
>>> --- a/llvm/lib/Support/Error.cpp
>>> +++ b/llvm/lib/Support/Error.cpp
>>> @@ -112,3 +112,17 @@ void report_fatal_error(Error Err, bool GenCrashDiag) {
>>> }
>>> 
>>> }
>>> +
>>> +
>>> +bool llvm::setABIBreakingChecks(bool Enabled) {
>>> +  static char abi_breaking_checks_enabled = 0;
>>> +  static char abi_breaking_checks_disabled = 0;
>>> +  if (Enabled)
>>> +abi_breaking_checks_enabled = 1;
>>> +  else
>>> +abi_breaking_checks_disabled = 1;
>>> +  if (abi_breaking_checks_enabled && abi_breaking_checks_disabled)

Re: [lldb-dev] download page for LLDB at llvm.org

[Mehdi Amini via lldb-dev]

> On Nov 10, 2016, at 9:14 AM, Todd Fiala via lldb-dev 
>  wrote:
> 
> Hi all,
> 
> I just took a look at our page here:
> 
> http://lldb.llvm.org/download.html 
> 
> The LLDB Releases section seems pretty out of date.  It seems like we could 
> correct that via a few different ways:
> 
> * Remove the LLDB Releases section - this would eliminate the appearance of 
> us keeping it up to date (i.e. match what looks to be reality).
> 
> * Start keeping it up to date, at least for the groups that are in fact 
> making occasional builds available.
> 
> * Coordinate with the LLVM folks that do the LLVM binaries, figure out what 
> we need to do to make that happen, and maybe have this page link to the LLVM 
> downloads page.

My 2 cents: I’d like to see lldb getting more of a first class citizen 
(alongside with Clang) in the LLVM project. So having it as part of the LLVM 
release makes sense to me, at least on the medium term.

Best,

— 
Mehdi




> 
> * For those buildbots that do produce usable packages, we could link from 
> here to the build jobs, possibly with a little text on how to make use of it.
> 
> * Something else?
> 
> Any opinions here?  Clearly some of those options above imply work by some, 
> so getting generating usable images generated still may be on a maintainer 
> opt-in basis.  I'm just looking to see us clean up the communication on this 
> page:
> 
> http://lldb.llvm.org/download.html 
> 
> just as a matter of settings expectations for those who land there.
> 
> Thanks for any thoughts on this!
> -- 
> -Todd
> ___
> 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] [llvm-dev] GitHub Survey - Results

[Mehdi Amini via lldb-dev]

I’m working on it.

— 
Mehdi

> On Nov 2, 2016, at 1:43 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> It would be nice if the slides containing the pie-graphs showed the original 
> question that people were responding to.  It's a little hard to make sense of 
> the answers if we can't see (and don't remember) the question.
> 
> On Wed, Nov 2, 2016 at 12:39 PM Renato Golin via llvm-dev 
> > wrote:
> Folks,
> 
> Please note that the survey is still open!
> 
> But it's almost time for the US LLVM meeting and I'd like to give
> everybody the ability to inspect the results before entering the BoF
> session tomorrow.
> 
> Here is a zip file with the raw results (minus emails) of the data up
> until this morning, and a short presentation with a summary and my
> personal pick of the comments.
> 
> http://people.linaro.org/~renato.golin/LLVM%20Move%20to%20GitHub.zip 
> 
> 
> I tried to focus on less on the positive comments and more on the
> negative ones for all topics, because they're the ones that will make
> the difference. I've also tried hard to be completely impartial, just
> presenting the results.
> 
> If you haven't yet submitted, please do. We'll be looking at the data
> and sharing it on the Bof. Mehdi will collate the BoF results and once
> the survey is finally closed, I'll share the raw results again.
> 
> Enjoy!
> --renato
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-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] Regenerating public API reference documentation

[Mehdi Amini via lldb-dev]

> On Oct 14, 2016, at 6:44 AM, Tamas Berghammer via lldb-dev 
>  wrote:
> 
> Hi All,
> 
> The current LLDB API reference documentation available at 
> http://lldb.llvm.org/python_reference/ 
>  and at 
> http://lldb.llvm.org/cpp_reference/html/ 
>  but it haven't been updated since 
> July 2013.
> 
> I am planning to regenerate it next week using "ninja lldb-cpp-doc 
> lldb-python-doc" (from a Linux machine using epydoc 3.0.1 and doxygen 1.8.6) 
> to get them up to date. Is there any objection against it?
> 
> Additionally, in the future it would be great if we can keep the generated 
> doc more up to date after additions to the SB API so users of LLDB can rely 
> it.

There is a bot continuously updating http://llvm.org/docs/ 
 ; ideally we should be able to hook the other LLVM 
sub-projects there.

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

Re: [lldb-dev] fate of TimeValue

[Mehdi Amini via lldb-dev]

> On Oct 7, 2016, at 10:19 PM, Pavel Labath  wrote:
> 
> On 7 October 2016 at 21:42, Mehdi Amini  wrote:
>> 
>>> On Oct 7, 2016, at 9:30 PM, Pavel Labath via lldb-dev 
>>>  wrote:
>>> 
>>> The llvm-dev thread seems to have fizzed out - I would assume they are
>>> not interested in std::chrono.
>> 
>> I suggest a totally different course of action: any utility (except specific 
>> to the debugger for some reason) should be submitted into LLVM (Support?).
>> I may be happy to have it available next months in LLVM, and I may not think 
>> about looking in every subproject.
>> 
>> The question is not if “they” (I rather have you guys say “we”) are not 
>> interested, but rather “is anyone opposing to having utilities wrapping / 
>> manipulating std::chrono in LLVM”.
>> 
> 
> I like that idea. I've added you to the reviews so you can see what
> kind of utility functions I am talking about. BTW, LLVM seems to have
> a TimeValue class as well (presumably because not all compilers used
> to support std::chrono)

I believe TimeValue was created before std::chrono was standardized (first 
committed in 2004!)

> - one possibility would be to start using that
> instead, although I would prefer std::chrono.

Indeed, I believe we tend to move to the standard version of our utilities when 
the feature is complete in the compiler versions we support. 

It is also possible that not all of TimeValue features are supported by 
std::chrono, I haven't compared in detail.

— 
Mehdi

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

Re: [lldb-dev] fate of TimeValue

[Mehdi Amini via lldb-dev]

> On Oct 7, 2016, at 9:30 PM, Pavel Labath via lldb-dev 
>  wrote:
> 
> The llvm-dev thread seems to have fizzed out - I would assume they are
> not interested in std::chrono.

I suggest a totally different course of action: any utility (except specific to 
the debugger for some reason) should be submitted into LLVM (Support?). 
I may be happy to have it available next months in LLVM, and I may not think 
about looking in every subproject.

The question is not if “they” (I rather have you guys say “we”) are not 
interested, but rather “is anyone opposing to having utilities wrapping / 
manipulating std::chrono in LLVM”. 

Thanks,

— 
Mehdi


> In any case, I've put the more
> interesting patches I have in my stack up for review, so you have a
> better idea of what I have in mind. and then we can decide what is the
> fate of the utility functions there.
> cheers,
> pl
> 
> On 6 October 2016 at 18:01, Pavel Labath  wrote:
>> I see one usage of of chrono in the Fuzzer, and that's about it.
>> 
>> On 6 October 2016 at 17:46, Zachary Turner  wrote:
>>> 
>>> I'd love to move over to chrono. For Utility functions such as those you
>>> propose probably we should consider whether they should go into llvm. Does
>>> llvm currently use anything from chrono or have any chrono support functions
>>> yet?
>>> On Thu, Oct 6, 2016 at 5:39 PM Pavel Labath via lldb-dev
>>>  wrote:
 
 Hello all,
 
 in line with the "deinventing the wheel" movement, I'd like to remove the
 TimeValue class from LLDB. I've done some research on a flight this week,
 and as far as I can tell all functionality can be easily replaced with
 appropriate usage of std::chrono::duration and time_point.
 
 The only parts that are missing are the ability to convert to/from legacy
 C types (struct timevalue, struct timespec), which can be replaced by
 utility functions.
 
 Also, I've found one use case particularly cumbersome to write in the c++
 way: writing out a duration as a fractional number of units (e.g.
 milliseconds). So, I'd propose adding the following utility function as 
 well
 (unless someone knows a cleaner way to write this):
 
 template
 double float_duration(DurIn dur) {
  return std::chrono::duration_cast>(dur).count();
 }
 
 Then, you can write float_duration(dur) to get the duration
 as a fractional number of milliseconds (used in printing time deltas in a
 human readable fashion).
 
 Any thoughts or objections?
 
 pl
 ___
 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] Adding D language demangling support

[Mehdi Amini via lldb-dev]

> On Sep 21, 2016, at 5:52 AM, Johan Engelen via lldb-dev 
>  wrote:
> 
> Hi all,
>   I recently looked into adding demangling support for D in LLDB, but got 
> lost in the code.
> (right now, basic D support is there with: https://reviews.llvm.org/D24794 
> )
> 
> I'd like some pointers to where demangling is done for the other languages, 
> and to where I should add D support for it.

C++ demangler is in libcxxabi (and a copy is kept in LLVM itself).

LLDB includes a “fast” demangler and falls back to the libcxxabi one when the 
“fast” one fails.

David Majnemer mentioned he was interested in rewriting a demangler 
functionality in LLVM, I don’t know the scope though (could it have a common 
infrastructure for multiple language/scheme?).


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

Re: [lldb-dev] LLDB Evolution - Final Form

[Mehdi Amini via lldb-dev]

> On Sep 20, 2016, at 2:46 PM, Zachary Turner  wrote:
> 
> Occasionally (and in my experience *very* occasionally), you need to treat "" 
> as different from null.

return an Optional?

— 
Mehdi



>   But the frequency with which that is really necessary is much lower than 
> people realize.  It just seems high because of the prevalence of raw pointers.
> 
> For every other case, you can use withNullAsEmpty()  (mostly used as a helper 
> for porting and when dealing with native APIs, which is to say quite a bit 
> right now, but in the long run, almost never (evidenced by the fact that it 
> only got added to LLVM a few days ago and nobody has ever needed it).
> 
> On Tue, Sep 20, 2016 at 2:41 PM Mehdi Amini  > wrote:
> 
> > On Sep 20, 2016, at 2:31 PM, Greg Clayton  > > wrote:
> >
> > We should avoid crashing if there is a reasonable work around when the 
> > input is bad. StringRef with NULL is easy, just put NULL and zero length 
> > and don't crash. Just because it is documented, doesn't mean it needs to 
> > stay that way, but I am not going to fight that battle.
> >
> > We should make every effort to not crash if we can. If it is way too 
> > difficult, document the issue and make sure clients know that this is the 
> > way things are. StringRef does this and we accept it. Doesn't mean it won't 
> > crash us. I just hate seeing the crash logs where we have:
> >
> > StringRef s(die.GetName());
> >
> > It shouldn't crash IMHO, but we know it does and we now code around it. 
> > Yes, we put in code like:
> >
> > StringRef s;
> > const char *cstr = die.GetName();
> > if (cstr)
> >s = cstr;
> >
> > Is this nice code?
> 
> Well no, it is indeed terrible: changing die.GetName() to return StringRef 
> make the code a lot safer.
> 
> When StringRef is used everywhere, this problem disappear by itself. 
> StringRef(const char *) is a very unsafe API, that is not intended to be used 
> *inside* the library (or very sporadically). So if you build a StringRef out 
> of a const char *, you’re supposed to be in a place that deals with 
> “uncontrolled” input and you need to sanitize it.
> 
> (Also StringRef(const char *) is “costly": it calls strlen)
> 
> —
> Mehdi
> 
> 
> 
> > I am glad it makes it simple for the LLVM side, but I would rather write:
> >
> > StringRef s(die.GetName());
> >
> > Maybe I will subclass llvm::StringRef as lldb::StringRef and override the 
> > constructor.
> >
> >
> >> On Sep 20, 2016, at 2:24 PM, Zachary Turner  >> > wrote:
> >>
> >> Well, but StringRef for example is well documented.  So it seems to me 
> >> like there's an example of a perfectly used assert.  It's documented that 
> >> you can't use null, and if you do it asserts.  Just like strlen.
> >>
> >> The issue I have with "you can't ever assert" is that it brings it into an 
> >> absolute when it really shouldn't be.  We already agreed (I think) that 
> >> certain things that are well documented can assert.  But when we talk in 
> >> absolutes, it tends to sway people that they should always do that thing, 
> >> even when it's not the most appropriate solution.  And I think some of 
> >> that shows in the LLDB codebase where you've got hugely complicated logic 
> >> that is very hard to follow, reason about, or test, because no assumptions 
> >> are ever made about any of the inputs.  Even when they are internal inputs 
> >> that are entirely controlled by us.
> >>
> >> On Tue, Sep 20, 2016 at 2:19 PM Greg Clayton  >> > wrote:
> >> Again, strlen is a stupid example as it is well documented. All of llvm 
> >> and clang are not.
> >>> On Sep 20, 2016, at 1:59 PM, Zachary Turner  >>> > wrote:
> >>>
> >>>
> >>>
> >>> On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton  >>> > wrote:
> >>>
>  On Sep 20, 2016, at 1:45 PM, Zachary Turner   > wrote:
> 
>  I do agree that asserts are sometimes used improperly.  But who's to say 
>  that the bug was the assert, and not the surrounding code?  For example, 
>  consider this code:
> 
>  assert(p);
>  int x = *p;
> >>>
> >>> Should be written as:
> >>>
> >>> assert(p);
> >>> if (!p)
> >>>do_something_correct();
> >>> else
> >>>int x = *p;
> >>>
> 
>  Should this assert also not be here in library code?  I mean it's 
>  obvious that the program is about to crash if p is invalid.  Asserts 
>  should mean "you're about to invoke undefined behavior", and a crash is 
>  *better* than undefined behavior.  It surfaces the problem so that you 
>  can't let it slip under the radar, and it also alerts you to the point 
>  that the UB is invoked, rather than later.
> 

Re: [lldb-dev] LLDB Evolution - Final Form

[Mehdi Amini via lldb-dev]

> On Sep 20, 2016, at 2:31 PM, Greg Clayton  wrote:
> 
> We should avoid crashing if there is a reasonable work around when the input 
> is bad. StringRef with NULL is easy, just put NULL and zero length and don't 
> crash. Just because it is documented, doesn't mean it needs to stay that way, 
> but I am not going to fight that battle.
> 
> We should make every effort to not crash if we can. If it is way too 
> difficult, document the issue and make sure clients know that this is the way 
> things are. StringRef does this and we accept it. Doesn't mean it won't crash 
> us. I just hate seeing the crash logs where we have:
> 
> StringRef s(die.GetName());
> 
> It shouldn't crash IMHO, but we know it does and we now code around it. Yes, 
> we put in code like:
> 
> StringRef s;
> const char *cstr = die.GetName();
> if (cstr)
>s = cstr;
> 
> Is this nice code?

Well no, it is indeed terrible: changing die.GetName() to return StringRef make 
the code a lot safer.

When StringRef is used everywhere, this problem disappear by itself. 
StringRef(const char *) is a very unsafe API, that is not intended to be used 
*inside* the library (or very sporadically). So if you build a StringRef out of 
a const char *, you’re supposed to be in a place that deals with “uncontrolled” 
input and you need to sanitize it. 

(Also StringRef(const char *) is “costly": it calls strlen)

— 
Mehdi



> I am glad it makes it simple for the LLVM side, but I would rather write:
> 
> StringRef s(die.GetName());
> 
> Maybe I will subclass llvm::StringRef as lldb::StringRef and override the 
> constructor.
> 
> 
>> On Sep 20, 2016, at 2:24 PM, Zachary Turner  wrote:
>> 
>> Well, but StringRef for example is well documented.  So it seems to me like 
>> there's an example of a perfectly used assert.  It's documented that you 
>> can't use null, and if you do it asserts.  Just like strlen.
>> 
>> The issue I have with "you can't ever assert" is that it brings it into an 
>> absolute when it really shouldn't be.  We already agreed (I think) that 
>> certain things that are well documented can assert.  But when we talk in 
>> absolutes, it tends to sway people that they should always do that thing, 
>> even when it's not the most appropriate solution.  And I think some of that 
>> shows in the LLDB codebase where you've got hugely complicated logic that is 
>> very hard to follow, reason about, or test, because no assumptions are ever 
>> made about any of the inputs.  Even when they are internal inputs that are 
>> entirely controlled by us.
>> 
>> On Tue, Sep 20, 2016 at 2:19 PM Greg Clayton  wrote:
>> Again, strlen is a stupid example as it is well documented. All of llvm and 
>> clang are not.
>>> On Sep 20, 2016, at 1:59 PM, Zachary Turner  wrote:
>>> 
>>> 
>>> 
>>> On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton  wrote:
>>> 
 On Sep 20, 2016, at 1:45 PM, Zachary Turner  wrote:
 
 I do agree that asserts are sometimes used improperly.  But who's to say 
 that the bug was the assert, and not the surrounding code?  For example, 
 consider this code:
 
 assert(p);
 int x = *p;
>>> 
>>> Should be written as:
>>> 
>>> assert(p);
>>> if (!p)
>>>do_something_correct();
>>> else
>>>int x = *p;
>>> 
 
 Should this assert also not be here in library code?  I mean it's obvious 
 that the program is about to crash if p is invalid.  Asserts should mean 
 "you're about to invoke undefined behavior", and a crash is *better* than 
 undefined behavior.  It surfaces the problem so that you can't let it slip 
 under the radar, and it also alerts you to the point that the UB is 
 invoked, rather than later.
 
 What about this assert?
 
 assert(ptr);
 int x = strlen(ptr);
 
 Surely that assert is ok right?  Do we need to check whether ptr is valid 
 EVERY SINGLE TIME we invoke strlen, or any other function for that matter? 
  The code would be a disastrous mess.
>>> 
>>> Again, check before you call if this is in a shared library! What is so 
>>> hard about that? It is called software that doesn't crash.
>>> 
>>> assert(ptr)
>>> int x = ptr ? strlen(ptr) : 0;
>>> 
>>> I find it hard to believe that you are arguing that you cannot EVER know 
>>> ANYTHING about the state of your program.  :-/
>>> 
>>> This is like arguing that you should run a full heap integrity check every 
>>> time you perform a memory write, just to be sure you aren't about to crash.
>>> 
>>> If you make a std::vector<>, do we need to verify that its internal pointer 
>>> is not null before we write to it?   Probably not, right?  Why not?  
>>> Because it has a specification of how it works, and it is documented that 
>>> you can construct one, you can use it.
>>> 
>>> It's ok to document how functions work, and it is ok to assume that 
>>> functions work the way they 

Re: [lldb-dev] LLDB Evolution - Final Form

[Mehdi Amini via lldb-dev]

> On Sep 20, 2016, at 2:19 PM, Greg Clayton  wrote:
> 
> Again, strlen is a stupid example as it is well documented. All of llvm and 
> clang are not.

IMO that is:

1) A free claim that is easily defeated (to prove you wrong on *all* of LLVM 
being not document I just have to point you to one example where it is).
2) Not productive or constructive attitude. I’m not sure where you go with that…

—
Mehdi

>> On Sep 20, 2016, at 1:59 PM, Zachary Turner  wrote:
>> 
>> 
>> 
>> On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton  wrote:
>> 
>>> On Sep 20, 2016, at 1:45 PM, Zachary Turner  wrote:
>>> 
>>> I do agree that asserts are sometimes used improperly.  But who's to say 
>>> that the bug was the assert, and not the surrounding code?  For example, 
>>> consider this code:
>>> 
>>> assert(p);
>>> int x = *p;
>> 
>> Should be written as:
>> 
>> assert(p);
>> if (!p)
>>do_something_correct();
>> else
>>int x = *p;
>> 
>>> 
>>> Should this assert also not be here in library code?  I mean it's obvious 
>>> that the program is about to crash if p is invalid.  Asserts should mean 
>>> "you're about to invoke undefined behavior", and a crash is *better* than 
>>> undefined behavior.  It surfaces the problem so that you can't let it slip 
>>> under the radar, and it also alerts you to the point that the UB is 
>>> invoked, rather than later.
>>> 
>>> What about this assert?
>>> 
>>> assert(ptr);
>>> int x = strlen(ptr);
>>> 
>>> Surely that assert is ok right?  Do we need to check whether ptr is valid 
>>> EVERY SINGLE TIME we invoke strlen, or any other function for that matter?  
>>> The code would be a disastrous mess.
>> 
>> Again, check before you call if this is in a shared library! What is so hard 
>> about that? It is called software that doesn't crash.
>> 
>> assert(ptr)
>> int x = ptr ? strlen(ptr) : 0;
>> 
>> I find it hard to believe that you are arguing that you cannot EVER know 
>> ANYTHING about the state of your program.  :-/
>> 
>> This is like arguing that you should run a full heap integrity check every 
>> time you perform a memory write, just to be sure you aren't about to crash.  
>> 
>> If you make a std::vector<>, do we need to verify that its internal pointer 
>> is not null before we write to it?   Probably not, right?  Why not?  Because 
>> it has a specification of how it works, and it is documented that you can 
>> construct one, you can use it.
>> 
>> It's ok to document how functions work, and it is ok to assume that 
>> functions work the way they claim to work.
> 

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

Re: [lldb-dev] LLDB Evolution - Final Form

[Mehdi Amini via lldb-dev]

> On Sep 20, 2016, at 10:33 AM, Greg Clayton  wrote:
> 
>> 
>> On Sep 19, 2016, at 2:46 PM, Mehdi Amini  wrote:
>> 
>>> 
>>> On Sep 19, 2016, at 2:34 PM, Greg Clayton  wrote:
>>> 
 
 On Sep 19, 2016, at 2:20 PM, Mehdi Amini  wrote:
 
> 
> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> 
>> On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev 
>>  wrote:
>> 
>> Following up with Kate's post from a few weeks ago, I think the dust has 
>> settled on the code reformat and it went over pretty smoothly for the 
>> most part.  So I thought it might be worth throwing out some ideas for 
>> where we go from here.  I have a large list of ideas (more ideas than 
>> time, sadly) that I've been collecting over the past few weeks, so I 
>> figured I would throw them out in the open for discussion.
>> 
>> I’ve grouped the areas for improvement into 3 high level categories.
>> 
>>  • De-inventing the wheel - We should use more code from LLVM, and 
>> delete code in LLDB where LLVM provides a solution.  In cases where 
>> there is an LLVM thing that is *similar* to what we need, we should 
>> extend the LLVM thing to support what we need, and then use it.  
>> Following are some areas I've identified.  This list is by no means 
>> complete.  For each one, I've given a personal assessment of how likely 
>> it is to cause some (temporary) hiccups, how much it would help us in 
>> the long run, and how difficult it would be to do.  Without further ado:
>>  • Use llvm::Regex instead of lldb::Regex
>>  • llvm::Regex doesn’t support enhanced mode.  Could we 
>> add support for this to llvm::Regex?
>>  • Risk: 6
>>  • Impact: 3
>>  • Difficulty / Effort: 3  (5 if we have to add enhanced 
>> mode support)
> 
> As long as it supports all of the features, then this is fine. Otherwise 
> we will need to modify the regular expressions to work with the LLVM 
> version or back port any advances regex features we need into the LLVM 
> regex parser. 
> 
>>  • Use llvm streams instead of lldb::StreamString
>>  • Supports output re-targeting (stderr, stdout, 
>> std::string, etc), printf style formatting, and type-safe streaming 
>> operators.
>>  • Interoperates nicely with many existing llvm utility 
>> classes
>>  • Risk: 4
>>  • Impact: 5
>>  • Difficulty / Effort: 7
> 
> I have worked extensively with both C++ streams and with printf. I don't 
> find the type safe streaming operators to be readable and a great way to 
> place things into streams. Part of my objection to this will be quelled 
> if the LLVM streams are not stateful like C++ streams are (add an extra 
> "std::hex" into the stream and suddenly other things down stream start 
> coming out in hex). As long as printf functionality is in the LLVM 
> streams I am ok with it.
> 
>>  • Use llvm::Error instead of lldb::Error
>>  • llvm::Error is an error class that *requires* you to 
>> check whether it succeeded or it will assert.  In a way, it's similar to 
>> a C++ exception, except that it doesn't come with the performance hit 
>> associated with exceptions.  It's extensible, and can be easily extended 
>> to support the various ways LLDB needs to construct errors and error 
>> messages.
>>  • Would need to first rename lldb::Error to LLDBError 
>> so that te conversion from LLDBError to llvm::Error could be done 
>> incrementally.
>>  • Risk: 7
>>  • Impact: 7
>>  • Difficulty / Effort: 8
> 
> We must be very careful here. Nothing can crash LLDB and adding something 
> that will be known to crash in some cases can only be changed if there is 
> a test that can guarantee that it won't crash. assert() calls in a shared 
> library like LLDB are not OK and shouldn't fire. Even if they do, when 
> asserts are off, then it shouldn't crash LLDB. We have made efforts to 
> only use asserts in LLDB for things that really can't happen, but for 
> things like constructing a StringRef with NULL is one example of why I 
> don't want to use certain classes in LLVM. If we can remove the crash 
> threat, then lets use them. But many people firmly believe that asserts 
> belong in llvm and clang code and I don't agree.
 
 I’m surprise by your aversion to assertions, what is your suggested 
 alternative? Are you expecting to check and handle every 

Re: [lldb-dev] LLDB Evolution - Final Form

[Mehdi Amini via lldb-dev]

> On Sep 19, 2016, at 2:34 PM, Greg Clayton  wrote:
> 
>> 
>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini  wrote:
>> 
>>> 
>>> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev 
>>>  wrote:
>>> 
>>> 
 On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev 
  wrote:
 
 Following up with Kate's post from a few weeks ago, I think the dust has 
 settled on the code reformat and it went over pretty smoothly for the most 
 part.  So I thought it might be worth throwing out some ideas for where we 
 go from here.  I have a large list of ideas (more ideas than time, sadly) 
 that I've been collecting over the past few weeks, so I figured I would 
 throw them out in the open for discussion.
 
 I’ve grouped the areas for improvement into 3 high level categories.
 
• De-inventing the wheel - We should use more code from LLVM, and 
 delete code in LLDB where LLVM provides a solution.  In cases where there 
 is an LLVM thing that is *similar* to what we need, we should extend the 
 LLVM thing to support what we need, and then use it.  Following are some 
 areas I've identified.  This list is by no means complete.  For each one, 
 I've given a personal assessment of how likely it is to cause some 
 (temporary) hiccups, how much it would help us in the long run, and how 
 difficult it would be to do.  Without further ado:
• Use llvm::Regex instead of lldb::Regex
• llvm::Regex doesn’t support enhanced mode.  Could we 
 add support for this to llvm::Regex?
• Risk: 6
• Impact: 3
• Difficulty / Effort: 3  (5 if we have to add enhanced 
 mode support)
>>> 
>>> As long as it supports all of the features, then this is fine. Otherwise we 
>>> will need to modify the regular expressions to work with the LLVM version 
>>> or back port any advances regex features we need into the LLVM regex 
>>> parser. 
>>> 
• Use llvm streams instead of lldb::StreamString
• Supports output re-targeting (stderr, stdout, 
 std::string, etc), printf style formatting, and type-safe streaming 
 operators.
• Interoperates nicely with many existing llvm utility 
 classes
• Risk: 4
• Impact: 5
• Difficulty / Effort: 7
>>> 
>>> I have worked extensively with both C++ streams and with printf. I don't 
>>> find the type safe streaming operators to be readable and a great way to 
>>> place things into streams. Part of my objection to this will be quelled if 
>>> the LLVM streams are not stateful like C++ streams are (add an extra 
>>> "std::hex" into the stream and suddenly other things down stream start 
>>> coming out in hex). As long as printf functionality is in the LLVM streams 
>>> I am ok with it.
>>> 
• Use llvm::Error instead of lldb::Error
• llvm::Error is an error class that *requires* you to 
 check whether it succeeded or it will assert.  In a way, it's similar to a 
 C++ exception, except that it doesn't come with the performance hit 
 associated with exceptions.  It's extensible, and can be easily extended 
 to support the various ways LLDB needs to construct errors and error 
 messages.
• Would need to first rename lldb::Error to LLDBError 
 so that te conversion from LLDBError to llvm::Error could be done 
 incrementally.
• Risk: 7
• Impact: 7
• Difficulty / Effort: 8
>>> 
>>> We must be very careful here. Nothing can crash LLDB and adding something 
>>> that will be known to crash in some cases can only be changed if there is a 
>>> test that can guarantee that it won't crash. assert() calls in a shared 
>>> library like LLDB are not OK and shouldn't fire. Even if they do, when 
>>> asserts are off, then it shouldn't crash LLDB. We have made efforts to only 
>>> use asserts in LLDB for things that really can't happen, but for things 
>>> like constructing a StringRef with NULL is one example of why I don't want 
>>> to use certain classes in LLVM. If we can remove the crash threat, then 
>>> lets use them. But many people firmly believe that asserts belong in llvm 
>>> and clang code and I don't agree.
>> 
>> I’m surprise by your aversion to assertions, what is your suggested 
>> alternative? Are you expecting to check and handle every possible invariants 
>> everywhere and recover (or signal an error) properly? That does not seem 
>> practical, and it seems to me that it'd lead to just involving UB (or 
>> breaking design invariant) without actually noticing it.
> 
> We have to as a debugger. We get input from a variety of different 

Re: [lldb-dev] LLDB Evolution

[Mehdi Amini via lldb-dev]

> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Back to the formatting issue, there's a lot of code that's going to look bad 
> after the reformat, because we have some DEEPLY indented code.  LLVM has 
> adopted the early return model for this reason.  A huge amount of our deeply 
> nested code could be solved by using early returns.  For example, here's some 
> code in a function I was just looking at:
> 
> // The 'A' packet is the most over designed packet ever here with
> // redundant argument indexes, redundant argument lengths and needed hex
> // encoded argument string values. Really all that is needed is a comma
> // separated hex encoded argument value list, but we will stay true to the
> // documented version of the 'A' packet here...
> 
> Log *log (GetLogIfAnyCategoriesSet(LIBLLDB_LOG_PROCESS));
> int actual_arg_index = 0;
> 
> packet.SetFilePos(1); // Skip the 'A'
> bool success = true;
> while (success && packet.GetBytesLeft() > 0)
> {
> // Decode the decimal argument string length. This length is the
> // number of hex nibbles in the argument string value.
> const uint32_t arg_len = packet.GetU32(UINT32_MAX);
> if (arg_len == UINT32_MAX)
> success = false;
> else
> {
> // Make sure the argument hex string length is followed by a comma
> if (packet.GetChar() != ',')
> success = false;
> else
> {
> // Decode the argument index. We ignore this really because
> // who would really send down the arguments in a random 
> order???
> const uint32_t arg_idx = packet.GetU32(UINT32_MAX);
> if (arg_idx == UINT32_MAX)
> success = false;
> else
> {
> // Make sure the argument index is followed by a comma
> if (packet.GetChar() != ',')
> success = false;
> else
> {
> // Decode the argument string value from hex bytes
> // back into a UTF8 string and make sure the length
> // matches the one supplied in the packet
> std::string arg;
> if (packet.GetHexByteStringFixedLength(arg, arg_len) 
> != (arg_len / 2))
> success = false;
> else
> {
> // If there are any bytes left
> if (packet.GetBytesLeft())
> {
> if (packet.GetChar() != ',')
> success = false;
> }
> 
> if (success)
> {
> if (arg_idx == 0)
> 
> m_process_launch_info.GetExecutableFile().SetFile(arg.c_str(), false);
> 
> m_process_launch_info.GetArguments().AppendArgument(arg.c_str());
> if (log)
> log->Printf ("LLGSPacketHandler::%s added 
> arg %d: \"%s\"", __FUNCTION__, actual_arg_index, arg.c_str ());
> ++actual_arg_index;
> }
> }
> }
> }
> }
> }
> }
> 
> 
> 
> Whether we like early return or not, it is the LLVM Style, and when you have 
> to deal with an 80 column wrapping limitation, it definitely helps.  For 
> example, the above function becomes:

Since you’re going with the LLVM style, just a few notes (maybe you quickly 
added the early return without clang-formatting): 

> 
> // The 'A' packet is the most over designed packet ever here with
> // redundant argument indexes, redundant argument lengths and needed hex
> // encoded argument string values. Really all that is needed is a comma
> // separated hex encoded argument value list, but we will stay true to the
> // documented version of the 'A' packet here...
> 
> Log *log (GetLogIfAnyCategoriesSet(LIBLLDB_LOG_PROCESS));
> int actual_arg_index = 0;
> 
> packet.SetFilePos(1); // Skip the 'A'
> while (packet.GetBytesLeft() > 0)
> {

Actually I believe the opening bracket here should be on the same line as the 
while.

> // Decode the decimal argument string length. This length is the
> // number of hex nibbles in the argument string value.
> const uint32_t arg_len = packet.GetU32(UINT32_MAX);
>   if (arg_len == UINT32_MAX)

Any reason the if isn’t on the same indentation as the previous line? (As for 
almost every other if apparently)

> 

Re: [lldb-dev] Passing std::atomics by value

[Mehdi Amini via lldb-dev]

> On Aug 26, 2016, at 1:13 PM, Zachary Turner  wrote:
> 
> IOW, marking it =delete() is no different than deleting the copy constructor 
> above, but at least if you mark it delete, maybe someone will read the 
> comment above it that explains why it's deleted :)

Got it, make sense.

Thanks.

— 
Mehdi


> 
> On Fri, Aug 26, 2016 at 1:13 PM Zachary Turner  > wrote:
> I think so.  But in this case lldb::Address explicitly supplied a copy 
> constructor that looked like this:
> 
> Address (const Address& rhs) :
> m_section_wp (rhs.m_section_wp),
> m_offset(rhs.m_offset.load())   // this is the std::atomic<>
> {
> }
> 
> circumventing the problem.
> 
> On Fri, Aug 26, 2016 at 1:11 PM Mehdi Amini  > wrote:
>> On Aug 26, 2016, at 1:02 PM, Zachary Turner via lldb-dev 
>> > wrote:
>> 
>> It seems to be.  I will also make the copy constructor =delete() to make 
>> sure this cannot happen again.
> 
> Just curious: if a member has a deleted copy-ctor (like std::atomic right?), 
> isn’t the copy constructor automatically deleted?
> 
> — 
> Mehdi
> 
> 
>> 
>> I'm still concerned that the std::atomic is unnecessary, but at that point 
>> at least it just becomes a performance problem and not a bug.
>> 
>> On Fri, Aug 26, 2016 at 1:00 PM Greg Clayton > > wrote:
>> So after speaking with local experts on the subject, we do indeed have a 
>> problem. Please convert all placed where we pass lldb_private::Address by 
>> value to pass by "const Address &". Anyone that is modifying the address 
>> should make a local copy and work with that.
>> 
>> Is Address the only class that is causing problems?
>> 
>> Greg
>> 
>> > On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev 
>> > > wrote:
>> >
>> > I recently updated to Visual Studio 2015 Update 3, which has improved its 
>> > diagnostics.  As a result of this, LLDB is uncompilable due to a slew of 
>> > errors of the following nature:
>> >
>> > D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error C2719: 
>> > 'default_stop_addr': formal parameter with requested alignment of 8 won't 
>> > be aligned
>> >
>> > The issue comes down to the fact that lldb::Address contains a 
>> > std::atomic, and is being passed by value pervasively throughout 
>> > the codebase.  There is no way to guarantee that this value is 8 byte 
>> > aligned.  This has always been a bug, but until now the compiler just 
>> > hasn't been reporting it.
>> >
>> > Someone correct me if I'm wrong, but I believe this is a problem on any 
>> > 32-bit platform, and MSVC is just the only one erroring.
>> >
>> > I'm not really sure what to do about this.  Passing std::atomic's 
>> > by value seems wrong to me.
>> >
>> > Looking at the code, I don't even know why it needs to be atomic.  It's 
>> > not even being used safely.  We'll have a single function write the value 
>> > and later read the value, even though it could have been used in the 
>> > meantime.  Maybe what is really intended is a mutex.  Or maybe it doesn't 
>> > need to be atomic in the first place.
>> >
>> > Does anyone have a suggestion on what to do about this?  I'm currently 
>> > blocked on this as I can't compile LLDB.
>> > ___
>> > 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] Passing std::atomics by value

[Mehdi Amini via lldb-dev]

> On Aug 26, 2016, at 1:02 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> It seems to be.  I will also make the copy constructor =delete() to make sure 
> this cannot happen again.

Just curious: if a member has a deleted copy-ctor (like std::atomic right?), 
isn’t the copy constructor automatically deleted?

— 
Mehdi


> 
> I'm still concerned that the std::atomic is unnecessary, but at that point at 
> least it just becomes a performance problem and not a bug.
> 
> On Fri, Aug 26, 2016 at 1:00 PM Greg Clayton  > wrote:
> So after speaking with local experts on the subject, we do indeed have a 
> problem. Please convert all placed where we pass lldb_private::Address by 
> value to pass by "const Address &". Anyone that is modifying the address 
> should make a local copy and work with that.
> 
> Is Address the only class that is causing problems?
> 
> Greg
> 
> > On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev 
> > > wrote:
> >
> > I recently updated to Visual Studio 2015 Update 3, which has improved its 
> > diagnostics.  As a result of this, LLDB is uncompilable due to a slew of 
> > errors of the following nature:
> >
> > D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error C2719: 
> > 'default_stop_addr': formal parameter with requested alignment of 8 won't 
> > be aligned
> >
> > The issue comes down to the fact that lldb::Address contains a 
> > std::atomic, and is being passed by value pervasively throughout 
> > the codebase.  There is no way to guarantee that this value is 8 byte 
> > aligned.  This has always been a bug, but until now the compiler just 
> > hasn't been reporting it.
> >
> > Someone correct me if I'm wrong, but I believe this is a problem on any 
> > 32-bit platform, and MSVC is just the only one erroring.
> >
> > I'm not really sure what to do about this.  Passing std::atomic's 
> > by value seems wrong to me.
> >
> > Looking at the code, I don't even know why it needs to be atomic.  It's not 
> > even being used safely.  We'll have a single function write the value and 
> > later read the value, even though it could have been used in the meantime.  
> > Maybe what is really intended is a mutex.  Or maybe it doesn't need to be 
> > atomic in the first place.
> >
> > Does anyone have a suggestion on what to do about this?  I'm currently 
> > blocked on this as I can't compile LLDB.
> > ___
> > 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] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Mehdi Amini via lldb-dev]

> On Jul 8, 2016, at 1:05 PM, Renato Golin  wrote:
> 
> On 8 July 2016 at 21:04, Mehdi Amini  wrote:
>>> What about git describe?
>> 
>> Not a number.
> 
> It contains a number... "tag-number-hash"
> 
> Removing the tag and hash seems trivial.

And you end up with a number that is not unique across branch.

The problem is not that is it is not possible to work with a tuple (branch, 
number), the problem is that a tuple (or a string) is not a number and breaks 
existing infrastructure. It does not mean it cannot be made to work, but it 
won’t out-of-the-box.
(Imagine that the LNT  database needs an integer id for instance, and this id 
is usually the SVN rev, unique across branches).

— 
Mehdi

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

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Mehdi Amini via lldb-dev]

Sent from my iPhone

> On Jul 8, 2016, at 9:18 AM, Renato Golin  wrote:
> 
>> On 8 July 2016 at 03:14, Robinson, Paul  wrote:
>> I could see wanting to compare data from master and a release branch.  If
>> that means sequential IDs need to work across branches, then we're back to
>> needing a fancier solution than 'rev-list –count'.
> 
> How would you do this in SVN anyway?
> 
> Branch commits are inter-twined with trunk commits, and comparing them
> numerically doesn't yield the results you expect.

If I give the revision that corresponds to some 3.8 branch commit and compare 
to another in master, I think I get exactly the result I expect. 
I may not understand your point here...


> 
> At least in Git, the history is tied up via "parent" and not via
> sequential IDs, so you can actually walk the path.
> 
> Sequential numbers are only meaningful for linear histories. Branches,
> whether on Git or Svn break that promise.

SVN has monotonic increasing ids that are unique across branches.


> 
> If we make LNT work with Git "as Git", then all problems are solved.
> And meanwhile, we get to work with LNT "as SVN" via rev-list --count.

You missed the point that in a single instance of LNT a revision number has to 
be unique. 
The rev-list thing won't provide this across branches.
A rev-list count number won't identify a revision, you need the tuple (branch, 
count), which is less easy or less compatible with existing systems.

-- 
Mehdi


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

Re: [lldb-dev] [llvm-dev] Sequential ID Git hook

[Mehdi Amini via lldb-dev]

> On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev 
>  wrote:
> 
> Quick re-cap.
> 
> After a few rounds, not only the "external server" proposal got
> obliterated as totally unnecessary, but the idea that we may even need
> a hook at all is now challenged.

This is not clear to me. 
How is the umbrella repository updated?

— 
Mehdi



> 
> Jared's idea to use "git describe" is in line with previous proposals
> to use rev-list --count and to do so only up to the previous tag, but
> all in one nice and standard little feature.
> 
> There were concerns by applying one tag per commit, but most of them
> offered weak evidence. However, if "describe" can cover all our needs,
> there is no point in even discussing tags.
> 
> Just for reference, GitHub *does* have an SVN interface [1], and you
> can already checkout a specific revision with "svn checkout -r NNN
> repo", which *is already* using "git rev-list --count".
> 
> This means that, for SVN based bisects, using GitHub will make it
> *completely transparent* for SVN users. You can also base your
> releases off an SVN view of the Git repo.
> 
> So, to clear up this discussion and finish my proposal to move to
> GitHub, my final questions, only to those that *want* SVN
> compatibility:
> 
> 1. Is there anything in the SVN view of GitHub that *doesn't* work for
> you? (ie. same as using "rev-list --count")
> 
> 2. If so, can "git describe" solve the problem?
> 
> 3. If not, please describe, in details, why < solution>> would be the *only* way forward.
> 
> I'll let this sit for a few days, and if no one has any serious issue,
> I'll write up the final proposal and start the voting process with the
> Foundation.
> 
> cheers,
> --renato
> 
> [1] https://github.com/blog/626-announcing-svn-support
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Mehdi Amini via lldb-dev]

> On Jun 28, 2016, at 1:55 AM, NAKAMURA Takumi via llvm-dev 
>  wrote:
> 
> It has also submodules. 
> https://github.com/llvm-project/llvm-project-submodule 
> 
> 
> Both llvm-project(-tree) and (-submodule) have refs/notes/commits.

This is easy to compute when coming from SVN, the difficulty will be to keep 
this when having multiple git repo as a source.

— 
Mehid


> 
> On Tue, Jun 28, 2016 at 1:13 AM Renato Golin via llvm-dev 
> > wrote:
> On 27 June 2016 at 17:03, Rafael Espíndola  > wrote:
> > I think that trying to create a ordering/rev number between independent git
> > repositories is fundamentally unreliable.
> >
> > If we want to keep llvm and clang in lock step we should probably probably
> > just have them in the same repository like
> > https://github.com/llvm-project/llvm-project 
> > .
> 
> That is similar to the proposal we have, except that llvm-projects
> will have sub-modules.
> 
> Having all of them in the same physical repository is a big problems
> for those that only use a small subset of the components, which is the
> vast majority of users, most of the time (all buildbots, Jenkins,
> local development, downstream users, even releases don't clone all
> repos).
> 
> cheers,
> --renato
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
> 
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Mehdi Amini via lldb-dev]

> On Jun 13, 2016, at 5:56 PM, Saleem Abdulrasool <compn...@compnerd.org> wrote:
> 
> On Mon, Jun 13, 2016 at 5:01 PM, Mehdi Amini via lldb-dev 
> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> > On Jun 13, 2016, at 4:54 PM, Hans Wennborg <h...@chromium.org 
> > <mailto:h...@chromium.org>> wrote:
> >
> > Breaking this out into a separate thread since it's kind of a separate
> > issue, and to make sure people see it.
> 
> Thanks!
> 
> >
> > If you have opinions on this, please chime in. I'd like to collect as
> > many arguments here as possible to make a good decision. The main
> > contestants are 4.0 and 3.10, and I've seen folks being equally
> > surprised by both.
> >
> > Brain-dump so far:
> >
> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
> > comes after 3.9.
> >
> > - There are special bitcode stability rules [1] concerning major
> > version bumps. 2.0 and 3.0 had major IR changes, but since there
> > aren't any this time, we should go to 3.10.
> >
> > - The bitcode stability rules allow for breakage with major versions,
> > but it doesn't require it, so 4.0 is fine.
> 
> (basically repeating my point of the other thread here)
> Bumping the major version number without changing the bitcode compatibility 
> rule would mean dropping the current guarantee on this aspect. I doubt we 
> want to go this route without a good reason.
> 
> Completely agree with you here: unless we have a reason to break backwards 
> compatibility at the bit code level for this release, I don't see a 
> compelling reason to bump the major version number to 4.0.  As such, I would 
> expect that the next release would be 3.10.

To clarify my point: I don't have a particular opinion about bumping the major 
number for whatever other reason than breaking the compatibility, but I'd 
probably suggest that we rewrite the compatibility policy to say something like 
"The current LLVM version support loading any bitcode since version 3.0".


-- 
Mehdi

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

Re: [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Mehdi Amini via lldb-dev]

> On Jun 13, 2016, at 4:54 PM, Hans Wennborg  wrote:
> 
> Breaking this out into a separate thread since it's kind of a separate
> issue, and to make sure people see it.

Thanks!

> 
> If you have opinions on this, please chime in. I'd like to collect as
> many arguments here as possible to make a good decision. The main
> contestants are 4.0 and 3.10, and I've seen folks being equally
> surprised by both.
> 
> Brain-dump so far:
> 
> - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
> comes after 3.9.
> 
> - There are special bitcode stability rules [1] concerning major
> version bumps. 2.0 and 3.0 had major IR changes, but since there
> aren't any this time, we should go to 3.10.
> 
> - The bitcode stability rules allow for breakage with major versions,
> but it doesn't require it, so 4.0 is fine.

(basically repeating my point of the other thread here)
Bumping the major version number without changing the bitcode compatibility 
rule would mean dropping the current guarantee on this aspect. I doubt we want 
to go this route without a good reason.

-- 
Mehdi


> 
> - But maybe we want to save 4.0 for when we do have a significant IR change?
> 
> - We've never had an x.10 version before; maybe that would be
> confusing? Perhaps it's simply time to move on (like Linux 2.6.39 ->
> 3.0 and 3.19 -> 4.0).
> 
> - Since we do time-based rather than feature-based releases, the major
> version number shouldn't mean anything special anyway (e.g. big IR
> changes or not), so 4.0?
> 
> - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
> a tuple after all.
> 
> - Let's go for 4.0 now, and 5.0 after that. Then the "dot"-releases in
> between would correspond to minor version bumps, which would make
> sense (and catch up with GCC!).
> 
> - It's just a number, no big deal; flip a coin or something.
> 
> What do you think?
> 
> - Hans
> 
> 
> [1]. http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 4:28 PM, Tanya Lattner  wrote:
> 
> 
> 
>> On Jun 2, 2016, at 12:18 PM, Mehdi Amini  wrote:
>> 
>> 
>>> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev 
>>>  wrote:
>>> 
>>> I personally find this email thread very hard to follow and read (this 
>>> isn’t anyones fault.. its just a lot of replies). I am sure others do as 
>>> well. I think it would be good to have a form/survey of some sort that can 
>>> get feedback from users such as: who they are, how they use 
>>> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
>>> etc. People could then submit their feedback in an organized way and we 
>>> could get a better idea of how the community feels on the topic. 
>>> 
>>> I am happy to try to set something like this up.
>> 
>> I don't think it is a good idea to set this up like that without having a 
>> well defined plan first.
>> My idea is rather that we should first try to see what is doable in term of 
>> server-side hook and integration so that the "poll" is not about naked "svn 
>> vs git", but about "svn vs 
>> git-with-this-server-side-setup-that-preserve-our-workflow".
>> 
> 
> Sure, I am fine with flushing out those details out. Just an idea to get a 
> better idea of the consensus when the time comes.

We're on the same page.

-- 
Mehdi

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:51 AM, d...@cray.com wrote:
> 
> Mehdi Amini via cfe-dev  writes:
> 
>> My opinion is that submodules or not is an implementation details. For
>> the sake of this high-level discussion we should be able to keep it as
>> "submodules" meaning "some system to integrate and manage different
>> repositories coherently".
>> We should evaluate subtree as well, as you mentioned, but also the
>> tradeoff of other tools like repo (Android).
> 
> Fair enough.  It might be less confusing to use a term other that
> "submodule" though.  I've used "superproject/subproject" in the past,
> for example, and also "host repository" and "project repository."

It does not even represent the full set of possibility: having a *separate* 
"integration repository" is what *I* think would be better. Some people 
proposed submodules in the llvm repo to track the subprojects, with a possible 
auto-update on push to the other repos. In this case there is no "super 
project" or separate repo.
I'm not trying to force a design on anyone here.

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:22 AM, d...@cray.com wrote:
> 
> Matthias Braun via cfe-dev  writes:
> 
>> 3. Make sure we have ala llvm-project-submodules setup in the official
>> account. (Optional or necessary for the buildbots?)
> 
>> 7. Make sure bisecting with llvm-project-submodules is a good experience
> 
> I would like to have a fuller discussion about how to handle the
> multiple repositories before going forward.  Submodules is not the only
> solution available and we should take some time to evaluate what's out
> there.  There are definite downsides to submodules (and all the various
> solutions) and I personally need to better understand the tradeoffs.

My opinion is that submodules or not is an implementation details. For the sake 
of this high-level discussion we should be able to keep it as "submodules" 
meaning "some system to integrate and manage different repositories coherently".
We should evaluate subtree as well, as you mentioned, but also the tradeoff of 
other tools like repo (Android).

-- 
Mehdi


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

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:22 AM, Robinson, Paul  wrote:
> 
>>> How do you get monotonically increasing number with a history graph?
>> 
>> I think what we're trying to get is a "pushed" revision number, i.e.
>> tracking the state of the upstream repositories at a given time.
> 
> I think I've mentioned this before but internally we are (mostly) using
> "rev-list --count --first-parent branch-name" which gives us a 
> monotonically increasing number per-branch.  The --first-parent means 
> each merge counts as one, which is enough for build-number uniqueness.
> Unique sequential build numbers meet our internal needs.  If this number
> gets incorporated into the version numbering self-reported by Clang/LLVM,
> then it's not hard to map back onto git commits.

I think I've answered to this before but it does not help to solve the 
cross-repository problem, we need a "meta integration repository".

-- 
Mehdi

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:03 AM, d...@cray.com wrote:
> 
> Tim Northover via cfe-dev <cfe-...@lists.llvm.org> writes:
> 
>> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
>> <lldb-dev@lists.llvm.org> wrote:
>>> Apparently I wasn't very clear: llvm and clang (and the others
>>> projects) would be simple decoupled, individual git
>>> repositories. You would be able to check them out however you want
>>> and commit to them individually.
>>> There would be an extra "integration repository" on top that would
>>> only provide the service that tells "r12345 is llvm:36c941c
>>> clang:eaf492b compiler-rt:6d77ea5". This repository should be
>>> managed transparently by some server-side integration.
>> 
>> This actually sounds like a really good idea even if a full move to
>> git gets blocked for some reason. It seems like it could be a fairly
>> common requirement: I don't suppose you know of an existing script
>> that could do it? If not, I may take a stab.
> 
> How do you get monotonically increasing number with a history graph?

I think what we're trying to get is a "pushed" revision number, i.e. tracking 
the state of the upstream repositories at a given time.


> There are multiple ways to linearize the history.
> 
> You can simply disallow merges I guess but that seems not much better
> than just sticking with SVN.  GitHub's pull request model kind of breaks
> down if you can't do merges.

Github has an automatic "squashed" mode for pull requests now, I haven't tested 
in practice but it may help.

-- 
Mehdi

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:01 AM, d...@cray.com wrote:
> 
> Mehdi Amini via llvm-dev  writes:
> 
>>> Personally, I’m hugely in favor of moving llvm’s source hosting to
>>> github at some point, despite the fact that I continue to dislike
>>> git as a tool and consider monotonicly increasing version numbers to
>>> be hugely beneficial.
>> 
>> Getting a monotonically increasing revision number seems doable in git
>> with some server-side scripting using git notes or named tags (yet to
>> be seen is how to achieve it *reliably* with github hosting).
>> However the challenge is more about sharing this number across
>> repositories (i.e. having clang and llvm in sync). I can imagine some
>> tooling for that, but with a github hosting it may still be fragile.
> 
> What exactly is the concrete benefit of monotonically increasing
> revision numbers?  It's completely foreign to git's architecture.

I'm notified that bug is fixed in r12345, my binary says "clang -v" is r23456, 
if I observe the bug I know there is a problem immediately.
Another use case is that it provides a cross-repository reference.

I'm sure that if you lookup the previous discussion about moving to git (two 
years ago, and four years ago I believe), the threads contain plenty of 
arguments from people attached to it.
I don't want to play the "devil's advocate" here since I'm not that bothered by 
loosing this.

> 
> Putting this requirement on git is going to severely limit how the
> history is allowed to look.  Maybe that's what people want, I don't
> know.  We certainly haven't missed them since moving to git.

I'm personally fine with arbitrary history in git, but some people (I suspect 
many here) are attached to the linear history. 
So my impression is that such a move has more chances of being accepted by the 
community if we keep the same workflow (linear history + monotonic revision 
numbers), at least at first.


-- 
Mehdi

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 1, 2016, at 11:51 AM, Matthias Braun  wrote:
> 
> So here's a straw-man proposal for a github migration:
> 
> 1. Register an official github project with the llvm foundation.
> 2. Setup another (read-only) mirror of llvm.org/git at this github project
> 3. Make sure we have ala llvm-project-submodules setup in the official 
> account. (Optional or necessary for the buildbots?) 
> 4. Update the buildbots to pick up updates and commits from the official git 
> repository
> 5. Update phabricator to pick up commits from the official git repository
> 6. Tell people living downstream to pick up commits from the official git 
> repository
> 7. Make sure bisecting with llvm-project-submodules is a good experience
> 8. Give things time to settle. We could play some games like disabling the 
> svn repository for a few hours on purpose so that people can test that their 
> infrastructure has really become independent of the svn repository.
> 9. Review and update llvm documentation.
> 10. Review website links pointing to viewvc/klaus/phab etc. to point to 
> github instead.
> ... Until this point nothing has changed for developers, it will just boil 
> down to a lot of work for buildbot and other infrstructure owners ...
> 11. Collect peoples github account information, give them push access. 
> Ideally while still locking the github repository somehow...
> 12. Switch svn repository to read-only and allow pushs to the github 
> repository.

12.2: mirror git to svn :)

> 13. Disable/remove/archive the svn repository.


LGTM, this is how I'd approach it as well, thanks for writing it down!

-- 
Mehdi

> 
> - Matthias
> 
>> On Jun 1, 2016, at 11:31 AM, Mehdi Amini via llvm-dev 
>>  wrote:
>> 
>> 
>>> On Jun 1, 2016, at 11:18 AM, Renato Golin via llvm-dev 
>>>  wrote:
>>> 
>>> On 1 June 2016 at 17:02, John Criswell  wrote:
 Do you have a set of volunteers lined up to do such a migration? Getting
 people willing to do the migration will obviously be key, and that was the
 one thing I didn't see in the original email.
>>> 
>>> Hi John,
>>> 
>>> Well, first we need to know if people are in favour, then if the
>>> migration won't bring any serious problem, and then we can think of a
>>> migration plan. :)
>>> 
>>> So far, it seems people are mostly in favour, with a few that reported
>>> being locked into SVN. I had anticipated that, and have proposed
>>> GitHub's SVN integration, which allows read-write access, so it should
>>> be mostly ok. We need more tests on that side to be sure, though.
>>> 
>>> The biggest problem we're facing right now is how to sync the repos.
>>> The existing llvm-repos format with all projects as sub-modules seem
>>> to be a good candidate, but I still haven't seen a consensus on how
>>> we'd do that.
>>> 
>>> About the migration plan, most people seem to agree a step-by-step
>>> process is necessary.
>> 
>> I personnally disagree with that, see below.
>> 
>>> So, first we move to git-only, possibly with
>>> sub-modules
>> 
>> If you move to git-only without the rest of the infrastructure/scripts, 
>> we're losing the convenience we have today with svn, and the "user 
>> experience" will not be so great. We may face resistance to this change.
>> I advocate to first set it up till it reaches the point of "good enough" in 
>> term of usability before actually migrating.
>> 
>>> , then we move to GitHub/Lab/BB,
>> 
>> It means we first need to host our git, write the tooling around it, to then 
>> migrate to github. I don't see the benefit over migrating directly to 
>> github: if people have to change their configuration, better have one single 
>> change.
>> 
>>> then we move Phab to
>>> GitHub merge requests, etc.
>> 
>> Phab to GitHub merge requests is a totally separate discussion IMO, and this 
>> discussion can happen after a successful move.
>> 
>> 
>>> 
>>> Regarding volunteers, I haven't yet asked around yet, but I'm sure we
>>> have enough interested people to help. If everything else fails, I'm
>>> more than happy to do all of that myself. Though, I'd have to learn a
>>> lot more about sub-modules than I know today, which is effectively
>>> nothing. :)
>> 
>> I'll be happy to throw manpower into tooling/infrastructure to make it 
>> happen.
>> 
>> -- 
>> Mehdi
>> 
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 1, 2016, at 10:19 AM, Tim Northover via llvm-dev 
>  wrote:
> 
> On 1 June 2016 at 10:12, Dan Liew via cfe-dev  wrote:
>> the directories for each submodule will stay empty. Thus it isn't
>> necessary to pull down all the sources when using git submodules.
>> This would need support from the build system though. I'm not sure
>> what the build system would do right now if it found an empty
>> ``tools/clang`` directory in the source tree.
> 
> You can't have submodules within submodules like that (or at least it
> didn't let me yesterday). For Unixy systems a simple "ln -s clang
> llvm/tools" from the top-level should do the trick, but I vaguely
> remember that Windows have issues with symlinks?
> 
> If so, we might have to restructure our CMake and we'd be able to fix
> that at the same time.

CMake already supports not having clang in tools with 
-DLLVM_EXTERNAL_CLANG_SOURCE_DIR=path/to/clang

-- 
Mehdi

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 4:06 PM, Robinson, Paul  wrote:
> 
> 
> 
>> -Original Message-
>> From: mehdi.am...@apple.com [mailto:mehdi.am...@apple.com]
>> Sent: Tuesday, May 31, 2016 3:54 PM
>> To: Robinson, Paul
>> Cc: Bill Kelly; Clang Dev; LLDB Dev; llvm-...@lists.llvm.org
>> Subject: Re: [llvm-dev] GitHub anyone?
>> 
>> 
>>> On May 31, 2016, at 3:38 PM, Robinson, Paul 
>> wrote:
>>> 
>>> 
>>> 
 -Original Message-
 From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
>> Mehdi
 Amini via llvm-dev
 Sent: Tuesday, May 31, 2016 2:38 PM
 To: Bill Kelly
 Cc: LLVM Dev; Clang Dev; LLDB Dev
 Subject: Re: [llvm-dev] GitHub anyone?
 
 
> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev >>> d...@lists.llvm.org> wrote:
> 
> Chris Lattner via llvm-dev wrote:
>> Personally, I’m hugely in favor of moving llvm’s source hosting to
 github at
>> some point, despite the fact that I continue to dislike git as a tool
 and
>> consider monotonicly increasing version numbers to be hugely
 beneficial.
> 
> For whatever it's worth, our projects define a `buildnum` git alias:
> 
> alias.buildnum=!sh -c "git rev-list --all | wc -l"
>>> 
>>> Or the cheaper "git rev-list --count --all" if your git is new enough.
>>> We do something like this as well.
>>> 
> 
> So from the shell:
> 
> $ git buildnum
> 17475
> 
> This number increases monotonically per commit.
 
 It does not work with branches though (we're not really planning to
>> have
 branches I believe),
>>> 
>>> You can get a per-branch unique number with this tactic.  On our local
>>> branches we use "rev-list origin/master.." which is the number of
>> commits
>>> since branching from master, and that's enough for our local purposes.
>>> 
 but more importantly it won't handle cross-repository
 versioning (how do you relate the number this command prints in the
>> llvm
 repo to the number it'll print in the clang repo?), which I believe is
 something important considering our setup.
>>> 
>>> Is it really that important?  Or are we just used to the convenience?
>> 
>> I don't know how important it is. How would you bisect without this
>> "convenience" for instance?
>> (There is nothing like "push date" in git)
> 
> I know that on a single branch, "git bisect" deals with that for you.

Sure, but our case is worse than branches: it is *cross repositories rev-locks".

> I've seen the talk about submodules but I have no clue how that works
> or whether git-bisect can operate cleanly in that situation.

Submodules is one solution, I gave some other pointers in this thread 
previously.

-- 
Mehdi


>> 
>> 
>> 
>>> If the Clang build number is a tuple (cfe-number, llvm-number) instead
>>> of a single number, how horrible is that really?  If you consider what
>>> an out-of-tree front end probably does, it's exactly the same thing.
>>> 
>>> (I admit that locally we mush cfe+llvm into a single branch and do the
>>> rev-list count to get a single number. But that's more for our own
>>> convenience than anything else.)
>>> --paulr
>>> 
 
 --
 Mehdi
 
 
 
> 
> 
> Our build scripts make this number available in various #define forms.
> 
> (We use a little extra scripting logic to also determine whether there
> are currently any unmerged or uncommitted changes, and add an
>> annotation
> to the program version in that case, e.g.  "9.3.17475 [unmerged]")
> 
> 
> It's all stupidly simple, but seems to work well enough for us.
> 
> 
> 
> Regards,
> 
> Bill
> 
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
 
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev 
>  wrote:
> 
> Chris Lattner via llvm-dev wrote:
>> Personally, I’m hugely in favor of moving llvm’s source hosting to github at
>> some point, despite the fact that I continue to dislike git as a tool and
>> consider monotonicly increasing version numbers to be hugely beneficial.
> 
> For whatever it's worth, our projects define a `buildnum` git alias:
> 
>  alias.buildnum=!sh -c "git rev-list --all | wc -l"
> 
> So from the shell:
> 
>  $ git buildnum
>  17475
> 
> This number increases monotonically per commit.

It does not work with branches though (we're not really planning to have 
branches I believe), but more importantly it won't handle cross-repository 
versioning (how do you relate the number this command prints in the llvm repo 
to the number it'll print in the clang repo?), which I believe is something 
important considering our setup.

-- 
Mehdi



> 
> 
> Our build scripts make this number available in various #define forms.
> 
> (We use a little extra scripting logic to also determine whether there
> are currently any unmerged or uncommitted changes, and add an annotation
> to the program version in that case, e.g.  "9.3.17475 [unmerged]")
> 
> 
> It's all stupidly simple, but seems to work well enough for us.
> 
> 
> 
> Regards,
> 
> Bill
> 
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 1:31 PM, Renato Golin  wrote:
> 
> On 31 May 2016 at 21:28, Mehdi Amini  wrote:
>> Ideally, I'd prefer the cross-repository to be handled with an extra layer, 
>> in a way similar as described in: 
>> https://gerrit-review.googlesource.com/Documentation/user-submodules.htm 
>> (somehow conceptually similar to Android manifests XML files).
>> It would be easy to have tooling/scripts for llvm that would easily say 
>> "checkout llvm+clang+compiler-rt+libcxx+clang-extra here", or "update all 
>> llvm subproject under this root", or "checkout this specific revision for 
>> all these" (with a monotonic number for the revision).
> 
> At Linaro, we already have a set of scripts that do that. We're now
> moving to git worktree, and I think it's going to simplify our work
> considerably. But honestly, I'd rather not force anyone to use any set
> of scripts, and let people work directly with git, so I'd be more in
> favour of having a server-side solution, if at all possible.

Apparently I wasn't very clear: llvm and clang (and the others projects) would 
be simple decoupled, individual git repositories. You would be able to check 
them out however you want and commit to them individually.
There would be an extra "integration repository" on top that would only provide 
the service that tells "r12345 is llvm:36c941c clang:eaf492b 
compiler-rt:6d77ea5". This repository should be managed transparently by some 
server-side integration.
The provided scripting I was referring to would just be a convenience that is 
using this extra layer of metadata ("integration repository") to be able 
checkout the other individual repositories together at the right "rev-lock" 
revision.
This is not on your way if you don't want to use it, but it provides this 
"single increase monotonic revision number across multiple repository" that is 
convenient for some people.

Makes sense?

-- 
Medhi

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 1:16 PM, Chris Lattner via llvm-dev 
>  wrote:
> 
>> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev 
>>  wrote:
>> There has been some discussion on IRC about SVN hosting and the perils
>> of doing it ourselves. The consensus on the current discussion was
>> that moving to a Git-only solution would have some disvantages, but
>> many advantages. Furthermore, not hosting our own repos would save us
>> a lot of headaches, admin costs and timed out connections.
> 
> Personally, I’m hugely in favor of moving llvm’s source hosting to github at 
> some point, despite the fact that I continue to dislike git as a tool and 
> consider monotonicly increasing version numbers to be hugely beneficial.

Getting a monotonically increasing revision number seems doable in git with 
some server-side scripting using git notes or named tags (yet to be seen is how 
to achieve it *reliably* with github hosting).
However the challenge is more about sharing this number across repositories 
(i.e. having clang and llvm in sync). I can imagine some tooling for that, but 
with a github hosting it may still be fragile.

Ideally, I'd prefer the cross-repository to be handled with an extra layer, in 
a way similar as described in: 
https://gerrit-review.googlesource.com/Documentation/user-submodules.htm 
(somehow conceptually similar to Android manifests XML files). 
It would be easy to have tooling/scripts for llvm that would easily say 
"checkout llvm+clang+compiler-rt+libcxx+clang-extra here", or "update all llvm 
subproject under this root", or "checkout this specific revision for all these" 
(with a monotonic number for the revision).

(+1 to all the rest of what you wrote)

-- 
Mehdi


> The killer feature to me is the community aspects of github, allowing people 
> to get involved in the project more easily and make “drive by” contributions 
> through the pull request model.  Github also has a very scriptable interface, 
> allowing integration of external bug trackers etc into the workflow (which is 
> good, because its bugtracker is anemic).
> 
>> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
>> etc. Not only this incurs in additional admin cost, but it also gets
>> outdated, locally modified, and it needs to be backed up, etc. GitHub
>> gives all that for us for free.
> 
> Yes, it would be great to get out of this business.
> 
>> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
>> we can also use GitHub's system to manage releases (it's actually
>> quite good for that).
> 
> If we made this change, I think we should only change one thing at a time: 
> change source hosting, but not phabricator or the bug tracker.  We could then 
> discuss moving off phabricator to the github PR model, etc.
> 
>> 6. GitHub has automated testing of merge requests, meaning we can have
>> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
>> own validation hooks.
> 
> This works pretty well.  The major problem is with tests that are flakey.
> 
> -Chris
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.8 Release] RC1 has been tagged

[Mehdi Amini via lldb-dev]

If the test-suite setup with CMake is broken, why not replace the CMake 
auto-detection of the test-suite with an error?
Something like:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index d96afc465177..918da6f6c945 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -693,11 +693,7 @@ endif()
 
 if( LLVM_INCLUDE_TESTS )
   if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite AND TARGET clang)
-include(LLVMExternalProjectUtils)
-llvm_ExternalProject_Add(test-suite 
${LLVM_MAIN_SRC_DIR}/projects/test-suite
-  USE_TOOLCHAIN
-  EXCLUDE_FROM_ALL
-  NO_INSTALL)
+message(FATAL_ERROR "The test-suite cannot be built in-tree with CMake at 
that time")
   endif()
   add_subdirectory(test)
   add_subdirectory(unittests)



— 
Mehdi


> On Jan 26, 2016, at 8:04 AM, James Molloy via cfe-dev 
>  wrote:
> 
> The test-suite shouldn't be being build with CMake for the release - the 
> CMake system is not yet ready. Have you accidentally checked out the 
> test-suite into /projects? if it's there it will auto-configure.
> 
> James
> 
> On Tue, 26 Jan 2016 at 16:01 Ismail Donmez via cfe-dev 
> > wrote:
> On Tue, Jan 26, 2016 at 1:56 PM, Nikola Smiljanic via llvm-dev
> > wrote:
> > Phase1 fails to build on openSUSE 13.2, can anyone see what's wrong from
> > this log file?
> 
> Something wrong with the test-suite:
> 
> make -f CMakeFiles/test-suite.dir/build.make CMakeFiles/test-suite.dir/depend
> make[2]: Entering directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/test-suite.dir/build.make:112: *** target pattern contains
> no '%'.  Stop.
> make[2]: Leaving directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/Makefile2:198: recipe for target
> 'CMakeFiles/test-suite.dir/all' failed
> make[1]: *** [CMakeFiles/test-suite.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev 
> 
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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