This is the mail archive of the
mailing list for the binutils project.
libopcode endian and subarch inconsistencies?
- From: "Dr. David Alan Gilbert" <dave at treblig dot org>
- To: binutils at sourceware dot org
- Date: Sun, 10 Jun 2012 17:33:30 +0100
- Subject: libopcode endian and subarch inconsistencies?
I've been writing a simple disassembler app (on android) with libopcode and
hit a couple of inconsistencies that I wondered what was the 'right' way
to solve them. In my app I've been taking a chunk of raw bytes
and throwing them to libopcode, having chosen 'binary' as the target;
see the code at:
(I'm using binutils-2.22 tweeked to build on Android)
There seem to be two separate places to set the endianness; one by
using the target and the other by using disassembler_info.endian;
the code in disassemble.c uses bfd_big_endian which pulls it from
2) The 'binary' target
The 'binary' target has it's flags set as BFD_ENDIAN_UNKNOWN;
but there again there is a comment that says it's only for
use as output not by input; so other than ignoring that
comment (as I did) - what's the right way to use libopcode
to disassemble from a byte stream?
(I took a copy of the xvec from binary and tweeked it's endian
flag - I know that's grim, better suggestions welcome - I think
I found somewhere similar in binutils)
Different architectures seem to prefer things passed in different
places with different styles. To give some examples:
Alpha - you have a subarch like alpha:ev6 to specify that version
ARM - subarch is xscale or armv3m (not arm:xscale to follow the alpha)
PPC - seems to prefer the variant to be passed by -M
It's a pity these are all different.
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ gro.gilbert @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/