Re: Your commit 'MIPS/opcodes: Also set disassembler's ASE flags from ELF structures' broke GDB

Re: Your commit 'MIPS/opcodes: Also set disassembler's ASE flags from ELF structures' broke GDB

[Maciej W. Rozycki]

On Thu, 15 Dec 2016, sergiodj+buildbot@sergiodj.net wrote:

> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> Buildslave:
> 	wildebeest-debian-jessie-i686
> 
> Full Build URL:
> 	<http://gdb-build.sergiodj.net/builders/Debian-i686-native-extended-gdbserver/builds/4691>
> 
> Commit(s) tested:
> 	5e7fc731f80e0d08385a05ad47dda332a49d9341
> 
> Author(s) (in the same order as the commits):
> 	Maciej W. Rozycki <macro@imgtec.com>
> 
> Subject:
> 	MIPS/opcodes: Also set disassembler's ASE flags from ELF structures
> 
> Testsuite log (gdb.sum and gdb.log) URL(s):
> 	<http://gdb-build.sergiodj.net/results/Debian-i686-native-extended-gdbserver/5e/5e7fc731f80e0d08385a05ad47dda332a49d9341/>
> 
> *** Failed to compiled GDB.  ***
> ============================

 How do I get the canonical build/host/target system and `configure' 
options used for this build?

 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?

 In any case I have tried building a couple of GDB configurations and all 
completed successfully.

  Maciej

Re: Your commit 'MIPS/opcodes: Also set disassembler's ASE flags from ELF structures' broke GDB

[Antoine Tremblay]

Maciej W. Rozycki writes:

> On Thu, 15 Dec 2016, sergiodj+buildbot@sergiodj.net wrote:
>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> 
>> Buildslave:
>> 	wildebeest-debian-jessie-i686
>> 
>> Full Build URL:
>> 	<http://gdb-build.sergiodj.net/builders/Debian-i686-native-extended-gdbserver/builds/4691>
>> 
>> Commit(s) tested:
>> 	5e7fc731f80e0d08385a05ad47dda332a49d9341
>> 
>> Author(s) (in the same order as the commits):
>> 	Maciej W. Rozycki <macro@imgtec.com>
>> 
>> Subject:
>> 	MIPS/opcodes: Also set disassembler's ASE flags from ELF structures
>> 
>> Testsuite log (gdb.sum and gdb.log) URL(s):
>> 	<http://gdb-build.sergiodj.net/results/Debian-i686-native-extended-gdbserver/5e/5e7fc731f80e0d08385a05ad47dda332a49d9341/>
>> 
>> *** Failed to compiled GDB.  ***
>> ============================
>
>  How do I get the canonical build/host/target system and `configure' 
> options used for this build?
>
>  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:
http://gdb-build.sergiodj.net/builders/Debian-i686-native-extended-gdbserver/builds/4691/steps/configure%20gdb/logs/stdio
and
http://gdb-build.sergiodj.net/builders/Debian-i686-native-extended-gdbserver/builds/4691/steps/compile%20gdb/logs/stdio

For all the configure options.

The configure run should host the host itself etc...

Re: Your commit 'MIPS/opcodes: Also set disassembler's ASE flags from ELF structures' broke GDB

[Yao Qi]

On 16-12-15 12:15:33, Maciej W. Rozycki wrote:
>
>  How do I get the canonical build/host/target system and `configure'
> options used for this build?
>
>  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?
>
>  In any case I have tried building a couple of GDB configurations and all
> completed successfully.
>

Hi, Maciej,
Did you build GDB on an i686-linux?  I can somehow reproduce it on
x86_64-linux, like this,

../opcodes/libopcodes.a(mips-dis.o): In function `set_default_mips_dis_options':
mips-dis.c:(.text+0x906): undefined reference to `bfd_mips_elf_get_abiflags'
collect2: error: ld returned 1 exit status
make: *** [gdb] Error 1

I configure with these options,

../binutils-gdb/configure --host=i686-pc-linux-gnu --disable-sim
--disable-binutils --disable-gprof --disa
ble-gold --disable-gas --disable-ld --enable-targets=all CFLAGS='-m32'
CXXFLAGS='-m32'

however, the build fails due to failing to find i686-pc-linux-gnu-ar.
I explicitly set AR=ar in make,
or modify libtool in several directories.  Finally, the build failed
on the error above.

-- 
Yao

Re: Your commit 'MIPS/opcodes: Also set disassembler's ASE flags from ELF structures' broke GDB

[Maciej W. Rozycki]

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:
> http://gdb-build.sergiodj.net/builders/Debian-i686-native-extended-gdbserver/builds/4691/steps/configure%20gdb/logs/stdio
> and
> http://gdb-build.sergiodj.net/builders/Debian-i686-native-extended-gdbserver/builds/4691/steps/compile%20gdb/logs/stdio
> 
> 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 
audience.

 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?

  Maciej

Re: Your commit 'MIPS/opcodes: Also set disassembler's ASE flags from ELF structures' broke GDB

[Alan Modra]

On Thu, Dec 15, 2016 at 08:09:42PM +0000, Maciej W. Rozycki wrote:
>  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.

Make the new ELF code in mips-dis.c conditional on BFD64?

-- 
Alan Modra
Australia Development Lab, IBM

Re: Your commit 'MIPS/opcodes: Also set disassembler's ASE flags from ELF structures' broke GDB

[Maciej W. Rozycki]

On Thu, 15 Dec 2016, Alan Modra wrote:

> >  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.
> 
> Make the new ELF code in mips-dis.c conditional on BFD64?

 Ah, that sounds like the right direction, although I'd rather exclude all 
MIPS target support (Score wants that too, based on their code) at the 
`configure' level.  It looks like we handle that already in ld/, by 
interpreting `want64' and pulling `../bfd/config.bfd' if required, so I'll 
see if I can import that into binutils/ as well.  Thanks for the hint!

  Maciej

Re: Your commit 'MIPS/opcodes: Also set disassembler's ASE flags from ELF structures' broke GDB

[Maciej W. Rozycki]

Hi Alan,

On Thu, 15 Dec 2016, Maciej W. Rozycki wrote:

> On Thu, 15 Dec 2016, Alan Modra wrote:
> 
> > >  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.
> > 
> > Make the new ELF code in mips-dis.c conditional on BFD64?
> 
>  Ah, that sounds like the right direction, although I'd rather exclude all 
> MIPS target support (Score wants that too, based on their code) at the 
> `configure' level.  It looks like we handle that already in ld/, by 
> interpreting `want64' and pulling `../bfd/config.bfd' if required, so I'll 
> see if I can import that into binutils/ as well.  Thanks for the hint!

 So I have followed your advice after all and made a minimal change (see 
commit 4df995c77118 ("MIPS/opcodes: Only call `bfd_mips_elf_get_abiflags' 
if BFD64")), because in such a configuration we may still have other MIPS 
BFD targets configured, such as ECOFF, so the disassembler has to remain 
fully functional for `objdump' at least.

  Maciej

Re: [PATCH, RFA] opcodes: Use autoconf to check for `bfd_mips_elf_get_abiflags' in BFD

[Joel Brobecker]

> Fix a regression introduced with commit 5e7fc731f80e ("MIPS/opcodes: 
> Also set disassembler's ASE flags from ELF structures"), further updated 
> with commit 4df995c77118 ("MIPS/opcodes: Also set disassembler's ASE 
> flags from ELF structures"), and use autoconf to check for the presence 
> of `bfd_mips_elf_get_abiflags' in BFD.
> 
> 	opcodes/
> 	* mips-dis.c (set_default_mips_dis_options): Use 
> 	HAVE_BFD_MIPS_ELF_GET_ABIFLAGS rather than BFD64 to guard the
> 	call to `bfd_mips_elf_get_abiflags'.
> 	* configure.ac: Check for `bfd_mips_elf_get_abiflags' in BFD.
> 	* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add `libbfd.la'.
> 	* aclocal.m4: Regenerate.
> 	* configure: Regenerate.
> 	* config.in: Regenerate.
> 	* Makefile.in: Regenerate.

Unfortunately, this change breaks the following scenario, used
by the src-release.sh script (used to produce our nightly source
packages, as well as our official releases). It also looks like
the change is in the binutils 2.28 branch as well, so if Tristan
uses that script to produce the release, it's not going to work.

The reason for the failure is the following change:

   -# development.sh is used to determine -Werror default.
   -CONFIG_STATUS_DEPENDENCIES = $(BFDDIR)/development.sh
   +# development.sh is used to determine -Werror default, libbfd.la is needed
   +# for function availability checks.
   +CONFIG_STATUS_DEPENDENCIES = $(BFDDIR)/development.sh ../bfd/libbfd.la

It causes the following scenario to fail:

   $ ./configure
   $ make configure-host
   $ make distclean

I'm pretty sure "./configure; make; make distclean" fails the same way,
but I haven't bothered trying.

The reason it fails is that "make distclean" depends on distclean-host
which then depends on:

    distclean-host: maybe-distclean-bfd
    distclean-host: maybe-distclean-opcodes

So, "make distclean" first does a "distclean" in bfd, followed by
a "distclean" in opcodes. The bfd distclean results in libbfd.la
being deleted. And because opcodes' Makefile now depends on it,
we get this error:

| make: Entering directory '/[...]/obj/opcodes'
| make: *** No rule to make target '../bfd/libbfd.la', needed by 'config.status'.  Stop.
| make: Leaving directory '/[...]/obj/opcodes'

I haven't been able to figure out how distclean depends on
CONFIG_STATUS_DEPENDENCIES, but I'm thiking it's probably one of
the implicit dependencies. But looking at the automake documentation
about CONFIG_STATUS_DEPENDENCIES, it looks like this is meant to be
listing the depedencies to re-generate the Makefile. It don't think
libbfd.a/la is in this category, is it?

I don't have a solution. Perhaps one way to approach the problem
might be to distclean in the reverse order to configure/build?
If opcodes depends on bfd and we distclean bfd, then there might
indeed be some dependencies missing.

We need a solution fairly quickly...

-- 
Joel

Re: [PATCH, RFA] opcodes: Use autoconf to check for `bfd_mips_elf_get_abiflags' in BFD

[Alan Modra]

On Tue, Dec 27, 2016 at 02:08:41PM +0400, Joel Brobecker wrote:
> The reason for the failure is the following change:
> 
>    -# development.sh is used to determine -Werror default.
>    -CONFIG_STATUS_DEPENDENCIES = $(BFDDIR)/development.sh
>    +# development.sh is used to determine -Werror default, libbfd.la is needed
>    +# for function availability checks.
>    +CONFIG_STATUS_DEPENDENCIES = $(BFDDIR)/development.sh ../bfd/libbfd.la
> 
> It causes the following scenario to fail:
> 
>    $ ./configure
>    $ make configure-host
>    $ make distclean
> 
> I'm pretty sure "./configure; make; make distclean" fails the same way,

Yes, it does.  So let's revert that patch and simply modify the make
rule for mips-dis.lo (ie. provide it to overrided the default automake
rule) to test whether elfxx-mips.c has been compiled in.  The top
level makefile already has the required directory dependencies. 

	* configure.ac: Revert 2016-12-23.
	* Makefile.am: Likewise.
	(MIPS_DEFS): Define.
	(mips-dis.lo): Add rule.
	* Makefile.in: Regenerate.
	* aclocal.m4: Regenerate.
	* config.in: Regenerate.
	* configure: Regenerate.

Diff below excludes the reversion.

diff --git a/opcodes/Makefile.am b/opcodes/Makefile.am
index 3e9dc54..a441feb 100644
--- a/opcodes/Makefile.am
+++ b/opcodes/Makefile.am
@@ -610,6 +609,19 @@ $(srcdir)/z8k-opc.h: @MAINT@ z8kgen$(EXEEXT_FOR_BUILD)
 
 z8k-dis.lo: $(srcdir)/z8k-opc.h
 
+MIPS_DEFS=`case \`cat ../bfd/ofiles\` in *elfxx-mips*) echo "-DHAVE_BFD_MIPS_ELF_GET_ABIFLAGS=1";; esac`
+mips-dis.lo: mips-dis.c
+if am__fastdepCC
+	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $(MIPS_DEFS) $<
+	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
+else
+if AMDEP
+	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
+	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
+endif
+	$(LTCOMPILE) -c -o $@ $(MIPS_DEFS) $<
+endif
+
 sh-dis.lo: sh-dis.c
 if am__fastdepCC
 	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ @archdefs@ $(srcdir)/sh-dis.c

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH, RFA] opcodes: Use autoconf to check for `bfd_mips_elf_get_abiflags' in BFD

[Joel Brobecker]

> Yes, it does.  So let's revert that patch and simply modify the make
> rule for mips-dis.lo (ie. provide it to overrided the default automake
> rule) to test whether elfxx-mips.c has been compiled in.  The top
> level makefile already has the required directory dependencies. 
> 
> 	* configure.ac: Revert 2016-12-23.
> 	* Makefile.am: Likewise.
> 	(MIPS_DEFS): Define.
> 	(mips-dis.lo): Add rule.
> 	* Makefile.in: Regenerate.
> 	* aclocal.m4: Regenerate.
> 	* config.in: Regenerate.
> 	* configure: Regenerate.

Thanks, Alan!

-- 
Joel

Re: [PATCH, RFA] opcodes: Use autoconf to check for `bfd_mips_elf_get_abiflags' in BFD

[Maciej W. Rozycki]

On Tue, 27 Dec 2016, Joel Brobecker wrote:

> I haven't been able to figure out how distclean depends on
> CONFIG_STATUS_DEPENDENCIES, but I'm thiking it's probably one of
> the implicit dependencies. But looking at the automake documentation
> about CONFIG_STATUS_DEPENDENCIES, it looks like this is meant to be
> listing the depedencies to re-generate the Makefile. It don't think
> libbfd.a/la is in this category, is it?

 It is not, however `config.status' itself is, and with the change I made 
it depended on `libbfd.la' because one of the autoconf tests did.  So if 
e.g. you ran `configure' in opcodes/ first (for whatever reason), then 
running `make' there would run `configure' and then `make' in bfd/ because 
of other dependencies, however `config.status' would not get updated in 
opcodes/ afterwards, before its targets were made.

> I don't have a solution. Perhaps one way to approach the problem
> might be to distclean in the reverse order to configure/build?
> If opcodes depends on bfd and we distclean bfd, then there might
> indeed be some dependencies missing.
> 
> We need a solution fairly quickly...

 Thanks, Alan, for sorting this out in my absence!

 TBH I think `distclean' shouldn't really depend on non-phony targets in 
the first place, or at least it should ignore errors in their re-creation, 
but there you go.  With releases upcoming it's no time now to revamp our 
build system!

 Happy New Year!

  Maciej