Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged

[Diana Picus via lldb-dev]

Uploaded AArch64 binaries:
2c3bd3d686c3712ba5699e9a638bc849ddb0aae3
clang+llvm-8.0.0-rc1-aarch64-linux-gnu.tar.xz

Had one failure in check-all (memory sanitizer). I opened PR40511 for it [1].

I ran into some snags with ARM, I'm still figuring out if there's
something wrong with our infrastructure. Sorry about the delay!

Cheers,
Diana

[1] https://bugs.llvm.org/show_bug.cgi?id=40511

On Tue, 29 Jan 2019 at 00:23, Bero Rosenkränzer via Release-testers
 wrote:
>
> Hi,
> working without immediately obvious regressions on OpenMandriva x86-64, x86, 
> aarch64 and armv7hnl.
> Since our 4.0 release is imminent, 8.0 won't go in there, but it will be our 
> main compiler the day after the release and been cut.
>
> Would be nice to get the admin goto patches in to enable building the Linux 
> kernel, but unfortunately that may be too big a change after RC?
>
> ttyl
> bero
>
> On Thu, Jan 24, 2019, 3:50 AM Hans Wennborg via Release-testers 
> >
>> Dear testers,
>>
>> 8.0.0-rc1 was just tagged (from the branch at r351980).
>>
>> It took a little longer than planned, but it's looking good.
>>
>> Please run the test script, share your results, and upload binaries.
>>
>> I'll get the source tarballs and docs published as soon as possible,
>> and binaries as they become available.
>>
>> Thanks,
>> Hans
>> ___
>> Release-testers mailing list
>> release-test...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged

[Hans Wennborg via lldb-dev]

On Mon, Jan 28, 2019 at 6:23 PM Bero Rosenkränzer
 wrote:
>
> Hi,
> working without immediately obvious regressions on OpenMandriva x86-64, x86, 
> aarch64 and armv7hnl.
> Since our 4.0 release is imminent, 8.0 won't go in there, but it will be our 
> main compiler the day after the release and been cut.
>
> Would be nice to get the admin goto patches in to enable building the Linux 
> kernel, but unfortunately that may be too big a change after RC?

I'm definitely still open to considering those for llvm 8. I think it
depends on what they look like in the end, and when they land. But
they'll have to land on trunk first :-)

Thanks,
Hans

> On Thu, Jan 24, 2019, 3:50 AM Hans Wennborg via Release-testers 
> >
>> Dear testers,
>>
>> 8.0.0-rc1 was just tagged (from the branch at r351980).
>>
>> It took a little longer than planned, but it's looking good.
>>
>> Please run the test script, share your results, and upload binaries.
>>
>> I'll get the source tarballs and docs published as soon as possible,
>> and binaries as they become available.
>>
>> Thanks,
>> Hans
>> ___
>> Release-testers mailing list
>> release-test...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [monorepo] Much improved downstream zipping tool available

[David Greene via lldb-dev]

He all,

I've updated the downstream fork zipping tool that I posted about last
November [1].  It is much improved in every way.  The most important
enhancements are:

- Does a better job of simplifying history

- Handles nested submodules

- Will put non-submodule-update content in a subdirectory of the
  monorepo

- Updates tags

In addition there are plenty of the requisite bug fixes.  The latest
version of the tool can be found here:

https://github.com/greened/llvm-git-migration/tree/zip

With the nested submodules and the subdirectory features, the tool can
now take a downstream llvm repository with submodules (e.g. clang in
tools/clang and so on) as an umbrella and order the commits according to
changes in llvm and its submodules.

Björn, this new version may well be able to handle the tasks you
outlined in December [2].

I've written some recipes as proposed additions to the GitHub migration
proposal [3].  If you have a different scenario, please comment there
and if it seems a like a common case I can add a recipe for it so we can
all benefit from the learning.

Much of the bugfixing work was the result of some artificial histories I
created to shake out problems.  I believe it is ready for some testing
in the wild.  If you do try it, please let me know how it worked for you
and any problems you run into.  I will try to fix them.  It's easiest if
you can provide me with a test repository showing the problem but even a
verbal description of what is happening can help.

I hope this tool is helpful to the community.

 -David

