This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] MIPS: Opcode membership proposal
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 17 Jun 2013 16:18:45 +0100
- Subject: Re: [PATCH] MIPS: Opcode membership proposal
- References: <alpine dot DEB dot 1 dot 10 dot 1012181108290 dot 4142 at tp dot orcam dot me dot uk> <alpine dot DEB dot 1 dot 10 dot 1110311233290 dot 28657 at tp dot orcam dot me dot uk> <87obway4f5 dot fsf at firetop dot home> <alpine dot DEB dot 1 dot 10 dot 1208092012040 dot 20608 at tp dot orcam dot me dot uk> <20130617115141 dot GU21523 at bubble dot grove dot modra dot org>
On Mon, 17 Jun 2013, Alan Modra wrote:
> > +micromips-opc.lo: micromips-opc.c
> > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $<
> > +
> > +mips-opc.lo: mips-opc.c
> > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $<
> > +
> > +mips16-opc.lo: mips16-opc.c
> > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $<
> > +
>
> This patch resulted in no dependencies being generated for the mips
> opcode files, causing my regression tests to fail spectacularly from
> time to time. I finally got around to looking into the problem.
Oops, sorry about causing this regression -- I didn't notice it -- and
thanks for addressing it.
> * Makefile.am (mips-opc.lo): Add rules to create automatic
> dependency files. Pass archdefs.
> (micromips-opc.lo, mips16-opc.lo): Likewise.
> * Makefile.in: Regenerate.
>
> Index: opcodes/Makefile.am
> ===================================================================
> RCS file: /cvs/src/src/opcodes/Makefile.am,v
> retrieving revision 1.172
> diff -u -p -r1.172 Makefile.am
> --- opcodes/Makefile.am 6 Feb 2013 23:22:25 -0000 1.172
> +++ opcodes/Makefile.am 17 Jun 2013 11:06:21 -0000
> @@ -573,13 +573,43 @@ $(srcdir)/rl78-decode.c: @MAINT@ $(srcdi
> ./opc2c$(EXEEXT_FOR_BUILD) $(srcdir)/rl78-decode.opc > $(srcdir)/rl78-decode.c
>
> micromips-opc.lo: micromips-opc.c
> - $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $<
> +if am__fastdepCC
> + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) \
> + -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ @archdefs@ $<
> + mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
> +else
> +if AMDEP
> + source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
> + DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
> +endif
> + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ @archdefs@ $<
> +endif
>
> mips-opc.lo: mips-opc.c
> - $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $<
> +if am__fastdepCC
> + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) \
> + -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ @archdefs@ $<
> + mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
> +else
> +if AMDEP
> + source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
> + DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
> +endif
> + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ @archdefs@ $<
> +endif
>
> mips16-opc.lo: mips16-opc.c
> - $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $<
> +if am__fastdepCC
> + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) \
> + -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ @archdefs@ $<
> + mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
> +else
> +if AMDEP
> + source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
> + DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
> +endif
> + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ @archdefs@ $<
> +endif
>
> $(srcdir)/rx-decode.c: @MAINT@ $(srcdir)/rx-decode.opc opc2c$(EXEEXT_FOR_BUILD)
> ./opc2c$(EXEEXT_FOR_BUILD) $(srcdir)/rx-decode.opc > $(srcdir)/rx-decode.c
Hmm, this looks horribly tied to automake's internals to me and I am
afraid is bound to break as soon as automake maintainers decide to change
how the rules are generated. I know that this is going to be a pain, but
I wonder if it could be rewritten in a way that is portable across
automake versions, that is only relying on automake's published interface.
There is a way to request per-object compilation flags described in the
`Per-Object Flags Emulation' section of the automake manual. It involves
auxiliary convenience libraries (aka `ar' archives) and I used it
successfully in the past, albeit with program targets only rather than
libtool libraries. I do hope with little effort that can be adapted for
the latter case too.
This looks a bit convoluted, and frankly I'd prefer if automake supported
true per-object flags with no need to resort to hacks like this, but there
you go. The benefit would be no need to check the rules against generated
ones with each automake upgrade, that is less maintenance burden -- and
the maintenance of our autoconf scriptery has already proved tough even
without that.
Do you want me to check this alternative or would you prefer to do this
yourself?
Maciej