Re: Jump visualization feature for objdump.

[Nick Clifton <nickc at redhat dot com>]

Hi Thomas,

> I have written a program that adds visualization of jumps inside a function to the output of objdump in the form of a post-processor
> 
> $ objdump -wzSCD binary | postprocessor
> 
> Is that feature interesting enough to include it into objdump,

Given that you already have the tool working, and that there appears to be 
another tool which provides a similar function, what would be the benefit
of incorporating your code into objdump ?  Ie if the stand alone tool is
already working, why make things more complicated by moving it into a
another code base, written in another language ?

As an alternative, how about adding the tool to the binutils as a separate
utility ?  There are already quite a few tools in the binutils collection,
so adding one more would not be a problem.  Well except for the following:

  * Is the tool x86/x86_64 specific ?

  The binutils cover a lot of different architectures and utilities it
  provides ought to be able to work with more than just one or two.

  (Actually multi-architecture support might be a good argument for
  integrating the code into objdump, since the target specific 
  disassembly functions in the opcodes library are the places where
  the knowledge of branch and jump instructions can be found).

  * Are you willing to contribute the code ?

  I guess this was implied by your original posting, but just to be clear
  contributing this code would mean filling out a copyright assignment to
  the FSF, and agreeing to have the code licenced under the GPLv3.

  * Are you willing to maintain the code ?

  The long term usability of any tool depends upon having maintainers
  to look after it, otherwise it just bit-rots away.  Being a maintainer
  for the code should not be an onerous job, but it does mean being
  willing to look at bug reports (specific to the feature) when they
  come in.


> but there is the question who will review a patch 

We will.  If you post a patch, or a patch series, to this list, it will be
reviewed.  Sometimes you may have to prod us a bit, but it will be reviewed
in the end.  Just please remember that we will need a copyright assignment 
in place before we can accept any code.


> (source code formatting, test cases ...)?

We (try to) follow the GNU Coding Standards:

  https://www.gnu.org/prep/standards/standards.html

Test cases are always a good idea, especially when adding a new feature.
When testing the tests, please make sure that you try using more than just 
a native toolchain.  Checking with a binutils configure with "--enable-targets=all"
for example is always worth doing.

Also for new features adding an entry to the appropriate NEWS file 
(binutils/NEWS in this case) is also required.

Patches should be accompanied by proposed entries for the ChangeLogs.
Ideally these would just be in plain text as context diffs almost
never apply cleanly.


> Please enlighten me with your answers.

Be at one with the universe.  

Oh, sorry, you meant enlighten you about the binutils patch submission 
process.  For that, see above.

Cheers
  Nick