[Buildroot] Policy for upgrading toolchains in LTS version

[Buildroot] Policy for upgrading toolchains in LTS version

[Mason]

Hello,

Providing an LTS version is an interesting idea.

I was wondering about the policy for upgrading toolchains
in LTS versions (I use Linaro).

Case in point: 2017.02.x branch is set up to use gcc-linaro-6.2.1-2016.11

Since then, Linaro has released two bug-fix versions:

https://releases.linaro.org/components/toolchain/binaries/6.1-2016.08/
https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/
https://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/
https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/

AFAIU, these releases are all on the same branch, i.e. they
keep the packages (mostly) stable:
gcc 6, glibc 2.23, newlib 2.4, binutils 2.27, gdb 7.12
NB: Apparently gdb got bumped from 7.11 to 7.12 in 2016.11
(IIUC, this is a cross-debugger, when using remote gdb.)

For example, this bug seems likely to affect current BR LTS:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78253
(It was fixed in Linaro 2017.02)

I think there is a case for upgrading the toolchain in the LTS
branch (while staying on the same Linaro branch of course.)

What do you think?

Regards.

[Buildroot] Policy for upgrading toolchains in LTS version

[Yann E. MORIN]

Mason, All,

On 2017-06-22 11:23 +0200, Mason spake thusly:
> Providing an LTS version is an interesting idea.
> 
> I was wondering about the policy for upgrading toolchains
> in LTS versions (I use Linaro).
> 
> Case in point: 2017.02.x branch is set up to use gcc-linaro-6.2.1-2016.11
> 
> Since then, Linaro has released two bug-fix versions:
> 
> https://releases.linaro.org/components/toolchain/binaries/6.1-2016.08/
> https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/
> https://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/
> https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/
> 
> AFAIU, these releases are all on the same branch, i.e. they
> keep the packages (mostly) stable:
> gcc 6, glibc 2.23, newlib 2.4, binutils 2.27, gdb 7.12
> NB: Apparently gdb got bumped from 7.11 to 7.12 in 2016.11
> (IIUC, this is a cross-debugger, when using remote gdb.)
> 
> For example, this bug seems likely to affect current BR LTS:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78253
> (It was fixed in Linaro 2017.02)
> 
> I think there is a case for upgrading the toolchain in the LTS
> branch (while staying on the same Linaro branch of course.)
> 
> What do you think?

I think that it all depends. ;-)

First, Peter is in charge of the LTS branch, so it's all about what he
believes it is too intrusive or not...

Then, I have basically no knowledge of the Linaro toochains and their
release criterions.

If as you state they are only bug-fix releases, then we could indeed
bump those toolchains, yes. It imho complies with the goal of an LTS.

Note however that we so far never bumped the gcc version in the LTS
branch, but we already had 6.3 at the time we cut the LTS. So it;s
difficult to say if we would bump it. Probably, I'd say...

My 2 euro-cents...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Policy for upgrading toolchains in LTS version

[Mason]

On 22/06/2017 21:27, Yann E. MORIN wrote:

> Mason, All,
> 
> On 2017-06-22 11:23 +0200, Mason spake thusly:
>
>> Providing an LTS version is an interesting idea.
>>
>> I was wondering about the policy for upgrading toolchains
>> in LTS versions (I use Linaro).
>>
>> Case in point: 2017.02.x branch is set up to use gcc-linaro-6.2.1-2016.11
>>
>> Since then, Linaro has released two bug-fix versions:
>>
>> https://releases.linaro.org/components/toolchain/binaries/6.1-2016.08/
>> https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/
>> https://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/
>> https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/
>>
>> AFAIU, these releases are all on the same branch, i.e. they
>> keep the packages (mostly) stable:
>> gcc 6, glibc 2.23, newlib 2.4, binutils 2.27, gdb 7.12
>> NB: Apparently gdb got bumped from 7.11 to 7.12 in 2016.11
>> (IIUC, this is a cross-debugger, when using remote gdb.)
>>
>> For example, this bug seems likely to affect current BR LTS:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78253
>> (It was fixed in Linaro 2017.02)
>>
>> I think there is a case for upgrading the toolchain in the LTS
>> branch (while staying on the same Linaro branch of course.)
>>
>> What do you think?
> 
> I think that it all depends. ;-)
> 
> First, Peter is in charge of the LTS branch, so it's all about what he
> believes it is too intrusive or not...
> 
> Then, I have basically no knowledge of the Linaro toochains and their
> release criterions.

On freenode #linaro-tcwg, Ryan explained the Linaro toolchain
release process to me, which appears to be BR-LTS-compatible.

Toolchain releases are supported for 2 years.

First year in "stable" mode:
Bug fixes, and backports of non-invasive performance fixes for gcc.
One update per quarter.

Second year in "maintenance" mode:
Only bug fixes.
Updates when required (e.g. getaddrinfo vuln, or stack clash)

