Question: What is the exact meaning of the different arrow shapes in objdump output?
Nick Clifton
nickc@redhat.com
Mon Jan 8 15:10:35 GMT 2024
Hi Anselm,
> I want to apologize for the pretentious message that I included underneath my original message.
> While I personally agree with the sentiment approximately,
> I have now realized that it is presumptuous and in bad form to claim to know better about the organization of a project.
> I should have qualified or omitted that segment.
No worries. I am always happy to try to answer people's questions
if I can.
> What I am having trouble understanding is that on some occasions, instead of a > as an arrowhead, an X is used.
> This only occurs in the rightmost column that the ASCII art appears in, it certainly does not indicate lines crossing.
> Usually lines crossing is indicated by simply prioritizing the vertical line (shown with a |).
>
> Additionally I occasionally see > being used in place of + for a line splitting.
>
> > Do you have an example of these effects that we could examine ?
>
> Here is an example of the mysterious sigils (the code snippet is produced by the -S flag,
> it is not necessary to see these shapes):
>
> 4017c2: | /-- 0f 85 05 00 00 00 jne 4017cd <parse_until+0x7d>
> 4017c8: | /-----------|-- e9 93 00 00 00 jmp 401860 <parse_until+0x110>
> for (; !(exit_loop = start >= end) && start - offset < len; start++) {
> 4017cd: | | /--------\-X e9 00 00 00 00 jmp 4017d2 <parse_until+0x82>
> 4017d2: | | >----------> 31 c0 xor %eax,%eax
> 4017d4: | | | 48 8b 4d b8 mov -0x48(%rbp),%rcx
OK, I think that this one is easy to explain. The X here indicates
that a branch both starts and finishes as this point. Whilst the >
indicates that rather than two lines crossing perpendicularly, you
instead have two lines, one asceding one descending that meet and join
into a horizontal line.
Hmm, that is not the clearest of explanations, is it ?
How about this, if the disassembly was allowed to duplicate lines, then
the visualization might look like this instead:
4017c2: | /-- 0f 85 05 00 00 00 jne 4017cd <parse_until+0x7d>
4017c8: | /-----------|-- e9 93 00 00 00 jmp 401860 <parse_until+0x110>
4017cd: | | \-> e9 00 00 00 00 jmp 4017d2 <parse_until+0x82>
4017d2: | | /----------> 31 c0 xor %eax,%eax
4017d4: | | | 48 8b 4d b8 mov -0x48(%rbp),%rcx
4017c2: | 0f 85 05 00 00 00 jne 4017cd <parse_until+0x7d>
4017c8: | /-------------- e9 93 00 00 00 jmp 401860 <parse_until+0x110>
4017cd: | | /----------- e9 00 00 00 00 jmp 4017d2 <parse_until+0x82>
4017d2: | | \----------> 31 c0 xor %eax,%eax
4017d4: | | 48 8b 4d b8 mov -0x48(%rbp),%rcx
So there is a jump from 4017c2 to 4017cd, plus a jump from 4017cd to 4017d2,
plus a jump from somewhere further on that ends up at 4017d2.
> Another, more likely interpretation I have just now (while writing this) come up with is that > is used to clarify
> that the destination is to the right of this join, and not above or below it. In particular, maybe it distinguishes as follows:
>
> /--- ORIGIN 1 | /--- ORIGIN 1
> | | |
> +--- ORIGIN 2 | >--> DESTINATION
> | | |
> \--> DESTINATION | \--- ORIGIN 2
>
> Do you know if this or the other interpretation is correct?
[I really should have read all of your email first, before starting my reply above...]
I think that this second interpretation is the correct one.
> If it is, this technically unnecessary distinction lends itself to an easy suggestion: Why not,
> to aid quick legibility further, include an arrow to indicate the direction on other crossings as well?
> I would suggest using a v to point down and a ^ to point up. For instance:
>
> /--- ORIGIN 1 | /--- DESTINATION
> | | ^
> +--- ORIGIN 2 | +--- ORIGIN 1
> v | |
> \--> DESTINATION | \--- ORIGIN 2
>
> Of course this would not be available in the case that consecutive lines would use the same arrow.
> In this case, perhaps replace the + with the v/^.
Well this would certainly be possible - if there is enough room for the direction
characters to be inserted. But it does also seem to making the visualization code
even more complicated than it already is. Given that the visualization is only
intended as an aid to understanding the disassembly and that arbitrarily complex
execution paths are always possible, I think that keeping the display simple is
probably for the best. But that is just my opiion. If you would care to create
a patch to implement the changes you have suggested I will be happy to review it.
Cheers
Nick
More information about the Binutils
mailing list