[lldb-dev] Infinity full-system preview

[Gary Benson via lldb-dev]

Hi all,

I've been working on a platform-independent system for executables and
shared libraries to expose functionality to debug, monitoring, and
analysis tooling.  It's called Infinity.  I'm writing it to solve some
problems GDB has, but these are likely problems LLDB has too so I'd
like to make what I write suitable for you to use too.

The initial use case is to allow GDB to debug multithreaded inferiors
without libthread_db, a requirement which causes problems with
debugging inferiors in containers and makes it difficult to debug core
files from one platform with a debugger on another (e.g. debugging an
aarch64 core on your x86_64 workstation).  If Infinity proves
acceptable to the glibc community then it's likely this stuff will be
added to glibc to allow debuggers to support dlmopen too, and I'm
hoping the OpenMP community will get on board too (they are currently
proposing another libthread_db-style interface).

Rather than requiring a plugin library that the debugger loads, in
Infinity debug functions are shipped as DWARF bytecode in the actual
library they are for, so, e.g., the notes implementing what
libthread_db.so currently implements live in libpthread.so.  The idea
is that the debugger keeps a track of the notes it finds in the
executables and libraries it loads, and when complete sets arrive it
enables that particular subsystem.  So, when the notes needed to
support multithreaded inferiors appear then thread debugging switches
on.  This works regardless of whether the notes came from a library
(libpthread.so) or from the main executable (-static -pthread).

What exists so far?

 * Enough notes for GDB to attach to a process (or load a core file)
   and do "info threads".
 * An LGPLv2.1 client library to process and execute those notes.

The final plan is for GDB to directly call the client library
functions, but to allow people to see how this all works I've put
together a shim libthread_db.so that loads notes from the inferior
and uses the client library to execute them.  If you'd like to try
this out there are instructions here:

  https://infinitynotes.org/wiki/First_Flight

The code in the libthread_db shim is something like what would need
adding to LLDB, minus the ELF parsing which LLDB presumably already
handles.  For gdbserver there will be some remote protocol changes;
gdbserver does not parse ELF, so GDB will have to extract the notes
and pass them over the wire somehow.  I don't know if lldbserver
handles ELF parsing or not, but if it doesn't I'd like to collaborate
to make sure that the gdbserver remote protocol changes are suitable
for lldbserver too so we're talking the same language.

Infinity's mailing list is infin...@sourceware.org, so please
subscribe if you're interested (by sending an empty message to
infinity-subsribe@).

Thanks,
Gary

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

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Rafael Espíndola via lldb-dev]

> The 4.1 release gives us the opportunity to drop support for 3.x
> bitcode formats, so  I don't think we should move to 4.x until we have
> older bitcode features that we really want to drop.  There should
> probably be a separate discussion thread about this.

It give the opportunity, not the obligation. Given that I think it is
an independent issue and would suggest we just keep the revisions
simple and switch trunk to 4.0.

Cheers,
Rafael
___
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.9 Release] Release plan and call for testers

[David Chisnall via lldb-dev]

On 13 Jun 2016, at 14:14, Rafael Espíndola via cfe-dev  
wrote:
> 
>> The 4.1 release gives us the opportunity to drop support for 3.x
>> bitcode formats, so  I don't think we should move to 4.x until we have
>> older bitcode features that we really want to drop.  There should
>> probably be a separate discussion thread about this.
> 
> It give the opportunity, not the obligation. Given that I think it is
> an independent issue and would suggest we just keep the revisions
> simple and switch trunk to 4.0.

I don’t think that this makes it simple for anyone.  Existing packaging tools 
understand dot notation and know that 3.10 > 3.9, even if interpreting the dot 
as a decimal point would mean that it didn’t.  Without this kind of special 
handling, they’d be very confused by 3.4.1, which isn’t even a valid number.

LLVM minor revisions break ABI and API compatibility and bugfix revisions 
don’t.  There is an expectation that major revisions will break the bitcode 
format, so releasing a 4.0 version but saying ‘this one doesn’t actually break 
it’ will be confusing.  Particularly if we then release a 5.0 that does, after 
a 4.5 that doesn’t.

