2.30 Branch Planned for Friday...

2.30 Branch Planned for Friday...

[Nick Clifton]

Hi Guys,

  I am planning to create the 2.30 branch on Friday.  You have been warned. :-)

Cheers
  Nick

Re: 2.30 Branch Planned for Friday...

[Francois H. Theron]

Hi

We have a patch ready to add support for a new target (NFP, Netronome
Flow Processor). We believe it is in good shape and would like to hear
if we would still be able to get it accepted in the next release.

Regards
Francois


On 9 January 2018 at 12:41, Nick Clifton <nickc@redhat.com> wrote:
> Hi Guys,
>
>   I am planning to create the 2.30 branch on Friday.  You have been warned. :-)
>
> Cheers
>   Nick

Re: 2.30 Branch Planned for Friday...

[Nick Clifton]

Hi Francois,

> We have a patch ready to add support for a new target (NFP, Netronome
> Flow Processor). We believe it is in good shape and would like to hear
> if we would still be able to get it accepted in the next release.

It is a bit close to the deadline, but there is still a chance.  But in
order for the port to make it in, you should bare these things in mind:

  * You must have an FSF copyright assignment for the binutils in place.

  * The code in the patch should follow the GNU Coding Standards.

  * The patch should include some additions to the testsuites to make
    sure that it is working, and continues to work in the future.

  * The patch should include some updates to the documentation 
    describing any features, options or quirks specific to the NFP.

  * The patch should build without any errors and hopefully show
    no failures when the gas, ld and binutils testsuites are run.

  * You will probably need to patch the top level config.sub file
    in order to add an entry for the NFP.  Unfortunately this file
    is not part of the binutils project, so you will need to submit
    a separate patch (to <config-patches@gnu.org>).

  * Ideally someone should be willing to volunteer to be a maintainer
    of the port, so that it does not bit-rot away over time.

Cheers
  Nick

Re: 2.30 Branch Planned for Friday...

[Maciej W. Rozycki]

Nick,

>   I am planning to create the 2.30 branch on Friday.  You have been 
> warned. :-)

 FYI, I have just discovered we have a large number of regressions across 
MIPS targets, mainly various `mips*-elf' ones, compared to our tree as at 
Nov 30th.  I'll try to triage and bisect them in the coming days, however 
please be aware that regrettably I cannot fix anything due to my company 
copyright assignment still remaining in a limbo state on the FSF side 
after the recent transition from Imagination to the reincarnated MIPS 
company.

  Maciej

Re: 2.30 Branch Planned for Friday...

[H.J. Lu]

On Tue, Jan 9, 2018 at 2:41 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Guys,
>
>   I am planning to create the 2.30 branch on Friday.  You have been warned. :-)
>

I'd like to get my "-z separate-code" patch set:

https://sourceware.org/ml/binutils/2018-01/msg00158.html

into 2.30.

Thanks.
-- 
H.J.

Re: 2.30 Branch Planned for Friday...

[Nick Clifton]

Hi H.J.

> I'd like to get my "-z separate-code" patch set:
> 
> https://sourceware.org/ml/binutils/2018-01/msg00158.html

If it gets approved by Alan Modra then that is fine.

Cheers
  Nick

Re: 2.30 Branch Planned for Friday...

[H.J. Lu]

On Thu, Jan 11, 2018 at 8:23 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi H.J.
>
>> I'd like to get my "-z separate-code" patch set:
>>
>> https://sourceware.org/ml/binutils/2018-01/msg00158.html
>
> If it gets approved by Alan Modra then that is fine.
>

Hi Alan,

Can you take a look at my patches on users/hjl/pr22393/master branch at

https://sourceware.org/git/?p=binutils-gdb.git;a=summary

They should have addressed concerns you raise at:

https://sourceware.org/ml/binutils/2018-01/msg00132.html

Thanks.

-- 
H.J.

Re: 2.30 Branch Planned for Friday...

[H.J. Lu]

On Tue, Jan 9, 2018 at 2:41 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Guys,
>
>   I am planning to create the 2.30 branch on Friday.  You have been warned. :-)

I'd like to fix:

https://sourceware.org/bugzilla/show_bug.cgi?id=22677

with

https://sourceware.org/ml/binutils/2018-01/msg00173.html

-- 
H.J.

Re: 2.30 Branch Planned for Friday...

[Nick Clifton]

Hi H.J.

> I'd like to fix:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=22677
> 
> with
> 
> https://sourceware.org/ml/binutils/2018-01/msg00173.html

Ha!  Great minds think alike. :-)

I have just posted a very similar patch to the PR, although I
think that we do not need any special case code for the PRE_INIT_ARRAY
section as that is handled by a KEEP directive in the linker script.
Hmm - unless there can be PREINIT_ARRAY sections whose name is not
.preinit_array.  Which I suppose is possible...

Would you mind extending your patch to include this scenario ?  
I think that with that change in place I would be happy to approve it.

Cheers
  Nick

Re: 2.30 Branch Planned for Friday...

[H.J. Lu]

On Thu, Jan 11, 2018 at 9:07 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi H.J.
>
>> I'd like to fix:
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=22677
>>
>> with
>>
>> https://sourceware.org/ml/binutils/2018-01/msg00173.html
>
> Ha!  Great minds think alike. :-)
>
> I have just posted a very similar patch to the PR, although I
> think that we do not need any special case code for the PRE_INIT_ARRAY
> section as that is handled by a KEEP directive in the linker script.
> Hmm - unless there can be PREINIT_ARRAY sections whose name is not
> .preinit_array.  Which I suppose is possible...

Exactly.   Linker script for ld -r has:

 .preinit_array   0 :
  {
    KEEP (*(.preinit_array))
  }

It doesn't cover

 .section .preinit_array.01000,"aw",%preinit_array
 .p2align 2
 .word 0

in my testcase in my patch.

> Would you mind extending your patch to include this scenario ?
> I think that with that change in place I would be happy to approve it.
>

My patch does cover that with a testcase :-).


-- 
H.J.

Re: 2.30 Branch Planned for Friday...

[Nick Clifton]

Hi H.J.

> My patch does cover that with a testcase :-).

Doh! I need better spectacles.

Patch approved - please apply.

Cheers
  Nick

Re: 2.30 Branch Planned for Friday...

[H.J. Lu]

On Tue, Jan 9, 2018 at 2:41 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Guys,
>
>   I am planning to create the 2.30 branch on Friday.  You have been warned. :-)

I'd like to fix

https://sourceware.org/bugzilla/show_bug.cgi?id=22649

with

https://sourceware.org/ml/binutils/2018-01/msg00181.html


-- 
H.J.

Re: 2.30 Branch Planned for Friday...

[Alan Modra]

On Thu, Jan 11, 2018 at 08:30:47AM -0800, H.J. Lu wrote:
> Can you take a look at my patches on users/hjl/pr22393/master branch at

Looks good to me.  I was going to do something similar but was trying
to sort out nacl SEPARATE_CODE first, but that can go in later as a
refinement.

I notice you have used MAXPAGESIZE for the alignment.  That is the
safest way to go, but will result in large binaries.  Deliberate
choice?

-- 
Alan Modra
Australia Development Lab, IBM

Re: 2.30 Branch Planned for Friday...

[H.J. Lu]

On Thu, Jan 11, 2018 at 6:15 PM, Alan Modra <amodra@gmail.com> wrote:
> On Thu, Jan 11, 2018 at 08:30:47AM -0800, H.J. Lu wrote:
>> Can you take a look at my patches on users/hjl/pr22393/master branch at
>
> Looks good to me.  I was going to do something similar but was trying
> to sort out nacl SEPARATE_CODE first, but that can go in later as a
> refinement.
>
> I notice you have used MAXPAGESIZE for the alignment.  That is the
> safest way to go, but will result in large binaries.  Deliberate
> choice?

Yes, it is done on purpose.  Otherwise, we need to set a larger
common-page-size if we want a larger page.

I do have 2 followup patches.

1.  Default max-page-size to common-page-size if -z separate-page-size
is used.
2.  Pad code segment with NOPs, instead zeros.

I hope I can get them into 2.30.

-- 
H.J.

Re: 2.30 Branch Planned for Friday...

[Maciej W. Rozycki]

On Wed, 10 Jan 2018, Maciej W. Rozycki wrote:

> >   I am planning to create the 2.30 branch on Friday.  You have been 
> > warned. :-)
> 
>  FYI, I have just discovered we have a large number of regressions across 
> MIPS targets, mainly various `mips*-elf' ones, compared to our tree as at 
> Nov 30th.  I'll try to triage and bisect them in the coming days, however 
> please be aware that regrettably I cannot fix anything due to my company 
> copyright assignment still remaining in a limbo state on the FSF side 
> after the recent transition from Imagination to the reincarnated MIPS 
> company.

 All the regressions/new failures except from:

FAIL: Build pr22649-2c.so
FAIL: Build pr22649-2d.so

are the result of commit 05a5feafdd38 ("Rewrite check_shared_lib_support") 
and are either test framework bugs or preexisting toolchain problems.  
Therefore I do not consider them 2.30 blockers and neither I am going to 
address them on the 2.30 branch; we'll have to live with them.

 I did address some of them locally already and I will try to sort that 
out on the master branch soon.  I have also expanded my test coverage by a 
couple of further MIPS targets, and addressed some obvious problems with 
them.  We may want to obsolete some of them sometime, however I see no 
need to rush here, especially if they continue working and given that 
properly extracting dead code can be more problematic than maintaining odd 
targets using it.

 I have also started cleaning up the test framework for correct support of 
some less usual MIPS targets, in particular those that deliberately do not 
support some emulations like for the o32 ABI or use vectors different from 
the usual ones which the test framework assumes are also present.  It will 
hopefully eventually clean up most failures we see for those targets.

  Maciej