[Bug binutils/21507] objdump: Incorrect jump label in disassemble for arm object file

[msmttchr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21507

--- Comment #2 from Michele Sardo <msmttchr at gmail dot com> ---
Hi Nick,

Thanks for the clarification.
I agree with you that linker will resolve the relocation address to <g>,
thus no functional problem happens.

My problem was related to label printed by objdump and, in this case, the
bl instruction has argument 0 (relative to PC) which means that jump
address is dummy and will be patched with correct address after linking.
Nevertheless, I am still unclear why a label <f> is printed which is
misleading, in my opinion. I would have expected <f+offset> meaning that
the jump is to the next instruction (dummy jump).

In general, I noticed that every 'bl 0' instruction is printed with a label
associated with function at the address 0 of the section, that in the
particular example happen to be f itself.
Don't you think it would make more sense to print the relocation address
label ?
In any case, thanks again for your feedback.

Cheers

Michele

Il 22/mag/2017 01:16 PM, "nickc at redhat dot com" <sourceware-bugzilla@
sourceware.org> ha scritto:

> https://sourceware.org/bugzilla/show_bug.cgi?id=21507
>
> Nick Clifton <nickc at redhat dot com> changed:
>
>            What    |Removed                     |Added
> ------------------------------------------------------------
> ----------------
>              Status|UNCONFIRMED                 |RESOLVED
>                  CC|                            |nickc at redhat dot com
>          Resolution|---                         |INVALID
>
> --- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
> Hi Michele,
>
> >    4: f7ff fffe       bl      0 <f>    <<<<< This label should be <g>
> >>>>>>
>
> This is not a bug.  Try adding the "-r" option to the objdump command line
> in
> order to see why:
>
>   4:    f7ff fffe       bl      0 <f>
>                         4: R_ARM_THM_CALL       g
>
> So the branch at address 4 is currently going to address 0, which is where
> the
> "f" symbol is located.  But there is a relocation attached to that address
> which
> will change the branch to go to the address of symbol "g".
>
> If you link the program, the relocation will be processed and the
> instruction
> will be updated to point to the correct destination.
>
> Cheers
>   Nick
>
> --
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.