This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] MIPS: Opcode membership proposal


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]