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.
> > 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
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.