This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb testing: get_compiler_info does not work with hp-ux aCC
On Tue, Jan 06, 2004 at 05:21:54AM -0500, Michael Chastain wrote:
> >From the "all the world is not gcc" department.
>
> I'm running the test suite on native hppa2.0w-hp-hpux11.11 with hp-ux
> ansi c and hp-ux aCC, and I'm getting results. Rather awful results but
> the test suite is running.
>
> When I use /opt/ansic/bin/cc, the symbol $hp_cc_compiler gets set
> properly. But when I use /opt/aCC/bin/aCC, the symbol $hp_aCC_compiler
> is never set.
>
> I dug into get_compiler_info and it's a mess. It calls different
> procedures on different targets. It calls "what" on the compiler
> executable, which is tough when my compiler executable is a shell script
> named "gcc" that chains to the real aCC. (I wrote a fake "what" and
> stuck it in my path). And it has its own private copy of the mechanism
> for looking up compiler executable names instead of just calling
> "gdb_compile" with the "preprocess" option.
>
> That last part is the part that doesn't work on hpux. It uses the C
> compiler for both "compiler.c" and "compiler.cc", no matter what I try.
> So hp_aCC_compiler is never set.
>
> I have some ideas for fixing this problem. My best idea is to run
> "[gdb_compile $ifile "" preprocess]", capture the result on standard
> output, and "eval" it. This replaces "capture the result in a file and
> source it". The command "gcc -E compiler.c -o file.o" does not comply
> with Single Unix Spec v3 and does not work on hp-ux; and the command
> "gcc -E compiler.c > file.o" involves an argument with dejagnu that I
> don't even want to start.
>
> Anyways. One side effect is that the foo.ci files might go away because
> get_compiler_info can do the job internally. This should not matter to
> the test scripts. But there are about six scripts that explicitly call
> "source ${binfile}.ci". They shouldn't do this anyways, because
> get_compiler_info already does it.
>
> So my plan is:
>
> write and test a patch to kill the bogus "source ${binfile}.ci"
> submit that patch for approval
> write and test a patch to rewrite get_compiler_info
> submit that patch for approval
>
> Of course, I could always have "get_compiler_info" create an empty
> file for compatibility. But since the references to ${binfile}.ci
> can all die right now, I'd rather just do that first.
>
> Does this sound okay?
Yes, absolutely!
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer