Binutils release 2.28 - soon

Binutils release 2.28 - soon

[Tristan Gingold]

Hello,

if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).

However, commit activity is still high and I'd prefer not to cut arbitrary.
It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!

Tristan.

Re: Binutils release 2.28 - soon

[Jiong Wang]

Tristan Gingold writes:

> Hello,
>
> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>
> However, commit activity is still high and I'd prefer not to cut arbitrary.
> It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!
>
> Tristan.

Ping the following three patches:

https://sourceware.org/ml/binutils/2016-12/msg00059.html ([AArch64][1/4] Make GAS testcases support ILP32 mode)
https://sourceware.org/ml/binutils/2016-12/msg00061.html ([AArch64][2/4] Make LD testcases support ILP32 mode)
https://sourceware.org/ml/binutils/2016-12/msg00060.html ([AArch64][3/4]
Recognize R_AARCH64_P32_ABS32 as 32-bit relocation in readelf)

They are improvements to GAS and LD testsuite for ILP32 on AArch64.  I
hope they can be included into 2.28

Thanks.


-- 
Regards,
Jiong

Re: Binutils release 2.28 - soon

[Alan Modra]

On Mon, Dec 12, 2016 at 10:49:19AM +0100, Tristan Gingold wrote:
> However, commit activity is still high and I'd prefer not to cut arbitrary.

I suggest that we cut the branch when you have a release candidate.

We don't have anything written about stages of development like the
gcc project, but I think your email should be seen as notice that we
are now in bug fixing mode.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Binutils release 2.28 - soon

[Andrew Pinski]

On Mon, Dec 12, 2016 at 1:49 AM, Tristan Gingold <gingold@adacore.com> wrote:
> Hello,
>
> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>
> However, commit activity is still high and I'd prefer not to cut arbitrary.
> It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!

I think it would be good if we get the fixes for AARCH64 ILP32
reviewed and in for 2.28.  I don't know how many are pending right now
though.

Thanks,
Andrew

>
> Tristan.
>

Re: Binutils release 2.28 - soon

[Yury Norov]

On Mon, Dec 12, 2016 at 04:08:46PM -0800, Andrew Pinski wrote:
> On Mon, Dec 12, 2016 at 1:49 AM, Tristan Gingold <gingold@adacore.com> wrote:
> > Hello,
> >
> > if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
> >
> > However, commit activity is still high and I'd prefer not to cut arbitrary.
> > It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!
> 
> I think it would be good if we get the fixes for AARCH64 ILP32
> reviewed and in for 2.28.  I don't know how many are pending right now
> though.

This is my patches I'd like to see in 2.28:
https://sourceware.org/ml/binutils/2016-12/msg00039.html
https://sourceware.org/ml/binutils/2016-12/msg00167.html

Yury

Re: Binutils release 2.28 - soon

[Maciej W. Rozycki]

Hi Tristan,

> if we still follow the new plan, the next release should be made early 
> 2017, which means the 2.28 branch should be created soon (TM).
> 
> However, commit activity is still high and I'd prefer not to cut 
> arbitrary. It would be nice if the branch could be created this week or 
> the next week; if this doesn't work for you, please answer to this mail 
> and share your plans!

 I still have a major MIPS feature to commit (which the recent commits are 
a preparation to) and don't expect to have it there but by the end of next 
week.  I thought you'd be creating the branch after the New Year only -- 
which I think would be reasonable due to the festive season and people 
being busy with other activities.

  Maciej

Re: Binutils release 2.28 - soon

[Nick Clifton]

Hi Jiong,

> Ping the following three patches:
> 
> https://sourceware.org/ml/binutils/2016-12/msg00059.html ([AArch64][1/4] Make GAS testcases support ILP32 mode)
> https://sourceware.org/ml/binutils/2016-12/msg00061.html ([AArch64][2/4] Make LD testcases support ILP32 mode)
> https://sourceware.org/ml/binutils/2016-12/msg00060.html ([AArch64][3/4]
> Recognize R_AARCH64_P32_ABS32 as 32-bit relocation in readelf)

