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