That said, in general I’d prefer if we used semantic versioning and stopped 
releasing major versions with a bump of the minor version number.

David

___
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] [3.9 Release] Release plan and call for testers

[Renato Golin via lldb-dev]

On 12 June 2016 at 13:27, Dimitry Andric via llvm-dev
 wrote:
>> 1) Right after the branch, the version number of the trunk will be
>> incremented. I assume this means bumping the major version number,
>> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.
>
> 4.0.  Since gcc is already at 7.0, we need to catch up! ;-)

Or, we can do like ARM and go from 3 straight to 7! :)


>> 2) Following up on the May thread about the release process [1], I'd
>> like to make the schedule we've followed for the last few years more
>> official by posting somewhere on the web page that we're committed to
>> shipping two major releases per year: one in early March (branching
>> mid-January), and one early September (branching mid-July), usually
>> with one (or sometimes two) "dot" releases in between.
>
> Having predictable release schedules is nice.  If everybody knows the
> tree should be in fairly good shape at the point of branching, any heavy
> refactoring can be postponed until after such branching (or preferably,
> until after the actual release).

Yup, +1 for a webpage with all this, in addition to the existing
snippet on the homepage.


>> 3) Another follow-up from that thread: it's usually the same people
>> who test the releases for their platform. Rather than asking everyone
>> each time, I'd like to make a list of who's responsible for each
>> platform and put that on the web page. Testers can still sign-up or
>> resign as they like, of course. Would you testers be OK with this?
>
> You can put me up for the FreeBSD platform, obviously.

And me for ARM and AArch64.

cheers,
--renato
___
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.9 Release] Release plan and call for testers

[Renato Golin via lldb-dev]

On 13 June 2016 at 14:23, David Chisnall via lldb-dev
 wrote:
> I don’t think that this makes it simple for anyone.  Existing packaging tools 
> understand dot notation and know that 3.10 > 3.9, even if interpreting the 
> dot as a decimal point would mean that it didn’t.  Without this kind of 
> special handling, they’d be very confused by 3.4.1, which isn’t even a valid 
> number.

Hi David,

This is indeed at odds with the rest of the open source community, but
it's what we've been doing for a long time... I don't particularly
like it myself, but I don't think it's evil.


> LLVM minor revisions break ABI and API compatibility and bugfix revisions 
> don’t.  There is an expectation that major revisions will break the bitcode 
> format, so releasing a 4.0 version but saying ‘this one doesn’t actually 
> break it’ will be confusing.  Particularly if we then release a 5.0 that 
> does, after a 4.5 that doesn’t.

Well, the idea here is that in "3.9.0", "3.9" is the major "number"
and ".0" is the minor. I'm not saying it's a good scheme (because
tools already understand the other one), but in essence, we *do* break
all stuff between "majors", which means as much from 3.7 to 3.8 as it
does from 3.9 to 4.0.


> That said, in general I’d prefer if we used semantic versioning and stopped 
> releasing major versions with a bump of the minor version number.

I weekly support this, as it is my preferred scheme, and all OSS tools
already understand those *very* well indeed. But I wouldn't want to
enforce it for this July. :)

Maybe we can think of 4.0 as the last of the "weird major release",
and plan well in advance to move to 5.0 when we're ready, not when the
clock ticked. But that could bring a whole lot of other things like
holding off features during code freeze, have multiple branches in Git
for experimental features, etc. which I'd *also* welcome, but all in
good time. Let's move to Git-only first.

