Questions on the submission of new patch in the binutils

Questions on the submission of new patch in the binutils

[Virendra Kumar Pathak]

Hi Binutils Group,

We are working on a new armv8.1-a aarch64 based server processor.
We have a simple patch to introduce basic "-mcpu" flag for this
processor in the binutils, and thus are interested to upstream it.
Unfortunately, we do not have any prior experience in upstreaming &
working with binutils group.

Could you kindly help us by answering below questions. Or point me to
the appropriate links/documentation where such information is present.

[Questions]

1. What would be the appropriate branch to upstream this new patch? I
see there are three major active branches:  master, gdb-7.11-branch
and binutils-2_26-branch.
     [https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git]

2. What are the formal tests that needs to be done before proposing a
patch to binutils?

3. Due to active development in binutils, the development branches
move very fast.
    What if the branch, over which my patch is based, moves forward
after the submission of my patch for the review?
    Do I need to rebase it again?

Thanks in advance for your time and patience.

-- 
with regards,
Virendra Kumar Pathak

Re: Questions on the submission of new patch in the binutils

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]

Hi Virendra,

  Thanks very much for your interest in contributing your work.

> Could you kindly help us by answering below questions. Or point me to
> the appropriate links/documentation where such information is present.

  Before you start you need to be aware of the FSF Copyright assignment
  policy.  Patches submitted to FSF projects, including the binutils,
  need to be covered by an FSF Copyright assignment:

http://www.fsf.org/licensing/assigning.html

  If you do not have a copyright assignment in place already then you 
  can apply for one by filling out the attached form and sending it off
  to the FSF.


> 1. What would be the appropriate branch to upstream this new patch? I
> see there are three major active branches:  master, gdb-7.11-branch
> and binutils-2_26-branch.

  master.

  The 2_26 branch is for the current 2.26 release.  It is meant to be
  a stable branch and so it is not suitable for the addition of new
  features.  The gdb-7_11 branch is for the GDB project, so you would
  need to have permission from the GDB branch manager to commit changes
  there.

  (The binutils git repository is shared between the binutils and gdb
  projects).


> 2. What are the formal tests that needs to be done before proposing a
>    patch to binutils?

  You should make sure that the patched sources build.  Also you should
  make sure that the gas, ld, binutils (and possibly gold) testsuites do
  not show any regressions for the appropriate target(s).  If you are adding
  a new feature then you should also, if possible, contribute one or more
  additions to the testsuite(s) that check that the new feature works.

  The targets to test depend upon the patch.  If it only affects ARM specific
  files, for example, then you would only need to test a set of ARM targets.
  But if it affects some generic code, then you would need to test a larger
  range of targets, including at least the x86 and x86_64 targets.  (I 
  currently test ~ 130 targets each day, just looking for regressions).

  With regard to ARM specific changes you should make sure that you check
  an arm-eabi target, plus arm-wince-pe, arm-nto and arm-nacl.



> 3. Due to active development in binutils, the development branches
> move very fast.
>     What if the branch, over which my patch is based, moves forward
> after the submission of my patch for the review?
>     Do I need to rebase it again?

  No and yes. :-)  If the patch is reviewed in a timely manor, then it
  will probably still apply.  Sometimes however patches are not reviewed
  quickly - were are working on this project on a volunteer basis after
  all - so you may find that you want to resubmit a patch, or maybe ping
  the maintainers asking for a review.  In cases like this, where some
  time has elapsed, it is helpful if you can regenerate the patch when
  asking/prompting for a review.

  Also, if you are asking for someone to apply the patch on your behalf,
  because you may not have write permission on the repository, then they
  may ask you to regenerate the patch, if they encounter problems when
  they try to apply it.


  I hope that this information helps and we look forward to your future 
  contributions.

Cheers
  Nick


[-- Attachment #2: request-assign.future --]
[-- Type: text/plain, Size: 965 bytes --]

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