All of these patches have been approved by me and are waiting for you to check them in.
If you do not have write access there is bound to be somebody else at ARM who can check
them in for you *cough*Richard Earnshaw*cough*.  But if they are busy then please ping
me and I will take care of it.

Cheers
  Nick

Re: Binutils release 2.28 - soon

[Jiong Wang]

Nick Clifton writes:

> Hi Jiong,
>
>> Ping the following three patches:
>> 
>> https://sourceware.org/ml/binutils/2016-12/msg00059.html ([AArch64][1/4] Make GAS testcases support ILP32 mode)
>> https://sourceware.org/ml/binutils/2016-12/msg00061.html ([AArch64][2/4] Make LD testcases support ILP32 mode)
>> https://sourceware.org/ml/binutils/2016-12/msg00060.html ([AArch64][3/4]
>> Recognize R_AARCH64_P32_ABS32 as 32-bit relocation in readelf)
>
> All of these patches have been approved by me and are waiting for you to check them in.
> If you do not have write access there is bound to be somebody else at ARM who can check
> them in for you *cough*Richard Earnshaw*cough*.  But if they are busy then please ping
> me and I will take care of it.

Aha, sorry, I am travelling and was relying on terminal mail client,
somehow missed the approve.

All pushed after a quick aarch64-linux build and test OK.

-- 
Regards,
Jiong

Re: Binutils release 2.28 - soon

[Palmer Dabbelt]

On Mon, 12 Dec 2016 01:49:19 PST (-0800), gingold@adacore.com wrote:
> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>
> However, commit activity is still high and I'd prefer not to cut arbitrary.
> It would be nice if the branch could be created this week or the next week;
> if this doesn't work for you, please answer to this mail and share your
> plans!

Thanks for the heads up.  We actually wanted to get a few things upstream
before a release, as our port got merged while still being a bit of a work in
progress.  We've submitted a patch set

  https://sourceware.org/ml/binutils/2016-12/msg00260.html

that we think is sufficient to do a proper release with (ie, maintaining ABI
compatibility forever).  I don't want to cause too much trouble (and I
definitely don't want to hold up a release), but I really don't want to support
a bad set of ABI flags or relocations -- that would be a mess.  Sorry if this
causes trouble!  We'd really just like to get a sane port before anything gets
released.

I'd also like to thank both Kito and Kuan-Lin, as without their help we would
never have been able to get things in as good of a shape as they currently are.

Re: Binutils release 2.28 - soon

[Cary Coutant]

> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>
> However, commit activity is still high and I'd prefer not to cut arbitrary.
> It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!

Sorry, I meant to respond last week...

I've just checked in -z bndplt support in gold, which is what I really
wanted to get done for 2.28, so I'm OK with whenever you want to
branch.

I still have a bit of a backlog of gold patches to review, but nothing
worth holding up the release.

I'd like to bump the gold version number just before you make the
branch, so if you could give me a heads up, I'd appreciate it.

-cary

Re: Binutils release 2.28 - soon

[Tristan Gingold]

> On 23 Dec 2016, at 05:25, Cary Coutant <ccoutant@gmail.com> wrote:
> 
>> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>> 
>> However, commit activity is still high and I'd prefer not to cut arbitrary.
>> It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!
> 
> Sorry, I meant to respond last week...
> 
> I've just checked in -z bndplt support in gold, which is what I really
> wanted to get done for 2.28, so I'm OK with whenever you want to
> branch.
> 
> I still have a bit of a backlog of gold patches to review, but nothing
> worth holding up the release.
> 
> I'd like to bump the gold version number just before you make the
> branch, so if you could give me a heads up, I'd appreciate it.

I have just made the branch (I will be away next week so I preferred to make it before).
Do not hesitate to bump the gold version on master and on the branch.

Tristan.

Re: Binutils release 2.28 - soon

[Maciej W. Rozycki]

On Fri, 23 Dec 2016, Tristan Gingold wrote:

> I have just made the branch (I will be away next week so I preferred 
> to make it before). Do not hesitate to bump the gold version on master 
> and on the branch.

 FYI, I'll be automatically pushing all changes I've intended to make as 
a part of the current MIPS development effort to this branch then, until 
a further notice.

 I'll be away from tomorrow until Jan 8th, and I will have further stuff 
to push when I am back, as I won't be able to complete the documentation 
and test suite updates tonight for the upcoming MIPS feature I intend to 
publish.

 Thanks for the extra work you caused me and Merry Christmas anyway.

  Maciej

Re: Binutils release 2.28 - soon

[Alan Modra]

On Fri, Dec 23, 2016 at 07:08:20PM +0000, Maciej W. Rozycki wrote:
>  Thanks for the extra work you caused me and Merry Christmas anyway.

Heh.  At least it's really easy to backport with git cherry-pick and
git-merge-changelog.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Binutils release 2.28 - soon

[Matthias Klose]

[CCing Joel]

On 23.12.2016 10:13, Tristan Gingold wrote:
> I have just made the branch (I will be away next week so I preferred to make it before).
> Do not hesitate to bump the gold version on master and on the branch.

As with the 2.27 branch, the date bumps are not enabled on the 2.28 branch.
Maybe worth documenting for the release process.

Matthias

Re: Binutils release 2.28 - soon

[Joel Brobecker]

> On 23.12.2016 10:13, Tristan Gingold wrote:
> > I have just made the branch (I will be away next week so I preferred
> > to make it before).  Do not hesitate to bump the gold version on
> > master and on the branch.
> 
> As with the 2.27 branch, the date bumps are not enabled on the 2.28 branch.
> Maybe worth documenting for the release process.

Thanks for the heads up. IMO, we should resume the efforts in trying
to get rid of that date (using the git revision when available instead),
so as to avoid those daily checkins. On the branch especially, they
completely drown the real commits, rendering the branch history
very painful to read.

In the meantime, i've updated the branch name for the date bump.

-- 
Joel

Re: Binutils release 2.28 - soon

[Matthias Klose]

On 29.12.2016 05:44, Joel Brobecker wrote:
>> On 23.12.2016 10:13, Tristan Gingold wrote:
>>> I have just made the branch (I will be away next week so I preferred
>>> to make it before).  Do not hesitate to bump the gold version on
>>> master and on the branch.
>>
>> As with the 2.27 branch, the date bumps are not enabled on the 2.28 branch.
>> Maybe worth documenting for the release process.
> 
> Thanks for the heads up. IMO, we should resume the efforts in trying
> to get rid of that date (using the git revision when available instead),
> so as to avoid those daily checkins. On the branch especially, they
> completely drown the real commits, rendering the branch history
> very painful to read.
> 
> In the meantime, i've updated the branch name for the date bump.

thanks!  I still think using the date is more expressive than using a commit ID.
 So what about only bumping the date if the last commit is not a date bump?

Matthias

Re: Binutils release 2.28 - soon

[Maciej W. Rozycki]

On Thu, 29 Dec 2016, Matthias Klose wrote:

> > Thanks for the heads up. IMO, we should resume the efforts in trying
> > to get rid of that date (using the git revision when available instead),
> > so as to avoid those daily checkins. On the branch especially, they
> > completely drown the real commits, rendering the branch history
> > very painful to read.
> > 
> > In the meantime, i've updated the branch name for the date bump.
> 
> thanks!  I still think using the date is more expressive than using a commit ID.
>  So what about only bumping the date if the last commit is not a date bump?

 Depending on the history of a particular commit its date may be out of 
order, sometimes way out, which may be confusing and having time stamps 
might help -- although we still require any accompanying ChangeLog records 
to have the actual date of the commit being applied to a particular 
branch.

 OTOH extra commits increase the amount of work required for bisection, 
and that can be more costly (e.g. requiring a full toolchain bootstrap per 
iteration) than the amount of effort required to reach out for any 
ChangeLog update included with a given commit.

 FWIW,

  Maciej

