Re: Your patch of August 2 to osf.h

[Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>]

Richard,

> I don't understand your patch to config/alpha/osf.h.
> 
> For me, it caused mips-tfile to be called with a .s file name that isn't
> otherwise used.  This is because the name is specified with %g so it doesn't
> match.  This is what is causing the debugging problem I've been looking for
> all week.
> 
> Can you explain what this is trying to fix?

I thought I'd been pretty explicit in the patch submission and the thread
that lead to it

	http://gcc.gnu.org/ml/java-patches/2001-q3/msg00164.html

but I'll summarize again:

When invoking

	gcj hello.java --main=hello -o hello

on Tru64 UNIX (and any system that uses %A/ASM_FINAL_SPEC), the following
sequence was run (stripped to just the commands and filenames):

	jc1 hello.java -o /tmp/ccGZzoJD.s
	as -o /tmp/ccg1Wo5y.o /tmp/ccGZzoJD.s
	mips-tfile -o /tmp/ccg1Wo5y.o /tmp/ccGZzoJD.s

	jvgenmain hello /tmp/ccqRoxCAmain.i
	cc1 /tmp/ccqRoxCAmain.i -o /tmp/ccWC8MIDmain.s
	as -o /tmp/ccWTm8HKmain.o /tmp/ccWC8MIDmain.s
	mips-tfile -o /tmp/ccg1Wo5y.o /tmp/ccGZzoJD.s

Since gcc/java/jvspec.c (jvgenmain_spec) uses %umain.i, %Umain.s etc. to
refer to the generated main class file, the second invocation of mips-tfile
uses wrong filenames (since ASM_FINAL_SPEC uses %g.s and cannot know
anything about the main.s suffix used) and dies a horrible death.

So my patch avoids this hackery by properly setting input_filename and
input_basename for the invocations of jvgenmain and following to <main
class name>main.c and adjusting jvgenmain_spec accordingly.

This is not enough, though: with just this change, I get

	jc1 hello.java -o /tmp/ccQGodTn.s
	as -o /tmp/cc69lVoH.o /tmp/ccQGodTn.s	
	mips-tfile -o /tmp/cc69lVoH.o /tmp/ccQGodTn.s

	jvgenmain hellomain /tmp/cc6ww9N2.i
	cc1 /tmp/cc6ww9N2.i -o /tmp/ccg5bc8p.s
	as -o /tmp/ccqvJeZN.o /tmp/ccg5bc8p.s
	mips-tfile -o /tmp/ccqvJeZN.o /tmp/ccQGodTn.s

Now the .s and .o files passed to the second invocation of mips-tfile don't
match (ASM_FINAL_SPEC using %g, the assembler file from the first as
invokation is passed, again breaking mips-tfile).

My solution was using %U.s instead of %g.s in ASM_FINAL_SPEC, to match the
uses of %u.i, %U.s etc. in jvgenmain_spec.  This works for the second
invocation and allowed me to pass bootstrap:

	jc1 hello.java -o /tmp/cc3PmRpD.s
	as -o /tmp/ccgUkdgI.o /tmp/cc3PmRpD.s
	mips-tfile -o /tmp/ccgUkdgI.o /tmp/cceesaQI.s

	jvgenmain hellomain /tmp/ccqfmx5J.i
	cc1 /tmp/ccqfmx5J.i -o /tmp/cceesaQI.s
	as -o /tmp/ccwZUmFg.o /tmp/cceesaQI.s
	mips-tfile -o /tmp/ccwZUmFg.o /tmp/cceesaQI.s

	collect2 -o hello /tmp/ccwZUmFg.o /tmp/ccgUkdgI.o

Unfortunately (and I hadn't noticed that), the use of %U.s causes a wrong
temporary file name to be passed to the *first* invocation of mips-tfile, a
file which doesn't exist at this point, so no debugging information is
written to the resulting object file.  I'll have to investigate why
mips-tfile silently seems to work in the presence of this nonexistant file;
I think it should fail when the passed assembler input file does not exist,
which is a wrong invocation.

I think I know now how to properly fix this: while using %g globally
instead of %u/%U in the jvgenmain_spec doesn't work (the second object file
would overwrite the first one), I think I can use %g.s instead of %U.s for
the second assembler input file and leaving osf.h's ASM_FINAL_SPEC alone.
A quick test seems to confirm that this always works, with and without
-save-temps, but I'll run a full bootstrap to make sure and submit a
revised patch when I'm done with this.

Getting this fixed for 3.0.2 seems pretty important, since this is the
final piece of the puzzle necessary to support gcj on Tru64 UNIX.  This had
worked in gcc 2.95, so this is a considerable regression, not just `trying
to fix some Java bug' as David put it.

I'm sorry about the trouble this has caused, but as I said no problem had
shown up anywhere during testing on three differnt platforms.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE