2.30 Branch Planned for Friday...

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
> Hi Guys,
>
>   I am planning to create the 2.30 branch on Friday.  You have been warned. :-)
>
> Cheers
>   Nick
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>).

  * 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
Reply | Threaded
Open this post in threaded view
|

Re: 2.30 Branch Planned for Friday...

Maciej W. Rozycki-2
In reply to this post by Nick Clifton
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
Reply | Threaded
Open this post in threaded view
|

Re: 2.30 Branch Planned for Friday...

H.J. Lu-30
In reply to this post by Nick Clifton
On Tue, Jan 9, 2018 at 2:41 AM, Nick Clifton <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: 2.30 Branch Planned for Friday...

H.J. Lu-30
On Thu, Jan 11, 2018 at 8:23 AM, Nick Clifton <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 2.30 Branch Planned for Friday...

H.J. Lu-30
In reply to this post by Nick Clifton
On Tue, Jan 9, 2018 at 2:41 AM, Nick Clifton <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: 2.30 Branch Planned for Friday...

H.J. Lu-30
On Thu, Jan 11, 2018 at 9:07 AM, Nick Clifton <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: 2.30 Branch Planned for Friday...

H.J. Lu-30
In reply to this post by Nick Clifton
On Tue, Jan 9, 2018 at 2:41 AM, Nick Clifton <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 2.30 Branch Planned for Friday...

Alan Modra-3
In reply to this post by H.J. Lu-30
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
Reply | Threaded
Open this post in threaded view
|

Re: 2.30 Branch Planned for Friday...

H.J. Lu-30
On Thu, Jan 11, 2018 at 6:15 PM, Alan Modra <[hidden email]> 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.