Re: Binutils release 2.28 - soon

[Joel Brobecker]

> thanks!  I still think using the date is more expressive than using a
>  commit ID.  So what about only bumping the date if the last commit is
>  not a date bump?

In my opinion, git describe is much much more precise than a date.
Eg:

    % git describe
    ref-tag-190-gdda5790

From there, I know that the commit is 190 commits past a tag called
ref-tag.

-- 
Joel

Re: Binutils release 2.28 - soon

[Matthias Klose]

On 30.12.2016 06:48, Joel Brobecker wrote:
>> thanks!  I still think using the date is more expressive than using a
>>  commit ID.  So what about only bumping the date if the last commit is
>>  not a date bump?
> 
> In my opinion, git describe is much much more precise than a date.
> Eg:
> 
>     % git describe
>     ref-tag-190-gdda5790
> 
> From there, I know that the commit is 190 commits past a tag called
> ref-tag.

This only seems to work when there is a tag once the release branch is created.

Re: Binutils release 2.28 - soon

[Joel Brobecker]

> > From there, I know that the commit is 190 commits past a tag called
> > ref-tag.
> 
> This only seems to work when there is a tag once the release branch is
> created.

That's very easily resolved by updating our procedures. And even if a
tag isn't created, the command will go look for the first one past the
branch point.

-- 
Joel

Re: Binutils release 2.28 - soon

[Andreas Schwab]

On Dez 30 2016, Joel Brobecker <brobecker@adacore.com> wrote:

>> > From there, I know that the commit is 190 commits past a tag called
>> > ref-tag.
>> 
>> This only seems to work when there is a tag once the release branch is
>> created.
>
> That's very easily resolved by updating our procedures. And even if a
> tag isn't created, the command will go look for the first one past the
> branch point.

There are currently no useful annotated tags on master.

$ git describe origin/master 
users/ARM/embedded-binutils-master-2016q4-213-gfa62ef05fc

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Binutils release 2.28 - soon

[Joel Brobecker]

> > That's very easily resolved by updating our procedures. And even if a
> > tag isn't created, the command will go look for the first one past the
> > branch point.
> 
> There are currently no useful annotated tags on master.
> 
> $ git describe origin/master 
> users/ARM/embedded-binutils-master-2016q4-213-gfa62ef05fc

That's also true, but these are really implementation details.
We can sort those out in an instant if/when we decide to move
away from automated daily date bumps.

-- 
Joel

Re: Binutils release 2.28 - soon

[Maciej W. Rozycki]

On Fri, 23 Dec 2016, Maciej W. Rozycki wrote:

>  FYI, I'll be automatically pushing all changes I've intended to make as 
> a part of the current MIPS development effort to this branch then, until 
> a further notice.
> 
>  I'll be away from tomorrow until Jan 8th, and I will have further stuff 
> to push when I am back, as I won't be able to complete the documentation 
> and test suite updates tonight for the upcoming MIPS feature I intend to 
> publish.

 I have decided to withdraw from pushing the feature originally intended 
for 2.28 and keep it to the master branch only.

 Firstly, the delay incurred by all the work related to recent bug fixes, 
and PR ld/20828 in particular, means that any further work on the 2.28 
branch would potentially continue blocking the release without a good 
justification.  Secondly, the extra time bought will let me update the 
feature with some enhancements recently envisaged, making it more complete 
right from the beginning.  It does not mean I expect any significant delay 
with that code though -- it's just that it'll happen on the master branch 
only.

 I think there may yet be some further fallout from PR ld/20828 affecting 
2.28, but otherwise, with the final tweaks to the test suite just applied, 
I consider myself done with MIPS target changes intended for 2.28.

 There are still:

FAIL: objcopy -shared -z relro (tbss1)
FAIL: objcopy -shared -z relro (tbss2)
FAIL: objcopy -shared -z relro (tbss3)

uninvestigated MIPS regressions remaining, which I regret, however they 
are long-standing and not necessarily an actual linker issue.  I will 
strive to resolve them on master soon.

 However if anyone has anything they consider important to resolve for 
