2.36 Branch imminent

2.36 Branch imminent

[Nick Clifton]

Hi Guys,

   This is just to let you know that I plan on creating the 2.36 branch
   over the weekend of Jan 9/10 with a view to completing the release over
   the weekend of Jan 23.24.

   So if you have any new features or enhancements that you would like to
   see in the next release, now is the time to submit them for review.

Cheers
   Nick

Re: 2.36 Branch imminent

[H.J. Lu]

On Mon, Dec 14, 2020 at 3:45 AM Nick Clifton via Binutils
<binutils@sourceware.org> wrote:
>
> Hi Guys,
>
>    This is just to let you know that I plan on creating the 2.36 branch
>    over the weekend of Jan 9/10 with a view to completing the release over
>    the weekend of Jan 23.24.
>
>    So if you have any new features or enhancements that you would like to
>    see in the next release, now is the time to submit them for review.
>
> Cheers
>    Nick
>

I'd like to fix gold with SHF_GNU_RETAIN:

https://sourceware.org/pipermail/binutils/2020-December/114458.html

-- 
H.J.

Re: 2.36 Branch imminent

[Nick Clifton]

Hi H.J.

> I'd like to fix gold with SHF_GNU_RETAIN:
> https://sourceware.org/pipermail/binutils/2020-December/114458.html

You will have to ping Cary on this one.

Cheers
   Nick

Re: 2.36 Branch imminent

[H.J. Lu]

On Mon, Dec 14, 2020 at 3:45 AM Nick Clifton via Binutils
<binutils@sourceware.org> wrote:
>
> Hi Guys,
>
>    This is just to let you know that I plan on creating the 2.36 branch
>    over the weekend of Jan 9/10 with a view to completing the release over
>    the weekend of Jan 23.24.
>
>    So if you have any new features or enhancements that you would like to
>    see in the next release, now is the time to submit them for review.
>

I'd like to enable PGO/LTO build for binutils:

https://sourceware.org/pipermail/binutils/2020-October/113943.html

It can speed up the assembler significantly.

-- 
H.J.

Re: 2.36 Branch imminent

[Nick Clifton]

Hi H.J.

> I'd like to enable PGO/LTO build for binutils:
> 
> https://sourceware.org/pipermail/binutils/2020-October/113943.html
> 
> It can speed up the assembler significantly.

I'm all for this.  The binutils parts are approved although I assume
that you will still need buy in from the gdb and gcc folks.

Cheers
   Nick

Re: 2.36 Branch imminent

[H.J. Lu]

On Tue, Dec 15, 2020 at 5:51 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi H.J.
>
> > I'd like to enable PGO/LTO build for binutils:
> >
> > https://sourceware.org/pipermail/binutils/2020-October/113943.html
> >
> > It can speed up the assembler significantly.
>
> I'm all for this.  The binutils parts are approved although I assume
> that you will still need buy in from the gdb and gcc folks.

Toplevel files are shared with GCC.  But my changes are disabled for GCC.
I got no feedbacks from GCC nor GDB developers.  What should I do next?

-- 
H.J.

Re: 2.36 Branch imminent

[Nick Clifton]

Hi H.J.

>>> I'd like to enable PGO/LTO build for binutils:
>>> https://sourceware.org/pipermail/binutils/2020-October/113943.html

> Toplevel files are shared with GCC.  But my changes are disabled for GCC.
> I got no feedbacks from GCC nor GDB developers.  What should I do next?

Hmmm.  Please try contacting them again.  Given that we are now entering
the holiday period however, I would not be surprised if responses are
delayed.  If there is still no response by the first week of January
ping me again and I will see what I can do.

Cheers
   Nick

Re: 2.36 Branch imminent

[Tom Tromey]

> Toplevel files are shared with GCC.  But my changes are disabled for GCC.
> I got no feedbacks from GCC nor GDB developers.  What should I do next?

I looked at the link and didn't see any changes to gdb in there; and it
didn't seem to be CC'd to gdb-patches (?).  So in this situation I
wouldn't expect a response from gdb developers.

thanks,
Tom

Re: 2.36 Branch imminent

[H.J. Lu]

On Tue, Dec 15, 2020 at 9:15 AM Tom Tromey <tom@tromey.com> wrote:
>
> > Toplevel files are shared with GCC.  But my changes are disabled for GCC.
> > I got no feedbacks from GCC nor GDB developers.  What should I do next?
>
> I looked at the link and didn't see any changes to gdb in there; and it
> didn't seem to be CC'd to gdb-patches (?).  So in this situation I
> wouldn't expect a response from gdb developers.
>

https://sourceware.org/pipermail/gdb-patches/2020-December/174120.html

Someone needs to try PGO and LTO build with GDB.   "make check" in GDB
can be used for PGO training.

-- 
H.J.

Re: 2.36 Branch imminent

[Tom Tromey]

>> https://sourceware.org/pipermail/gdb-patches/2020-December/174120.html

Thanks.

>> Someone needs to try PGO and LTO build with GDB.   "make check" in GDB
>> can be used for PGO training.

If the patches don't affect ordinary gdb builds, then I think it's fine
from the gdb perspective.

If you want PGO to work with gdb, then maybe you could try it.  Also, it
seems unusual that configure changes were needed in other directories,
but not in any of the gdb-related ones.

I'm not sure that the gdb test suite is really representative of what
GDB normally does.  It tries to exercise all of GDB's features, which
includes many weird things that aren't normally used.  On the other
hand, the typical cause of performance problems in GDB is the DWARF
reader.  So perhaps a better training would be just "gdb -batch gdb".

