Adding support for a new architecture to upstream binutils

[Nick Clifton]

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
-------------- next part --------------
Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]