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.
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. :-)
> 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.
> 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
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.
> 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
> I notice you have used MAXPAGESIZE for the alignment. That is the
> safest way to go, but will result in large binaries. Deliberate
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
2. Pad code segment with NOPs, instead zeros.