Tom

Re: 2.36 Branch imminent

[H.J. Lu]

On Tue, Dec 15, 2020 at 9:33 AM Tom Tromey <tom@tromey.com> wrote:
>
> >> https://sourceware.org/pipermail/gdb-patches/2020-December/174120.html
>
> Thanks.
>
> >> Someone needs to try PGO and LTO build with GDB.   "make check" in GDB
> >> can be used for PGO training.
>
> If the patches don't affect ordinary gdb builds, then I think it's fine

PGO build needs to be enabled with --enable-pgo-build.

> from the gdb perspective.

Thanks.

> If you want PGO to work with gdb, then maybe you could try it.  Also, it
> seems unusual that configure changes were needed in other directories,
> but not in any of the gdb-related ones.

My binutils PGO/LTO branch is at

https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pgo-lto

GDB PGO training with "make check" failed.   Interested GDB developers
can try to fix GDB PGO build  and send me patches.

> I'm not sure that the gdb test suite is really representative of what
> GDB normally does.  It tries to exercise all of GDB's features, which
> includes many weird things that aren't normally used.  On the other
> hand, the typical cause of performance problems in GDB is the DWARF
> reader.  So perhaps a better training would be just "gdb -batch gdb".
>

-- 
H.J.

Re: 2.36 Branch imminent

[Nick Clifton]

Hi H.J.

>>>> https://sourceware.org/pipermail/gdb-patches/2020-December/174120.html
  
Where are we with testing of this patch for other projects ?

I think that I saw a problem report from a gdb developer fly by, but
I may have been mistaken.

Cheers
   Nick

Re: 2.36 Branch imminent

[H.J. Lu]

On Tue, Jan 5, 2021 at 2:50 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi H.J.
>
> >>>> https://sourceware.org/pipermail/gdb-patches/2020-December/174120.html
>
> Where are we with testing of this patch for other projects ?
>
> I think that I saw a problem report from a gdb developer fly by, but
> I may have been mistaken.
>

I got no feedbacks for my current patch set:

https://sourceware.org/pipermail/gdb-patches/2020-December/174216.html


-- 
H.J.

Re: 2.36 Branch imminent

[Nick Clifton]

Hi H.J.

> I got no feedbacks for my current patch set:
> https://sourceware.org/pipermail/gdb-patches/2020-December/174216.html

Right - in which case I would like to do this:

   1. Do not apply the patch now.  But when the 2.36 branch is
      created apply it there as soon as you can.  (In order to
      give us time to see if any problem arise - I am not
      expecting any though).

   2. Continue to ping the gdb abd gcc folks.  If we can get
      them to approve the patch then we can check it into the
      mainline sources, hopefully before the 2.37 release happens.

Cheers
   Nick

Support the PGO build for binutils+gdb (2.36 Branch imminent)

[H.J. Lu]

On Thu, Jan 7, 2021 at 4:10 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi H.J.
>
> > I got no feedbacks for my current patch set:
> > https://sourceware.org/pipermail/gdb-patches/2020-December/174216.html
>
> Right - in which case I would like to do this:
>
>    1. Do not apply the patch now.  But when the 2.36 branch is
>       created apply it there as soon as you can.  (In order to
>       give us time to see if any problem arise - I am not
>       expecting any though).

I am checking in my patches now.

>    2. Continue to ping the gdb abd gcc folks.  If we can get
>       them to approve the patch then we can check it into the
>       mainline sources, hopefully before the 2.37 release happens.
>
> Cheers
>    Nick
>
>


-- 
H.J.

Re: 2.36 Branch imminent

[Pedro Alves]

On 12/15/20 5:25 PM, H.J. Lu via Binutils wrote:
> On Tue, Dec 15, 2020 at 9:15 AM Tom Tromey <tom@tromey.com> wrote:
>>> Toplevel files are shared with GCC.  But my changes are disabled for GCC.
>>> I got no feedbacks from GCC nor GDB developers.  What should I do next?
>> I looked at the link and didn't see any changes to gdb in there; and it
>> didn't seem to be CC'd to gdb-patches (?).  So in this situation I
>> wouldn't expect a response from gdb developers.
>>
> https://sourceware.org/pipermail/gdb-patches/2020-December/174120.html
> 
> Someone needs to try PGO and LTO build with GDB.   "make check" in GDB
> can be used for PGO training.

GDB still has a lot of ODR violations, structures with the same name but different
definitions in different compile units.  Maybe it's OK in practice as these are largely
POD structs, I'm not sure, but I wouldn't trust an optimized LTO GDB build today,
until the ODR violations are sorted out.

Pedro Alves

RE: 2.36 Branch imminent

[Kyrylo Tkachov]

Hi Nick,

> -----Original Message-----
> From: Binutils <binutils-bounces@sourceware.org> On Behalf Of Nick Clifton
> via Binutils
> Sent: 14 December 2020 11:45
> To: binutils@sourceware.org
> Subject: 2.36 Branch imminent
> 
> Hi Guys,
> 
>    This is just to let you know that I plan on creating the 2.36 branch
>    over the weekend of Jan 9/10 with a view to completing the release over
>    the weekend of Jan 23.24.
> 
>    So if you have any new features or enhancements that you would like to
>    see in the next release, now is the time to submit them for review.

We've got an adjustment to some recent Arm architecture support we'd like to make for this release.
We're running some more validation currently and hope to post it soon.

Thanks,
Kyrill

> 
> Cheers
>    Nick