This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB 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: 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


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