This is the mail archive of the
mailing list for the binutils project.
Re: libopcode endian and subarch inconsistencies?
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: "Dr. David Alan Gilbert" <dave at treblig dot org>
- Cc: binutils at sourceware dot org
- Date: Sat, 7 Jul 2012 20:42:55 +0100 (BST)
- Subject: Re: libopcode endian and subarch inconsistencies?
- References: <20120610163330.GB13988@gallifrey> <alpine.LFD.email@example.com> <20120616235437.GA3372@gallifrey>
On Sun, 17 Jun 2012, Dr. David Alan Gilbert wrote:
> > 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.
You're welcome to propose improvement. This is a large code base with
long history, people often cannot know all the deficiencies in all the
corners yet alone have resource to address them all. If something is of
particular concern to you, then you are warmly encouraged to address its
> > 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.'
Well, the comment may be a bit of overstatement, I have certainly used
the "binary" BFD as input both to `objdump' and `objcopy'. What the
author meant might have been it's certainly not easy if possible at all to
use this BFD as input to the linker.
But then mixing different input BFDs in linking has never worked
particularly reliably and I think by now it has to be considered
essentially not supported at all -- you need to `objcopy' any odd inputs
to the same object format that all the others use before feeding them all
to the linker. Or you can use GAS's .incbin pseudo-op nowadays -- it's a
relatively recent addition meant to address a shortcoming of `objcopy'
that has no means to set essential output BFD's file flags that are needed
in some configurations, e.g. a flag that marks file contents compatible
with PIC code.
A note along the lines of: "Its main use is for output, and its usability
for input is limited." -- or suchlike might make sense instead; again,
feel free to propose a patch if that bothers you.
And sorry for the high RTT -- my resources are limited too.