[lldb-dev] [Bug 39330] New: 7.0.1 backport: Assertion failed: (!m_first_die || m_first_die == m_die_array.front())…

2018-10-16 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=39330

Bug ID: 39330
   Summary: 7.0.1 backport: Assertion failed: (!m_first_die ||
m_first_die == m_die_array.front())…
   Product: lldb
   Version: 7.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: jan.kratoch...@redhat.com
CC: llvm-b...@lists.llvm.org

Please backport:
  Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front())…
  https://reviews.llvm.org/rL344605

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM Relicensing Update

2018-10-16 Thread Chandler Carruth via lldb-dev 
Greetings,

I wanted to provide an update to all the LLVM project (including all of its
sub-projects) developers about the ongoing effort to relicense under LLVM
under a new, unified license.

TL;DR: It’s actually happening. If you are a contributor to LLVM, help us
out by filling out our form and signing an agreement to cover any
individual contributions you have made:
https://goo.gl/forms/X4HiyYRcRHOnTSvC3

All of this information and the latest status can always be found on the
relicensing website here:
http://llvm.org/foundation/relicensing/


## Background and Process

For background, here is the new license:
http://llvm.org/foundation/relicensing/LICENSE.txt
The motivation, scope, and discussion of the license itself, please see the
most recent thread from Chris on the subject:
http://lists.llvm.org/pipermail/llvm-dev/2017-April/112142.html
Also, we have the proposed new developer policy discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html

Based on these discussions, there seems clear consensus to move forward,
and we (the Foundation) have been working on this for the past year. I want
to update folks on the progress and the next steps in the more boring
logistics side of this: how do we actually switch.

Our plan, roughly outlined when discussing the developer’s policy last
year, is to install the new license and the developer policy that
references both the new and old license. At that point, all subsequent
contributions will be under both licenses. To ensure contributors are
aware, we have a two-fold plan:

1) We’re going to get as many active contributors (both companies and
individuals) to explicitly sign an agreement to relicense their
contributions. This will make the change clear and will cover historical
contributions as well.
2) For any remaining contributors, turn off their commit access until we
can confirm they are covered by one of the above agreements.