cheers,
--renato
___
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.9 Release] Release plan and call for testers

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Tom
> Stellard via cfe-dev
> Sent: Monday, June 13, 2016 7:12 AM
> To: Rafael Espíndola
> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
> LLDB Dev; cfe-dev
> Subject: Re: [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for
> testers
> 
> On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
> > > The 4.1 release gives us the opportunity to drop support for 3.x
> > > bitcode formats, so  I don't think we should move to 4.x until we have
> > > older bitcode features that we really want to drop.  There should
> > > probably be a separate discussion thread about this.
> >
> > It give the opportunity, not the obligation. Given that I think it is
> > an independent issue and would suggest we just keep the revisions
> > simple and switch trunk to 4.0.
> >
> 
> Hi Rafael,
> 
> The main issue I see with automatically moving to 4.0, is that if a year
> from now we decide we want to drop a bitcode feature, we can't really do
> it unless we bump the major version again to 5.0.  If we continue on
> with 3.x, then we still have the flexibility to drop bitcode features
> when we decide it's necessary.
> 
> -Tom

+1.  My understanding is that 2.9->3.0 came with some huge internal changes
(overhaul of the type system, maybe? this slightly predates my involvement
with LLVM so I'm not entirely sure) and warranted a major-version change
regardless of the .9->.0 thing.

I don't think 3.10 should be confusing to anyone, really.  The version
number is a tuple, not a string or a decimal fraction.
--paulr

> 
> > Cheers,
> > Rafael
> ___
> 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] [cfe-dev] [3.9 Release] Release plan and call for testers

[David Chisnall via lldb-dev]

On 13 Jun 2016, at 15:24, Robinson, Paul via llvm-dev  
wrote:
> 
> +1.  My understanding is that 2.9->3.0 came with some huge internal changes
> (overhaul of the type system, maybe? this slightly predates my involvement
> with LLVM so I'm not entirely sure) and warranted a major-version change
> regardless of the .9->.0 thing.

1->2 also came with a fairly fundamental change (removal of signed and unsigned 
integer types, addition of signed and unsigned integer operations).

> I don't think 3.10 should be confusing to anyone, really.  The version
> number is a tuple, not a string or a decimal fraction.

Agreed.

David

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

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Rafael Espíndola via lldb-dev]

On 13 June 2016 at 10:11, Tom Stellard  wrote:
> On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
>> > The 4.1 release gives us the opportunity to drop support for 3.x
>> > bitcode formats, so  I don't think we should move to 4.x until we have
>> > older bitcode features that we really want to drop.  There should
>> > probably be a separate discussion thread about this.
>>
>> It give the opportunity, not the obligation. Given that I think it is
>> an independent issue and would suggest we just keep the revisions
>> simple and switch trunk to 4.0.
>>
>
> Hi Rafael,
>
> The main issue I see with automatically moving to 4.0, is that if a year
> from now we decide we want to drop a bitcode feature, we can't really do
> it unless we bump the major version again to 5.0.  If we continue on
> with 3.x, then we still have the flexibility to drop bitcode features
> when we decide it's necessary.

OK, I guess that is where your reading of the version differ.

I read that we promise that 4.0 will read all of 3.X, but make no
further promises. That means that in 4.1 we *can* drop support for all
3.x, keep support for everything or something in the middle. But that
is also true for 4.2. So for example it would be valid that

* 4.0 reads all of 3.x
* 4.1 reads >= 3.1
* 4.2 reads >= 3.3

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

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
> Rafael Espíndola via llvm-dev
> Sent: Monday, June 13, 2016 7:47 AM
> To: Tom Stellard
> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
> LLDB Dev; cfe-dev
> Subject: Re: [llvm-dev] [3.9 Release] Release plan and call for testers
> 
> On 13 June 2016 at 10:11, Tom Stellard  wrote:
> > On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
> >> > The 4.1 release gives us the opportunity to drop support for 3.x
> >> > bitcode formats, so  I don't think we should move to 4.x until we
> have
> >> > older bitcode features that we really want to drop.  There should
> >> > probably be a separate discussion thread about this.
> >>
> >> It give the opportunity, not the obligation. Given that I think it is
> >> an independent issue and would suggest we just keep the revisions
> >> simple and switch trunk to 4.0.
> >>
> >
> > Hi Rafael,
> >
> > The main issue I see with automatically moving to 4.0, is that if a year
> > from now we decide we want to drop a bitcode feature, we can't really do
> > it unless we bump the major version again to 5.0.  If we continue on
> > with 3.x, then we still have the flexibility to drop bitcode features
> > when we decide it's necessary.
> 
> OK, I guess that is where your reading of the version differ.
> 
> I read that we promise that 4.0 will read all of 3.X, but make no
> further promises. That means that in 4.1 we *can* drop support for all
> 3.x, keep support for everything or something in the middle. But that
> is also true for 4.2. So for example it would be valid that
> 
> * 4.0 reads all of 3.x
> * 4.1 reads >= 3.1
> * 4.2 reads >= 3.3

I don't know that the actual policy has ever been formally documented,
although it has been discussed from time to time, so it's not too
surprising that people have different ideas of what the policy is.

Maybe documenting the release-numbering-semantics policy alongside
the release-timing policy would be a good idea?
--paulr

> 
> Cheers,
> Rafael
> ___
> 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.9 Release] Release plan and call for testers