Individual components (gcc, glibc, newlib, binutils, gdb)
are updated within their respective stable branches, i.e.
kept at the same release (gdb is an exception).

So, for example, the 6.x release is in stable mode until
2017.08, and in maintenance mode until 2018.08
(Ryan pointed out that an OOB release would be done to
address stack clash.)

See also
https://wiki.linaro.org/WorkingGroups/ToolChain/FAQ#What_were.2Fare_the_versions_of_toolchain_released.3F

> If as you state they are only bug-fix releases, then we could indeed
> bump those toolchains, yes. It imho complies with the goal of an LTS.

I believe it does. I don't know exactly how gcc/glibc
plan to address "stack clash" but I think it's important
for BR-LTS to include these fixes.

> Note however that we so far never bumped the gcc version in the LTS
> branch, but we already had 6.3 at the time we cut the LTS. So it's
> difficult to say if we would bump it. Probably, I'd say...

Isn't this the first time BR did an LTS release?

Regards.

[Buildroot] Policy for upgrading toolchains in LTS version

[Peter Korsgaard]

>>>>> "Mason" == Mason  <slash.tmp@free.fr> writes:

Hi,

 > On freenode #linaro-tcwg, Ryan explained the Linaro toolchain
 > release process to me, which appears to be BR-LTS-compatible.

 > Toolchain releases are supported for 2 years.

 > First year in "stable" mode:
 > Bug fixes, and backports of non-invasive performance fixes for gcc.
 > One update per quarter.

 > Second year in "maintenance" mode:
 > Only bug fixes.
 > Updates when required (e.g. getaddrinfo vuln, or stack clash)

 > Individual components (gcc, glibc, newlib, binutils, gdb)
 > are updated within their respective stable branches, i.e.
 > kept at the same release (gdb is an exception).

 > So, for example, the 6.x release is in stable mode until
 > 2017.08, and in maintenance mode until 2018.08
 > (Ryan pointed out that an OOB release would be done to
 > address stack clash.)

 > See also
 > https://wiki.linaro.org/WorkingGroups/ToolChain/FAQ#What_were.2Fare_the_versions_of_toolchain_released.3F

Ok, looks good. I take it that you are asking for this update because
you have run into some of the issues fixed by later versions?

Can you please send a patch (relative to the 2017.02.x branch) bumping
the toolchains and include the above + any details of the issues you
have encountered?


 >> If as you state they are only bug-fix releases, then we could indeed
 >> bump those toolchains, yes. It imho complies with the goal of an LTS.

 > I believe it does. I don't know exactly how gcc/glibc
 > plan to address "stack clash" but I think it's important
 > for BR-LTS to include these fixes.

Agreed.


 >> Note however that we so far never bumped the gcc version in the LTS
 >> branch, but we already had 6.3 at the time we cut the LTS. So it's
 >> difficult to say if we would bump it. Probably, I'd say...

 > Isn't this the first time BR did an LTS release?

Indeed ;) I guess Yann meant that we so far haven't bumped the gcc
version in 2017.02.x (or in any other point releases).

-- 
Bye, Peter Korsgaard

[Buildroot] Policy for upgrading toolchains in LTS version

[Mason]

On 23/06/2017 09:18, Peter Korsgaard wrote:

> Mason wrote:
> 
>> On freenode #linaro-tcwg, Ryan explained the Linaro toolchain
>> release process to me, which appears to be BR-LTS-compatible.
>> 
>> Toolchain releases are supported for 2 years.
>> 
>> First year in "stable" mode:
>> Bug fixes, and backports of non-invasive performance fixes for gcc.
>> One update per quarter.
>> 
>> Second year in "maintenance" mode:
>> Only bug fixes.
>> Updates when required (e.g. getaddrinfo vuln, or stack clash)
>> 
>> Individual components (gcc, glibc, newlib, binutils, gdb)
>> are updated within their respective stable branches, i.e.
>> kept at the same release (gdb is an exception).
>> 
>> So, for example, the 6.x release is in stable mode until
>> 2017.08, and in maintenance mode until 2018.08
>> (Ryan pointed out that an OOB release would be done to
>> address stack clash.)
> 
> Ok, looks good. I take it that you are asking for this update because
> you have run into some of the issues fixed by later versions?

Switching from gcc 5.3 to 6.2 triggered an issue which
*appeared* to go away when using 6.3.

But when the dust settled, the bug turned out to be in
our code (as is the case most of the time).

https://www.spinics.net/lists/gcchelp/msg46864.html

> Can you please send a patch (relative to the 2017.02.x branch) bumping
> the toolchains and include the above + any details of the issues you
> have encountered?

Romain bumped the version from 6.2-2016.11 to 6.3-2017.02
on master. IIUC, you don't want to update master, and then
cherry-pick into the LTS branch?

Is the plan to jump straight to 7.1 for master?