2.28 and the MIPS target, then please do let me know and I'll see what I 
can do.

 And last but not least thanks for your patience, Tristan, and your effort 
with release management!

  Maciej

Re: Binutils release 2.28 - soon

[Tristan Gingold]

> On 02 Feb 2017, at 00:33, Maciej W. Rozycki <macro@imgtec.com> wrote:
> 
> On Fri, 23 Dec 2016, Maciej W. Rozycki wrote:
> 
>> FYI, I'll be automatically pushing all changes I've intended to make as 
>> a part of the current MIPS development effort to this branch then, until 
>> a further notice.
>> 
>> I'll be away from tomorrow until Jan 8th, and I will have further stuff 
>> to push when I am back, as I won't be able to complete the documentation 
>> and test suite updates tonight for the upcoming MIPS feature I intend to 
>> publish.
> 
> I have decided to withdraw from pushing the feature originally intended 
> for 2.28 and keep it to the master branch only.
> 
> Firstly, the delay incurred by all the work related to recent bug fixes, 
> and PR ld/20828 in particular, means that any further work on the 2.28 
> branch would potentially continue blocking the release without a good 
> justification.  Secondly, the extra time bought will let me update the 
> feature with some enhancements recently envisaged, making it more complete 
> right from the beginning.  It does not mean I expect any significant delay 
> with that code though -- it's just that it'll happen on the master branch 
> only.
> 
> I think there may yet be some further fallout from PR ld/20828 affecting 
> 2.28, but otherwise, with the final tweaks to the test suite just applied, 
> I consider myself done with MIPS target changes intended for 2.28.
> 
> There are still:
> 
> FAIL: objcopy -shared -z relro (tbss1)
> FAIL: objcopy -shared -z relro (tbss2)
> FAIL: objcopy -shared -z relro (tbss3)
> 
> uninvestigated MIPS regressions remaining, which I regret, however they 
> are long-standing and not necessarily an actual linker issue.  I will 
> strive to resolve them on master soon.
> 
> However if anyone has anything they consider important to resolve for 
> 2.28 and the MIPS target, then please do let me know and I'll see what I 
> can do.
> 
> And last but not least thanks for your patience, Tristan, and your effort 
> with release management!

Thank you for the status update.  That's useful for the release process.

So I plan to to the 2.28 release mid February, unless there is still an urgent patch pending.

Regards,
Tristan.

Re: Binutils release 2.28 - soon

[Alan Modra]

On Thu, Feb 02, 2017 at 05:52:01PM +0100, Tristan Gingold wrote:
> So I plan to to the 2.28 release mid February, unless there is still an urgent patch pending.

Hi Tristan,

There is one thing I'd like to fix for hppa-linux.  -z relro is broken
there, and the patch I applied to the branch made things worse.  I
don't think that should hold up the release, but please give me a days
warning so I can revert the patch or apply the followup fix in pr21000
if Dave's testing shows it is good.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Binutils release 2.28 - soon

[H.J. Lu]