[Hans Wennborg via lldb-dev]

On Mon, Jun 13, 2016 at 9:24 AM, Robinson, Paul via cfe-dev
 wrote:
>
>
>> -Original Message-
>> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
>> Rafael Espíndola via llvm-dev
>> Sent: Monday, June 13, 2016 7:47 AM
>> To: Tom Stellard
>> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
>> LLDB Dev; cfe-dev
>> Subject: Re: [llvm-dev] [3.9 Release] Release plan and call for testers
>>
>> On 13 June 2016 at 10:11, Tom Stellard  wrote:
>> > On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
>> >> > The 4.1 release gives us the opportunity to drop support for 3.x
>> >> > bitcode formats, so  I don't think we should move to 4.x until we
>> have
>> >> > older bitcode features that we really want to drop.  There should
>> >> > probably be a separate discussion thread about this.
>> >>
>> >> It give the opportunity, not the obligation. Given that I think it is
>> >> an independent issue and would suggest we just keep the revisions
>> >> simple and switch trunk to 4.0.
>> >>
>> >
>> > Hi Rafael,
>> >
>> > The main issue I see with automatically moving to 4.0, is that if a year
>> > from now we decide we want to drop a bitcode feature, we can't really do
>> > it unless we bump the major version again to 5.0.  If we continue on
>> > with 3.x, then we still have the flexibility to drop bitcode features
>> > when we decide it's necessary.
>>
>> OK, I guess that is where your reading of the version differ.
>>
>> I read that we promise that 4.0 will read all of 3.X, but make no
>> further promises. That means that in 4.1 we *can* drop support for all
>> 3.x, keep support for everything or something in the middle. But that
>> is also true for 4.2. So for example it would be valid that
>>
>> * 4.0 reads all of 3.x
>> * 4.1 reads >= 3.1
>> * 4.2 reads >= 3.3
>
> I don't know that the actual policy has ever been formally documented,
> although it has been discussed from time to time, so it's not too
> surprising that people have different ideas of what the policy is.
>
> Maybe documenting the release-numbering-semantics policy alongside
> the release-timing policy would be a good idea?

If someone could just let me know what the policy actually is.. ;-)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Tom Stellard via lldb-dev]

On Fri, Jun 10, 2016 at 01:38:22PM -0700, Hans Wennborg via llvm-dev wrote:
> Hello everyone,
> 
> It's time to start planning for the 3.9 release.
> 
> Please let me know if you'd like to help providing binaries and
> testing for your favourite platform.
> 
> I propose the following schedule:
> 
> - 18 July: Create the release branch; build and test RC1 soon thereafter.
> 
> - 1 August: Tag, build and test RC2. Any unfinished features need to
> be turned off by now. As we get closer to the release, the bar for
> merging patches rises.
> 
> - 22 August: Tag 3.9.0-final. The release ships when binaries are ready.
> 
> 
> Also, I have three more questions for the community:
> 
> 1) Right after the branch, the version number of the trunk will be
> incremented. I assume this means bumping the major version number,
> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.
> 

The 4.1 release gives us the opportunity to drop support for 3.x
bitcode formats, so  I don't think we should move to 4.x until we have
older bitcode features that we really want to drop.  There should
probably be a separate discussion thread about this.

-Tom




> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases per year: one in early March (branching
> mid-January), and one early September (branching mid-July), usually
> with one (or sometimes two) "dot" releases in between.
> 
> 3) Another follow-up from that thread: it's usually the same people
> who test the releases for their platform. Rather than asking everyone
> each time, I'd like to make a list of who's responsible for each
> platform and put that on the web page. Testers can still sign-up or
> resign as they like, of course. Would you testers be OK with this?
> 

This is a great idea.

-Tom

> Let me know what you think.
> 
> Cheers,
> Hans
> 
> 
>  [1]. http://lists.llvm.org/pipermail/llvm-dev/2016-May/099541.html
> ___
> 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] [3.9 Release] Release plan and call for testers

[Tom Stellard via lldb-dev]

On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
> > The 4.1 release gives us the opportunity to drop support for 3.x
> > bitcode formats, so  I don't think we should move to 4.x until we have
> > older bitcode features that we really want to drop.  There should
> > probably be a separate discussion thread about this.
> 
> It give the opportunity, not the obligation. Given that I think it is
> an independent issue and would suggest we just keep the revisions
> simple and switch trunk to 4.0.
> 

Hi Rafael,

The main issue I see with automatically moving to 4.0, is that if a year
from now we decide we want to drop a bitcode feature, we can't really do
it unless we bump the major version again to 5.0.  If we continue on
with 3.x, then we still have the flexibility to drop bitcode features
when we decide it's necessary.

-Tom

> Cheers,
> Rafael
___
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.9 Release] Release plan and call for testers

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
> Wennborg
> Sent: Monday, June 13, 2016 9:27 AM
> To: Robinson, Paul
> Cc: Rafael Espíndola; Tom Stellard; llvm-...@lists.llvm.org; Release-
> testers; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
> Subject: Re: [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for
> testers
> 
> On Mon, Jun 13, 2016 at 9:24 AM, Robinson, Paul via cfe-dev
>  wrote:
> >
> >
> >> -Original Message-
> >> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
> >> Rafael Espíndola via llvm-dev
> >> Sent: Monday, June 13, 2016 7:47 AM
> >> To: Tom Stellard
> >> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
> >> LLDB Dev; cfe-dev
> >> Subject: Re: [llvm-dev] [3.9 Release] Release plan and call for testers
> >>
> >> On 13 June 2016 at 10:11, Tom Stellard  wrote:
> >> > On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
> >> >> > The 4.1 release gives us the opportunity to drop support for 3.x
> >> >> > bitcode formats, so  I don't think we should move to 4.x until we
> >> have
> >> >> > older bitcode features that we really want to drop.  There should
> >> >> > probably be a separate discussion thread about this.
> >> >>
> >> >> It give the opportunity, not the obligation. Given that I think it
> is
> >> >> an independent issue and would suggest we just keep the revisions
> >> >> simple and switch trunk to 4.0.
> >> >>
> >> >
> >> > Hi Rafael,
> >> >
> >> > The main issue I see with automatically moving to 4.0, is that if a
> year
> >> > from now we decide we want to drop a bitcode feature, we can't really
> do
> >> > it unless we bump the major version again to 5.0.  If we continue on
> >> > with 3.x, then we still have the flexibility to drop bitcode features
> >> > when we decide it's necessary.
> >>
> >> OK, I guess that is where your reading of the version differ.
> >>
> >> I read that we promise that 4.0 will read all of 3.X, but make no
> >> further promises. That means that in 4.1 we *can* drop support for all
> >> 3.x, keep support for everything or something in the middle. But that
> >> is also true for 4.2. So for example it would be valid that
> >>
> >> * 4.0 reads all of 3.x
> >> * 4.1 reads >= 3.1
> >> * 4.2 reads >= 3.3
> >
> > I don't know that the actual policy has ever been formally documented,
> > although it has been discussed from time to time, so it's not too
> > surprising that people have different ideas of what the policy is.
> >
> > Maybe documenting the release-numbering-semantics policy alongside
> > the release-timing policy would be a good idea?
> 
> If someone could just let me know what the policy actually is.. ;-)

I think this is probably a case where the best approach is to write up
*some* kind of policy, and then it gets thrashed out in review.
--paulr

___
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.9 Release] Release plan and call for testers

[Renato Golin via lldb-dev]

On 13 June 2016 at 17:24, Robinson, Paul via cfe-dev
 wrote:
> I don't know that the actual policy has ever been formally documented,
> although it has been discussed from time to time, so it's not too
> surprising that people have different ideas of what the policy is.

There isn't one. Never was. The *big* changes from 1.x to 2.x and 2.x
to 3.x were coincidental at best. There was no effort to hold features
until "the next big release comes out", like GCC.

However, I do want us to change to follow what almost all other OSS
projects do, so writing it as a policy now may discourage that change
and give folks some comfort that their idea has merits.

I fundamentally agree with David that we have a poor way of naming
releases, and that messes up a lot of infrastructure out there.

But we do have one policy, which is to warn of any potentially
damaging change with *at least* one release in advance.

Until now, we always moved from x.9 to (x+1).0. Not because it was a
rule or was written somewhere, but because we did. So, doing it again
will yield no surprise. If, OTOH, we create a 3.10, it will be our
first two-digit release, and that may, actually, break stuff
downstream.

So, my proposal on IRC was the following:

1. Get over it, call it 4.0 and release 3.9 as scheduled.
2. *Just after* the release, start the discussion for 5.0

This way we'll have at least 5 years to get it right, and people will
know (we can document that) that changes are coming. But we can also
change from (ex) 4.3 to 5.0 as soon as we agree that we'll do that.

My point for the delay is two-fold:

1. Changing the number is not just about naming, it's about behaviour.
We'll be telling the world that Clang/LLVM 3.x should work with *any*
3.x components, which is *not* true today.
2. We'll give time for people to agree or disagree, before we name the
release on SVN. People release Git-versions of LLVM and call them
"llvm-3.9-git". Imagine if we create "llvm-3.10-git" but we decide to
change later on to 4.0?

So, let's discuss about code freeze, feature branches, stable
releases, etc, *first*. But for that, it'd be good to get the SVN vs.
Git out of the way even sooner, so, we're talking years, here...

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] [3.9 Release] Release plan and call for testers

[Rafael Espíndola via lldb-dev]

> I don't know that the actual policy has ever been formally documented,
> although it has been discussed from time to time, so it's not too
> surprising that people have different ideas of what the policy is.
>
> Maybe documenting the release-numbering-semantics policy alongside
> the release-timing policy would be a good idea?


It is documented at

http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

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

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Renato Golin via lldb-dev]

On 13 June 2016 at 18:02, Rafael Espíndola  wrote:
> It is documented at
>
> http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

This is weird...

"The bitcode format produced by a X.Y release will be readable by all
following X.Z releases and the (X+1).0 release."

Why (x+1).0 ?

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

[lldb-dev] [Bug 28091] Build docs shouldn

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=28091

Eugene Zelenko  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||eugene.zele...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from Eugene Zelenko  ---
Looks like copy of bug 28092.

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

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Rafael Espíndola via lldb-dev]

On 13 June 2016 at 13:30, Michael Kuperstein  wrote:
> It would probably better for whoever wrote this text to pipe in, but I think
> the idea is that (X+1).0 is supposed to be a kind of a "bridge" release.
>
> That is, if you have legacy IR files that contain dropped features, or if
> the IR format changed significantly, you can still use the (X+1).0
> auto-upgrade (which may be fairly complex) to read them, but this
> auto-upgrade complexity may be dropped in (X+1).1.
> I'm not completely sure this makes sense, but this is how I've always
> understood it.

I think that is the idea. When the text was written it was just
codifying existing practices (3.0 could read 2.X).

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

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Renato Golin via lldb-dev]