[1] http://lists.llvm.org/pipermail/llvm-dev/2018-November/127704.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2018-December/128620.html
[3] https://reviews.llvm.org/D56550
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [monorepo] Much improved downstream zipping tool available

[David Greene via lldb-dev]

Björn Pettersson A  writes:

> In the new monorepo UC1 may or may not be a parent to UL1.
> We could actually have something like this:
>
>   UL4->UC2->UL3->UL2->UL1->UL0->UC1
>
> Our DL1 commit should preferably have UL1 as parent after
> conversion
>
>   UL4->UC2->UL3->UL2->UL1->UL0->UC1
>|
>  ...->DL1
>
> but since it also includes DC1 (via submodule reference) we
> want to zip in DC1 before DL1, right? 
>
>   UL4->UC2->UL3->UL2->UL1->UL0->UC1
>|
> ...->DC1->DL1
>
> The problem is that DC1 is based on UC1, so we would get something
> like this
>
>   UL4->UC2->UL3->UL2->UL1->UL0->UC1
>| |
> ...->DC1->DL1|
>   ^  |
>   |  |
>--
>
> Which is not correct, since then we also get the UL0 commit
> as predecessor to DL1.

To be clear, is DC1 a commit that updates the clang submodule to UC1 and
DL1 a separate local commit to llvm that merges in UL1?

When zip-downstream-fork.py runs, it *always* uses the exact trees in
use by each downstream commit, whether from submodules or the umbrella
itself.  It tries very hard to maintain the state of the trees as they
appeared in the umbrella repository.

Since in your case llvm isn't a submodule (it's the "umbrella"), DL1
will absolutely have the tree from UL1, not UL0.  This is how
migrate-downstream-fork.py works and zip-downstream-fork.py won't touch
the llvm tree since it's not a submodule.  The commit DL1 doesn't update
any submodules so it will just use the clang tree from DC1.

