Jump visualization feature for objdump.

[Thomas Troeger]

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

In the current form the tool only checks if the target address is inside
the same function and then adds a line between the two addresses. So
there is still work to do because I only want a line for instructions
that branch or jump. I figure that inside objdump itself that information
is available in some form, so it feels like a natural choice to integrate
it. I might need some help on how to check for jump instructions for a
given ISA, but I will try to figure it out on my own first.

I checked the code for objdump and think it can be done with a
reasonable amount of work. The main drawback is that I need to port it
to C, but the code is not that complicated or large and already works
with both std::list or std::vector, so I could use the list variant of
the algorithm and replace this container with some pointer to next
inside the appropriate struct to get similar functionality.

The other motivation is that it may be useful to the users of
objdump, in the end that's why I've written it. It might work as a
separate tool also (after all it does for me), but I would still have
to port it to C, right? Or is C++ an option for binutils?

> 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).

s. above. In the current form it only extracts address references so it
*should* work on all architectures. I tested it on both x86-64 and
ARM64.

>
>   * Are you willing to contribute the code ?

Of course.

>   * 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.

As long as it does not eat a substantial amount of time I see no problem there.

Cheers,
Thomas.