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:
> and
> 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 mailing list