libopcode endian and subarch inconsistencies?

["Dr. David Alan Gilbert" <dave at treblig dot org>]

Hi,
  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:
  https://github.com/penguin42/pocketdisassembler/blob/master/jni/binutilsglue.c

(I'm using binutils-2.22 tweeked to build on Android)

1) Endianness
  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
the target.

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)

3) Arch/subarch/-M
  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.

Dave
-- 
 -----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   |_______/