I suppose you want to update all 3 toolchains,
toolchain-external-linaro-{aarch64,arm,armeb}
Can this be done in a single patch, or should it
be split across 3 patches?

As previously mentioned, IIUC, Linaro is preparing an
OOB release addressing "stack clash". I plan to wait
for that release, and then send a patch, is that OK?

Regards.

[Buildroot] Policy for upgrading toolchains in LTS version

[Romain Naour]

Hi Mason, All

Le 23/06/2017 ? 16:15, Mason a ?crit :
> On 23/06/2017 09:18, Peter Korsgaard wrote:
> 
>> Mason wrote:
>>
>>> On freenode #linaro-tcwg, Ryan explained the Linaro toolchain
>>> release process to me, which appears to be BR-LTS-compatible.
>>>
>>> Toolchain releases are supported for 2 years.
>>>
>>> First year in "stable" mode:
>>> Bug fixes, and backports of non-invasive performance fixes for gcc.
>>> One update per quarter.
>>>
>>> Second year in "maintenance" mode:
>>> Only bug fixes.
>>> Updates when required (e.g. getaddrinfo vuln, or stack clash)
>>>
>>> Individual components (gcc, glibc, newlib, binutils, gdb)
>>> are updated within their respective stable branches, i.e.
>>> kept at the same release (gdb is an exception).
>>>
>>> So, for example, the 6.x release is in stable mode until
>>> 2017.08, and in maintenance mode until 2018.08
>>> (Ryan pointed out that an OOB release would be done to
>>> address stack clash.)
>>
>> Ok, looks good. I take it that you are asking for this update because
>> you have run into some of the issues fixed by later versions?
> 
> Switching from gcc 5.3 to 6.2 triggered an issue which
> *appeared* to go away when using 6.3.
> 
> But when the dust settled, the bug turned out to be in
> our code (as is the case most of the time).
> 
> https://www.spinics.net/lists/gcchelp/msg46864.html
> 
>> Can you please send a patch (relative to the 2017.02.x branch) bumping
>> the toolchains and include the above + any details of the issues you
>> have encountered?
> 
> Romain bumped the version from 6.2-2016.11 to 6.3-2017.02
> on master. IIUC, you don't want to update master, and then
> cherry-pick into the LTS branch?

I guess you also want the latest stable Linaro toolchain 2017.05 in the
2017.02.x branch, right ?

So, feel free to send patches bumping all Linaro toolchain to 2017.05 and Peter
will cherry-pick them to the LTS branch.

Don't forget, you can also use the toolchain-external-custom package to import
any external toolchain, even 2017.05 Linaro toolchain using the 2017.02.x branch.

In the past we had a version choice on some toolchains, but we removed this
option since it was difficult to maintain and time consuming [1].

"The pre-configured external toolchains are handy to get started, but keeping
several versions within buildroot is not so useful."

[1] http://elinux.org/Buildroot:DeveloperDaysELCE2015

> 
> Is the plan to jump straight to 7.1 for master?

There is no plan, when time allow I bump the Linaro toolchains.
You're welcome to send patches bumping to this version.

> 
> I suppose you want to update all 3 toolchains,
> toolchain-external-linaro-{aarch64,arm,armeb}
> Can this be done in a single patch, or should it
> be split across 3 patches?

Usually we use 3 separate patches, one for each toolchains.

> 
> As previously mentioned, IIUC, Linaro is preparing an
> OOB release addressing "stack clash". I plan to wait
> for that release, and then send a patch, is that OK?

Ok for me.

Best regards,
Romain

> 
> Regards.
> 

[Buildroot] Policy for upgrading toolchains in LTS version

[Peter Korsgaard]

>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes:

Hi,

 >> As previously mentioned, IIUC, Linaro is preparing an
 >> OOB release addressing "stack clash". I plan to wait
 >> for that release, and then send a patch, is that OK?

 > Ok for me.

Me as well.

-- 
Bye, Peter Korsgaard

[Buildroot] Policy for upgrading toolchains in LTS version

[Mason]

On 23/06/2017 16:15, Mason wrote:

> As previously mentioned, IIUC, Linaro is preparing an
> OOB release addressing "stack clash". I plan to wait
> for that release, and then send a patch, is that OK?

Hello Peter,

yroux has confirmed that the updated toolchain is not
ready yet ("the stack clash mitigation patchset is still
under discussion/review on GCC list").

There will be an update to GCC 6.4 in 2-3 weeks which will
include the mitigation patches *if* they are ready.

In the mean time, could you cherry-pick:

641fe0e39240 toolchain-external: bump Linaro AArch64 toolchain to 2017.02
52f059f38d46 toolchain-external: bump Linaro ARMeb toolchain to 2017.02
075d26900b4f toolchain-external: bump Linaro ARM toolchain to 2017.02

onto the 2017.02.x branch, so that it is in sync with master?

Regards.