I haven't tested this case explicitly but I would expect the resulting
history graph to look as you diagrammed above (reformatted to make it
clear there isn't a cycle):

   UL4->UC2->UL3->UL2->UL1->UL0->UC1 <- monorepo/master
| |
\ |
 `---.
  |   \
   ... ->DC1->DL1 <- zip/master

The "redundant" edge here is indicating that the state of the llvm tree
at DL1 is based on UL1, not UL0.  All other projects will be in the
state at UC1 (assuming you don't have other submodules under llvm).  I
know it looks strange but this is the best I could come up with because
in general there is no guarantee that submodule updates were in any way
correlated with when upstream commits were made (as you discovered!).
There's some discussion of this issue on the documentation I posted [1],
as well as in header comments in zip-downstream-fork.py.

The difficulty with this is that going forward, if you merge from
monorepo/master git will think you already have the changes from UL0.
There are at least two ways to work around this issue.  The first is to
just manually apply the llvm diff from UL1 to UL0 on top of zip/master
and then merge from monorepo/master after that.  The other way is to
freeze your local split repositories and merge from the upstream split
masters for all subprojects before running migrate-downstream-fork.py
and zip-downstream-fork.py.  Then everything will have the most
up-to-date trees and you should be fine going forward.  Doing such a
merge isn't possible for everyone at the time they want to migrate, but
the manual diff/patch method should suffice for those situations.  You
just have to somehow remember to do it before the next merge from
upstream.  Creating an auxilliary branch with the patch applied is one
way to remember.

I haven't really thought of a better way to handle situations like this
so I'm open to ideas!

   -David

[1] https://reviews.llvm.org/D56550
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Object identities in the LLDB's C++ API

[Leonard Mosescu via lldb-dev]

Reviving this old thread and +Joshua Peraza   who's
also interested in this.

On Wed, Dec 13, 2017 at 4:17 PM Leonard Mosescu  wrote:

> Thanks Greg,
>
> 1. Expose the opaque ptr as an opaque handle()
>  - this is an easy, quick and convenient solution for many SBxxx types
> but it may not work for all
>
> That would be nice, but that won't always work with how LLDB is currently
>> coded for SBFrame and possibly SBThread. These objects will be problems as
>> they can come and go and the underlying object isn't always the same even
>> through they lock onto the same logical object. SBThread and SBFrame have
>> "lldb::ExecutionContextRefSP m_opaque_sp" members. The execution context
>> reference is a class that contains weak pointers to the
>> lldb_private::Thread and lldb_private::StackFrame objects, but it also
>> contains the thread ID and frame ID so it can reconstitute the
>> value lldb_private::Thread and lldb_private::StackFrame even if the weak
>> pointer isn't valid. So the opaque handle will work for many objects but
>> not all.
>
>
> Indeed. One, relatively small but interesting benefit of the opaque handle
> type is that it opens the possibility of generic "handle maps" (I'll
> elaborate below)
>
> 2. Design and implement a consistent, first class
> identity/ordering/hashing for all the SBxxx types
>  - perhaps the most elegant and flexible approach, but also the most
> work
>
> I would be fine with adding new members to classes we know we want to hash
>> and order, like by adding:
>> uint32_t SB*::GetHash();
>> bool SB*::operator==(const SB*& ohs);
>> bool SB*::operator<(const SB*& ohs);
>> Would those be enough?
>
>
> I think so. If we use the standard containers as reference, technically we
> only need operator< to satisfy the Compare
>  concept. (also, a
> small nit - size_t would be a better type for the hash value). Also, both
> the hashing and the compare can be implemented as non-member functions (or
> even specializing std::hash, std::less for SBxxx types). A few minor
> concerns:
>
> a. if we keep things like SBModule::operator==() unchanged, it's not going
> to be the same as the equiv(a, b) for the case where a and b have null
> opaque pointers (not sure if this breaks anything, but I wouldn't want to
> be the first to debug a case where this matter)
> b. defining just the minimum set of operations may be technically enough
> but it may look a bit weird to have a type define < but none of the other
> relational operators.
> c. if some of the hash/compare implementation end up going through
> multiple layers (the execution context with thread, frame IDs example) the
> performance characteristics can be unpredictable, right?
>
>
> For context, the use case that brought this to my attention is managing a
> set of data structures that contain custom data associated with modules,
> frames, etc. It's easy to create, let's say a MyModule from a SBModule, but
> if later on I get the module for a particular frame, SBFrame::GetModule()
> will return a SBModule, which I would like to map to the corresponding
> MyModule instance. Logically this would require a SBModule -> MyModule map.
> The standard associative containers (map or unordered_map) would make this
> trivial if SBxxx types satisfy the key requirements.
>
> Another option for maintaining such a mapping, suggested by Mark Mentovai,
> is to use provision for an "user data" tag associated with every SBxxx
> object (this tag can simply be a void*, maybe wrapped with type safe
> accessors). This would be extremely convenient for the API users (since
> they don't have to worry about maintaining any maps themselves) but
> implementing it would hit the same complications around the synthesized
> instances (like SBFrame) and it may carry a small price - one pointer per
> SBxxx instance even if this facility is not used. I personally like this
> approach and in this particular case it has the additional benefit of being
> additive (we can graft it on with minimal risk of breaking existing stuff),
> although it still seems nice to have consistent identity semantics for the
> SBxxx types.
>
> On Wed, Dec 13, 2017 at 12:40 PM, Greg Clayton  wrote:
>
>>
>> On Dec 13, 2017, at 11:44 AM, Leonard Mosescu via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> LLDB's C++ API deals with SBxxx objects, most of which are PIMPL-style
>> wrappers around an opaque pointer to the internal implementation. These
>> SBxxx objects act as handles and are passed/returned by value, which is
>> generally convenient, except for the situations where one would need to
>> keep track of object identities, ex. using them as keys in associative
>> containers.
>>
>> As far as I can tell, there's a bit of inconsistency in the current state:
>>
>> 1. Some types, ex. SBThread, SBTarget, SBSection, ... offer ==, != that
>> map directly to the corresponding operator on the opaque pointer (good!),
>> but:
>> .. there ar

[lldb-dev] [Github] RFC: linear history vs merge commits

[Tom Stellard via lldb-dev]

Hi,

As part of the migration of LLVM's source code to github, we need to update
our developer policy with instructions about how to interact with the new git
repository.  There are a lot of different topics we will need to discuss, but
I would like to start by initiating a discussion about our merge commit
policy.  Should we:

1. Disallow merge commits and enforce a linear history by requiring a
   rebase before push.

2. Allow merge commits.

3. Require merge commits and disallow rebase before push.

I'm going to propose that if we cannot reach a consensus that we
adopt policy #1, because this is essentially what we have now
with SVN.

What does everyone think?

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

Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

[Adrian Prantl via lldb-dev]

A linear history makes it much easier to git-bisect, since each commit can be 
rolled back individually. Easier cross-project bisection is one of the 
advantages of having the monorepo, and I wouldn't want to loose that.

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

Re: [lldb-dev] [Openmp-dev] [Github] RFC: linear history vs merge commits

[David Greene via lldb-dev]

Tom Stellard via Openmp-dev  writes:

> As part of the migration of LLVM's source code to github, we need to update
> our developer policy with instructions about how to interact with the new git
> repository.  There are a lot of different topics we will need to discuss, but
> I would like to start by initiating a discussion about our merge commit
> policy.  Should we:
>
> 1. Disallow merge commits and enforce a linear history by requiring a
>rebase before push.
>
> 2. Allow merge commits.
>
> 3. Require merge commits and disallow rebase before push.
>
> I'm going to propose that if we cannot reach a consensus that we
> adopt policy #1, because this is essentially what we have now
> with SVN.

I agree with proposing #1 in general.  It results in a nice clean
history and will be familiar to everyone working on the project.

However, there is a place for merge commits.  If there's a bug in a
release and we want to make a point release, it might make sense to make
a commit on the release branch and then merge the release branch to
master in order to ensure the fix lands there as well.  Another option
is to commit to master first and then cherry-pick to release.  A third
option is to use the "hotfix branch" method of git flow [1], which would
result in a merge commit to the release branch and another merge commit
to master.

I've seen projects that commit to release first and then merge release
to master and also projects that commit to master and cherry-pick to
release.  I personally haven't seen projects employ the git flow hotfix
branch method rigorously.

But GitHub is read-only for almost a year, right?  So we really don't
have to decide this for a while.  I have not tried using the monorepo
and committing to SVN with it.  How does that work?  What would it do
with merge commits?

  -David

[1] https://nvie.com/posts/a-successful-git-branching-model
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

[Jeremy Lakeman via lldb-dev]

[Armchair observer...]

If any merges are allowed, they should be rare, have recent parent commits,
or the history graph becomes useless.

4. Each reviewed bug / feature must be rebased onto the current "known
good" commit, merged into a "probably good" commit, tested by build bots,
and only then pushed to trunk. Keeping trunk's history more usable, with
most bad patches reworked and resubmitted instead of reverted.

5. When a new feature is broken up into a patch series, the series should
be rebased then immediately merged to help identify the individual patches
in the history graph.


On Wed, 30 Jan 2019 at 09:04, Tom Stellard via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hi,
>
> As part of the migration of LLVM's source code to github, we need to update
> our developer policy with instructions about how to interact with the new
> git
> repository.  There are a lot of different topics we will need to discuss,
> but
> I would like to start by initiating a discussion about our merge commit
> policy.  Should we:
>
> 1. Disallow merge commits and enforce a linear history by requiring a
>rebase before push.
>
> 2. Allow merge commits.
>
> 3. Require merge commits and disallow rebase before push.
>
> I'm going to propose that if we cannot reach a consensus that we
> adopt policy #1, because this is essentially what we have now
> with SVN.
>
> What does everyone think?
>
> Thanks,
> Tom
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged

[Brian Cain via lldb-dev]

SLES and Ubuntu 14.04 tarballs uploaded.   Sorry for the delay.  I will try
and find time to make a build for bionic / 18.04 too.

99ec00702e39b096ace4fbce3d787b9e485b879e
clang+llvm-8.0.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz

dbf204f70cb09ec459e5eb4fc14e8fa71292daa7
clang+llvm-8.0.0-rc1-x86_64-linux-sles11.3.tar.xz


On Wed, Jan 23, 2019 at 6:50 PM Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear testers,
>
> 8.0.0-rc1 was just tagged (from the branch at r351980).
>
> It took a little longer than planned, but it's looking good.
>
> Please run the test script, share your results, and upload binaries.
>
> I'll get the source tarballs and docs published as soon as possible,
> and binaries as they become available.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>


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