https://sourceware.org/bugzilla/show_bug.cgi?id=30979
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com
--- Comment #8 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Bruno Haible from comment #4)
> 3b: e8 00 00 00 00 call 40 <fesetround>
> 3c: R_X86_64_PLT32 __stack_chk_fail-0x4
>
> which is not satisfactory, because
> - "40 <fesetround>" is still nonsense.
> - The -0x4 gives a misleading impression as well.
The reason for this behaviour is that the disassembler prefers accuracy over
readability. So for example the "40 <fesetround>" is accurate. That is where
the call instruction at address 3b will go. That is unless a relocation is
applied to the instruction. But in the object file, the relocations are
present, not applied.
The "__stack_chk_fail-0x4" is also accurate, as this is the address that is
stored in the relocation. The fact that the address is biased by -0x4 is
because of the nature of the call instruction, which automatically adds 0x4 to
whatever offset is stored inside it.
Of course the disassembler could produce more human readable output, as you
suggest. But this would be this would be disingenuous - the output would no
longer accurately reflect the input - and prone to errors when the "obvious
human readable" version is in fact wrong due to whatever circumstances may
apply.
In the end, it comes down to the fact that if you are reading the output of the
disassembler, you are expected to know the instruction set, and the
relocations, and be able to perceive the intent of the code without the
disassembler holding your hand.
Having said all of that however, I am not going to object if you wish to submit
a patch to add an option that changes the disassembler's behaviour. Perhaps
other people would prefer your version of the output too. But I am not going
to write such a patch, as for me, I do not think that it is needed.
--
You are receiving this mail because:
You are on the CC list for the bug.