On 13 June 2016 at 18:30, Michael Kuperstein  wrote:
> It would probably better for whoever wrote this text to pipe in, but I think
> the idea is that (X+1).0 is supposed to be a kind of a "bridge" release.

That rings a bell... but I have to be honest, it's weird...

Now, well, as Rafael said originally, our policy doesn't state how
long we can go (3.10, 3.11 or 3.9 -> 4.0), nor it does *require* that
we change the ABI on (X+1). FWIW, the Linux kernel seems to be going
that way, too.

Whatever works, but it would be good to choose something based on
consensus and document.

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] [3.9 Release] Release plan and call for testers

[Mehdi Amini via lldb-dev]

> On Jun 13, 2016, at 6:14 AM, Rafael Espíndola via llvm-dev 
>  wrote:
> 
>> The 4.1 release gives us the opportunity to drop support for 3.x
>> bitcode formats, so  I don't think we should move to 4.x until we have
>> older bitcode features that we really want to drop.  There should
>> probably be a separate discussion thread about this.
> 
> It give the opportunity, not the obligation.

I don't see this way: it means that we stop supporting compatibility, even if 
we don't aggressively remove the auto-upgradecode. It looks like an important 
decision and we should not take it lightly.

-- 
Mehdi


> Given that I think it is
> an independent issue and would suggest we just keep the revisions
> simple and switch trunk to 4.0.
> 
> Cheers,
> Rafael
> ___
> 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] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

Breaking this out into a separate thread since it's kind of a separate
issue, and to make sure people see it.

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.

- 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] [3.9 Release] Release plan and call for testers

[Hans Wennborg via lldb-dev]

I've split the version discussion off into a new thread ("What version
comes after 3.9?") and CC'd everyone discussing it here so far.

On Mon, Jun 13, 2016 at 11:23 AM, Mehdi Amini via llvm-dev
 wrote:
>
>> On Jun 13, 2016, at 6:14 AM, Rafael Espíndola via llvm-dev 
>>  wrote:
>>
>>> The 4.1 release gives us the opportunity to drop support for 3.x
>>> bitcode formats, so  I don't think we should move to 4.x until we have
>>> older bitcode features that we really want to drop.  There should
>>> probably be a separate discussion thread about this.
>>
>> It give the opportunity, not the obligation.
>
> I don't see this way: it means that we stop supporting compatibility, even if 
> we don't aggressively remove the auto-upgradecode. It looks like an important 
> decision and we should not take it lightly.
>
> --
> Mehdi
>
>
>> Given that I think it is
>> an independent issue and would suggest we just keep the revisions
>> simple and switch trunk to 4.0.
>>
>> Cheers,
>> Rafael
>> ___
>> 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 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] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hal Finkel via lldb-dev]

- Original Message -
> From: "Hans Wennborg via cfe-dev" 
> To: "llvm-dev" , "cfe-dev" , 
> "LLDB Dev" ,
> "openmp-dev (openmp-...@lists.llvm.org)" 
> Cc: "r jordans" , "Paul Robinson" 
> 
> Sent: Monday, June 13, 2016 6:54:19 PM
> Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release 
> plan and call for testers)
> 
> Breaking this out into a separate thread since it's kind of a
> separate
> issue, and to make sure people see it.
> 
> 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.
> 
> - But maybe we want to save 4.0 for when we do have a significant IR
> change?

I think that this is the right approach, and we happen to have a natural 
forcing function here: opaque pointer types. I think we should increment the 
major version number when opaque pointer types are here, as it will be a major 
breaking change, and then we'll have a version 4.0. Until then, unless 
something else breaking comes up, 3.10 sounds fine to me.

 -Hal

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[David Blaikie via lldb-dev]

