Your commit 'MIPS/opcodes: Also set disassembler's ASE flags from ELF structures' broke GDB
Maciej W. Rozycki
Thu Dec 15 20:10:00 GMT 2016
On Thu, 15 Dec 2016, Antoine Tremblay wrote:
> > This failure is very odd to me, it looks like `opcodes/mips-dis.c' has
> > been included in the build of `libopcodes.a', however `bfd/elfxx-mips.c'
> > has *not* been included in the build of `libbfd.a'. Offhand I would
> > consider such a configuration broken, however maybe it is legitimate after
> > all. Has the opcodes/ subdirectory been configured differently from the
> > bfd/ subdirectory by any chance?
> I would look for:
> For all the configure options.
Thanks, `--build=i686-pc-linux-gnu' does trigger the problem for me as
well, and AFAICT the underlying issue is MIPS target support is not
included in BFD as it wants 64-bit BFD which is not enabled, however the
opcodes library is still built.
Obviously such a configuration is useless for `libopcodes' as you can't
get at all the target-specific particulars BFD would normally provide, so
not even the binutils/ subdirectory tools (excluded, by request, from this
configuration, though otherwise buildable) can correctly support the MIPS
target, let alone GDB.
So I think we need to arrange for the list of targets enabled for other
subdirectories to be driven somehow by BFD or, more likely, the top level.
I'm not sure offhand how to do this though. Cc-ing `binutils' for wider
I'll see if there is something I could do right away as a temporary
measure to unbreak 32-bit BFD configurations -- I would make the reference
from `opcodes/mips-dis.c' to `bfd_mips_elf_get_abiflags' weak, however
regrettably this does not appear supported, so maybe we'll require a dummy
stub or suchlike hackery if MIPS target support is enabled, but not
included in BFD.
Any better suggestions?
More information about the Gdb-patches