This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding support for a new architecture to upstream binutils


Hi Ilja,

>  Currently we are considering pushing support for our architecture in binutils
> to upstream.

Thanks very much for thinking of doing this.

> Therefore I'd appreciate it if somebody of binutils maintainers
> could suggest the right sequence of steps (e.g. assigning copyright to FSF by
> my employer, obtaining an account for write access to binutils-gdb.git, ? ? ?)
> to be taken to make it possible to maintain E2K on 'master'.
 
The first step should be granting a copyright assignment to the FSF for any
patches that you submit.  (I am attaching the form that your company will need
to fill out and send to the FSF).

Once that is sorted out, you can submit the patches for review to this mailing
list.  Before doing so however, you should run a few sanity checks on the code
you are going to submit:

  * Does the patched code build and run correctly ?

  * Does the code in the patch(es) follow the GNU Coding Standard ?

  * Do the patches make any modifications to the generic parts
    of the binutils ?  If so, you should test to make sure that
    they do not break the building of the binutils for other targets.

  * Do the patches build on a 32-bit host (or build environment) as well
    as a 64-bit host ?

  * Have you patched readelf so that it will recognise and support the
    new architecture ?

When you submit your patches, it is helpful to bare the following in mind:

  * You do not need to include patches for auto-generated files
    (eg Makefile.in. configure, etc).

  * Including proposed ChangeLog entries is helpful, and ideally
    they should be presented as plain text, rather than context
    diffs.

  * If the patch set is large, consider compressing it, or breaking
    it down into several emails.

In addition, the following things help to make the patch set more attractive:

  * Updates to the assembler documentation files (gas/doc/*) and, if necessary
    the linker documentation.

  * Patches to the gas/NEWS and ld/NEWS files, mentioning that support is being
    added for the new architecture.

  * Tests.  Some new linker and assembler tests designed to check the behaviour
    of your new port would be very welcome.  You may also want to update the 
    binutils testsuite to allow for the new architecture.

  * An offer of maintainership for the new target.

Also - you will probably want to patch the top level config.sub file.
Please remember that this file is not actually maintained by the binutils
project, but instead has its own project/maintainer.

It may take some time for the patches to be reviewed, please be patient.  But
do also feel free to ping us if you think that we have forgotten the patches. :-)

You still will not have write permission on the repository at this point.  That
will come later after it is clear that you understand our processes and how the
binutils project works.  But I hope that this is enough for you to start the
process of becoming involved in the binutils.

Cheers
  Nick Clifton

Attachment: request-assign.future
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]