On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> - Original Message -
> > From: "Hans Wennborg via cfe-dev" 
> > To: "llvm-dev" , "cfe-dev" <
> cfe-...@lists.llvm.org>, "LLDB Dev" ,
> > "openmp-dev (openmp-...@lists.llvm.org)" 
> > Cc: "r jordans" , "Paul Robinson" <
> paul_robin...@playstation.sony.com>
> > Sent: Monday, June 13, 2016 6:54:19 PM
> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release]
> Release plan and call for testers)
> >
> > Breaking this out into a separate thread since it's kind of a
> > separate
> > issue, and to make sure people see it.
> >
> > 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.
> >
> > - But maybe we want to save 4.0 for when we do have a significant IR
> > change?
>
> I think that this is the right approach, and we happen to have a natural
> forcing function here: opaque pointer types. I think we should increment
> the major version number when opaque pointer types are here, as it will be
> a major breaking change, and then we'll have a version 4.0. Until then,
> unless something else breaking comes up, 3.10 sounds fine to me.
>

At least naively, I'd expect opaque pointer types to be backwards
compatible (ie: we can load old bitcode and just strip all the pointer
types and bitcasts). But perhaps it still meets the bar of a big change &
may be worth shedding all the backwards compatibility weight sooner rather
than later after the change, for sure.

(as to the main issue - yeah, I tend to agree with you/Mehdi, etc - go to
3.10 and so on, until we decide it's worth breaking back-compat - do we
need to update any wording about our back-compat guarantee that says we
won't do the inverse (4.3 -> 5.0 because we decide we have another breaking
change), though? Since we'll demonstrated that primary version bumps aren't
on a strict ~5 year cycle anymore - probably don't need to do anything, but
just a thought)

- Dave


>
>  -Hal
>
> >
> > - 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
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> ___
> 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] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Saleem Abdulrasool via lldb-dev]

On Mon, Jun 13, 2016 at 5:01 PM, Mehdi Amini via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

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

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.


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



-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Incorrect libclang dependency in standalone build

[Pavel Labath via lldb-dev]

I don't think you need to concern yourself with that comment. We
should make the dependency graph cleaner, but that is not something
related to your current problem.

IIUC, in case of a standalone build, you can assume that the relevant
target was already built, and you don't need to add it to the
dependency list. So, you should just be able to wrap that statement in
an if(). Ideally something like IF(LLDB_STANDALONE_BUILD), but it that
is not possible IF(TARGET libclang) will work as well...

pl


On 10 June 2016 at 16:34, Eugene Zelenko via lldb-dev
 wrote:
> On Fri, Jun 10, 2016 at 4:25 PM, Pavel Labath  wrote:
>> This is a side-effect of the cmake version bump to 3.4. Cmake now
>> errors out on non-existing targets. You'll need to figure out a way to
>> avoid adding this target to the dependency list. Patches welcome. :)
>
> Comment in cmake/modules/AddLLDB.cmake tells:
>
> # Hack: only some LLDB libraries depend on the clang autogenerated headers,
> # but it is simple enough to make all of LLDB depend on some of those
> # headers without negatively impacting much of anything.
> add_dependencies(${name} libclang)
>
> May be dependencies should be expressed explicitly? Of course, if
> libraries will be valid.
>
>> pl
>
> Eugene.
> ___
> 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] 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  wrote:
> 
> On Mon, Jun 13, 2016 at 5:01 PM, Mehdi Amini via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> > 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.
> 
> 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] [llvm-dev] [3.9 Release] Release plan and call for testers

[Michael Kuperstein via lldb-dev]

It would probably better for whoever wrote this text to pipe in, but I
think the idea is that (X+1).0 is supposed to be a kind of a "bridge"
release.

That is, if you have legacy IR files that contain dropped features, or if
the IR format changed significantly, you can still use the (X+1).0
auto-upgrade (which may be fairly complex) to read them, but this
auto-upgrade complexity may be dropped in (X+1).1.
I'm not completely sure this makes sense, but this is how I've always
understood it.

On Mon, Jun 13, 2016 at 10:22 AM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 13 June 2016 at 18:02, Rafael Espíndola 
> wrote:
> > It is documented at
> >
> > http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
>
> This is weird...
>
> "The bitcode format produced by a X.Y release will be readable by all
> following X.Z releases and the (X+1).0 release."
>
> Why (x+1).0 ?
>
> --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