On Thu, Feb 2, 2017 at 8:52 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
>> On 02 Feb 2017, at 00:33, Maciej W. Rozycki <macro@imgtec.com> wrote:
>>
>> On Fri, 23 Dec 2016, Maciej W. Rozycki wrote:
>>
>>> FYI, I'll be automatically pushing all changes I've intended to make as
>>> a part of the current MIPS development effort to this branch then, until
>>> a further notice.
>>>
>>> I'll be away from tomorrow until Jan 8th, and I will have further stuff
>>> to push when I am back, as I won't be able to complete the documentation
>>> and test suite updates tonight for the upcoming MIPS feature I intend to
>>> publish.
>>
>> I have decided to withdraw from pushing the feature originally intended
>> for 2.28 and keep it to the master branch only.
>>
>> Firstly, the delay incurred by all the work related to recent bug fixes,
>> and PR ld/20828 in particular, means that any further work on the 2.28
>> branch would potentially continue blocking the release without a good
>> justification.  Secondly, the extra time bought will let me update the
>> feature with some enhancements recently envisaged, making it more complete
>> right from the beginning.  It does not mean I expect any significant delay
>> with that code though -- it's just that it'll happen on the master branch
>> only.
>>
>> I think there may yet be some further fallout from PR ld/20828 affecting
>> 2.28, but otherwise, with the final tweaks to the test suite just applied,
>> I consider myself done with MIPS target changes intended for 2.28.
>>
>> There are still:
>>
>> FAIL: objcopy -shared -z relro (tbss1)
>> FAIL: objcopy -shared -z relro (tbss2)
>> FAIL: objcopy -shared -z relro (tbss3)
>>
>> uninvestigated MIPS regressions remaining, which I regret, however they
>> are long-standing and not necessarily an actual linker issue.  I will
>> strive to resolve them on master soon.
>>
>> However if anyone has anything they consider important to resolve for
>> 2.28 and the MIPS target, then please do let me know and I'll see what I
>> can do.
>>
>> And last but not least thanks for your patience, Tristan, and your effort
>> with release management!
>
> Thank you for the status update.  That's useful for the release process.
>
> So I plan to to the 2.28 release mid February, unless there is still an urgent patch pending.
>
> Regards,
> Tristan.
>

I am backporting this patch to 2.28 branch:

https://sourceware.org/ml/binutils/2017-02/msg00132.html

-- 
H.J.

Re: Binutils release 2.28 - soon

[Palmer Dabbelt]

On Thu, 02 Feb 2017 08:52:01 PST (-0800), Tristan Gingold wrote:
>
>> On 02 Feb 2017, at 00:33, Maciej W. Rozycki <macro@imgtec.com> wrote:
>>
>> On Fri, 23 Dec 2016, Maciej W. Rozycki wrote:
>>
>>> FYI, I'll be automatically pushing all changes I've intended to make as
>>> a part of the current MIPS development effort to this branch then, until
>>> a further notice.
>>>
>>> I'll be away from tomorrow until Jan 8th, and I will have further stuff
>>> to push when I am back, as I won't be able to complete the documentation
>>> and test suite updates tonight for the upcoming MIPS feature I intend to
>>> publish.
>>
>> I have decided to withdraw from pushing the feature originally intended
>> for 2.28 and keep it to the master branch only.
>>
>> Firstly, the delay incurred by all the work related to recent bug fixes,
>> and PR ld/20828 in particular, means that any further work on the 2.28
>> branch would potentially continue blocking the release without a good
>> justification.  Secondly, the extra time bought will let me update the
>> feature with some enhancements recently envisaged, making it more complete
>> right from the beginning.  It does not mean I expect any significant delay
>> with that code though -- it's just that it'll happen on the master branch
>> only.
>>
>> I think there may yet be some further fallout from PR ld/20828 affecting
>> 2.28, but otherwise, with the final tweaks to the test suite just applied,
>> I consider myself done with MIPS target changes intended for 2.28.
>>
>> There are still:
>>
>> FAIL: objcopy -shared -z relro (tbss1)
>> FAIL: objcopy -shared -z relro (tbss2)
>> FAIL: objcopy -shared -z relro (tbss3)
>>
>> uninvestigated MIPS regressions remaining, which I regret, however they
>> are long-standing and not necessarily an actual linker issue.  I will
>> strive to resolve them on master soon.
>>
>> However if anyone has anything they consider important to resolve for
>> 2.28 and the MIPS target, then please do let me know and I'll see what I
>> can do.
>>
>> And last but not least thanks for your patience, Tristan, and your effort
>> with release management!
>
> Thank you for the status update.  That's useful for the release process.
>
> So I plan to to the 2.28 release mid February, unless there is still an urgent patch pending.

We'd like to get a small patch in that's just waiting on 2.28 approval

  https://sourceware.org/ml/binutils/2017-02/msg00130.html
  https://sourceware.org/ml/binutils/2017-02/msg00103.html

Thanks!