We plan to have the *vast majority* of contributors handled via #1 ahead of
time, so this will not be disruptive. If necessary, we can delay this to
ensure that #1 covers enough of the active contributors. We do not want to
unnecessarily disrupt contributions, but we also want to move this forward
as fast as we can. For contributors who cannot, for whatever reason,
complete the outlined process (#2 above), please send email to
license-questi...@llvm.org and we'll work, in conjunction with our legal
counsel, to find a path forward.

Our current planned timeline is to install the new developer policy and the
new license after the LLVM 8.0 release branch in January. We will then be
focused on getting all of the historical contributions under an agreement
to relicense so we can remove the old license(s).


## Relicensing Agreements

For #1 to work, we need both individuals and companies to sign an agreement
to relicense. The Foundation has worked with our lawyer and built a process
for both companies and individuals.

For individuals, we’re asking everyone to fill out a form so we have the
necessary information (email addresses, potential employers, etc.) to
effectively relicense their contributions. It contains a link to a DocuSign
agreement to relicense any of their individual contributions under the new
license. We’re really hoping that most people will just sign this agreement
as it avoids us needing to prove whether every contribution is definitively
covered by some company. You can fill out the form and sign the agreement
here:
https://goo.gl/forms/X4HiyYRcRHOnTSvC3

For companies, we also have a DocuSign agreement:
https://na3.docusign.net/Member/PowerFormSigning.aspx?PowerFormId=5a2bb38c-41c4-4ce0-a26e-52a7eb8ae51c
We have already reached out to many major companies already, and a few have
already signed this agreement. We will be collecting more companies from
the form responses and reaching out to them. Feel free to reach out to your
employer with the DocuSign link above, but please check the list of
companies  we’ve
already contacted and try to coordinate internally to avoid duplicate work.

Once we get the new policy and license in place, we’ll be iterating with
these tools until we have everything relicensed, or we have a concrete plan
about what to do with any remaining material.


## New File Headers

With the new license and developer policy, we also need to update the file
headers. The Foundation worked with our lawyer to get a new header approved
that is both minimal and functional:
```
//===-- file/name - File description *- C++
-*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===--===//
```

Some notable aspects:
- No explicit copyright notice. After discussion with our law

Re: [lldb-dev] [libcxx-dev] LLVM Relicensing Update

2018-10-16 Thread Pavan Maddamsetti via lldb-dev 
Dear LLVM community,

Please do not agree to relicense LLVM under the Apache 2 license. It will
make LLVM less useful, prevent other open source projects from using it,
and encourage the proliferation of software patents on LLVM technologies.

If LLVM is relicensed, projects like OpenBSD will no longer be able to
include upstream changes, because the patent termination clause restricts
users’ rights. Even if you do not use OpenBSD, you almost certainly use
OpenSSH, OpenBSD’s SSH implementation. If the project loses the ability to
include a recent compiler, many people will suffer the consequences.

Relicensing will also encourage privately held software patents on LLVM.
Under US [1] and European [2] law, public disclosure of intellectual
property invalidates patentability. That means if you release source code
without filing patents, the code becomes unpatentable by anyone. When code
is committed under the current license, everyone gains a permanent right to
use it.

For the patent termination clause of the Apache 2 license to be valid,
patents must be filed preemptively. Other contributors who have not filed
their own patents are then placed at a legal disadvantage. This creates an
“arms race” where everyone has to patent their unique contributions,
creating the threat of retaliation to avoid potentially getting sued for
infringement.

Even if you acknowledge that the current license is not perfect,
relicensing LLVM will violate the spirit of good will and cooperation that
makes open source possible. It will take away the ability for other
projects to use LLVM, and increase the legal risks for those who choose not
to patent their contributions. If you are a programmer, not a lawyer,
relicensing LLVM is not in your interest.

Thanks,
Pavan

[1]
http://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title35-section102&num=0&edition=prelim

[2] https://www.epo.org/law-practice/legal-texts/html/epc/2016/e/ar54.html

On Tue, Oct 16, 2018, 7:37 PM Chandler Carruth via libcxx-dev <
libcxx-...@lists.llvm.org> wrote:

> Greetings,
>
> I wanted to provide an update to all the LLVM project (including all of
> its sub-projects) developers about the ongoing effort to relicense under
> LLVM under a new, unified license.
>
> TL;DR: It’s actually happening. If you are a contributor to LLVM, help us
> out by filling out our form and signing an agreement to cover any
> individual contributions you have made:
> https://goo.gl/forms/X4HiyYRcRHOnTSvC3
>
> All of this information and the latest status can always be found on the
> relicensing website here:
> http://llvm.org/foundation/relicensing/
>
>
> ## Background and Process
>
> For background, here is the new license:
> http://llvm.org/foundation/relicensing/LICENSE.txt
> The motivation, scope, and discussion of the license itself, please see
> the most recent thread from Chris on the subject:
> http://lists.llvm.org/pipermail/llvm-dev/2017-April/112142.html
> Also, we have the proposed new developer policy discussed here:
> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html
>
> Based on these discussions, there seems clear consensus to move forward,
> and we (the Foundation) have been working on this for the past year. I want
> to update folks on the progress and the next steps in the more boring
> logistics side of this: how do we actually switch.
>
> Our plan, roughly outlined when discussing the developer’s policy last
> year, is to install the new license and the developer policy that
> references both the new and old license. At that point, all subsequent
> contributions will be under both licenses. To ensure contributors are
> aware, we have a two-fold plan:
>
> 1) We’re going to get as many active contributors (both companies and
> individuals) to explicitly sign an agreement to relicense their
> contributions. This will make the change clear and will cover historical
> contributions as well.
> 2) For any remaining contributors, turn off their commit access until we
> can confirm they are covered by one of the above agreements.
>
> We plan to have the *vast majority* of contributors handled via #1 ahead
> of time, so this will not be disruptive. If necessary, we can delay this to
> ensure that #1 covers enough of the active contributors. We do not want to
> unnecessarily disrupt contributions, but we also want to move this forward
> as fast as we can. For contributors who cannot, for whatever reason,
> complete the outlined process (#2 above), please send email to
> license-questi...@llvm.org and we'll work, in conjunction with our legal
> counsel, to find a path forward.
>
> Our current planned timeline is to install the new developer policy and
> the new license after the LLVM 8.0 release branch in January. We will then
> be focused on getting all of the historical contributions under an
> agreement to relicense so we can remove the old license(s).
>
>
> ## Relicensing Agreements
>
> For #1 to work, we need both individuals and companies to sig

Re: [lldb-dev] [libcxx-dev] LLVM Relicensing Update

2018-10-16 Thread Chandler Carruth via lldb-dev 
On Tue, Oct 16, 2018 at 4:51 PM Pavan Maddamsetti <
pavan.maddamse...@gmail.com> wrote:

> Dear LLVM community,
>
> Please do not agree to relicense LLVM under the Apache 2 license.
>
This has already been discussed extensively. Please see the posts I cited.
I don't really want to re-discuss this, there was clear consensus in the
previous threads.

I acknowledge that some still have concerns, but I don't think
re-discussing it here is going to be constructive. If there is new
information, then a new discussion (not this thread) should be started.
However, the content of your email brings up points that have been
discussed already.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [LLDB]{Proposal} Adding new typesystem to support language like PLI/COBOL to lldb

2018-10-16 Thread Chirag Patel via lldb-dev 
Ping.




Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET

Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com


From: paul.robin...@sony.com 
Sent: 11 October 2018 00:02:06
To: Chirag Patel
Cc: lldb-dev@lists.llvm.org; john.rea...@vmssoftware.com
Subject: RE: [LLDB]{Proposal} Adding new typesystem to support language like 
PLI/COBOL to lldb


John Reagan at VMS Software has made noises about adopting LLDB, in which case 
it would need to support PLI and COBOL types.  Looping him in directly.

--paulr



From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Chirag 
Patel via lldb-dev
Sent: Tuesday, October 09, 2018 6:56 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] [LLDB]{Proposal} Adding new typesystem to support language 
like PLI/COBOL to lldb



Hello all,



I am looking into adding the new typesystem support for languages like 
PLI/COBOL.

Is anybody actively working/looking on this?



Regards,



Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET

Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com


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