Re: libopcode endian and subarch inconsistencies?

["Maciej W. Rozycki" <macro at linux-mips dot org>]

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 
shortcomings.

> > 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.

  Maciej