This is the mail archive of the
mailing list for the binutils project.
Re: libopcode endian and subarch inconsistencies?
* Maciej W. Rozycki (email@example.com) wrote:
> On Sun, 10 Jun 2012, Dr. David Alan Gilbert wrote:
Thanks for the reply.
> > 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?
> See how `objdump' drives opcodes -- it has -EB/-EL options to select the
> endianness regardless of the target chosen.
Yes, I think that might have been where I originally saw the trick I used;
from the objdump code:
if (endian != BFD_ENDIAN_UNKNOWN)
struct bfd_target *xvec;
xvec = (struct bfd_target *) xmalloc (sizeof (struct bfd_target));
memcpy (xvec, abfd->xvec, sizeof (struct bfd_target));
xvec->byteorder = endian;
abfd->xvec = xvec;
and then later:
if (bfd_big_endian (abfd))
disasm_info.display_endian = disasm_info.endian = BFD_ENDIAN_BIG;
else if (bfd_little_endian (abfd))
disasm_info.display_endian = disasm_info.endian = BFD_ENDIAN_LITTLE;
My point really is that memcpying and tweeking xvec feels a horrible
hack, especially when you also have disasm_info.endian which feels
like the place you'd expect to set the endianness because it exists.
I'd think that there should only be one of them that a caller to libopcode
should have to set.
> It can disassemble from the
> "binary" target just fine.
Yes, my point about 'binary' was that there is the comment in binary.c:
'It may only be used for output, not input.'
-----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 |_______/