Re: Problems with dejagnu and c++ tests...

Re: Problems with dejagnu and c++ tests...

[Michael Elizabeth Chastain]

ac> (aren't we trying to delete gcc_compiled? :-)

Yes.  When the last reference to gcc_compiled goes away,
then we can remove the code that initializes it.

ac> Something based on CPP would be more robust, and avoid assumptions such 
ac> as the target has output and can correctly compile / execute code. 
ac> Consider what happens when trying to bring up a new GDB+GCC+....

We're running the test suite.  If gdb_compile does not work,
or the resulting executables cannot be run, then the test script
cannot run its tests anyways.

Just look at the code in gdb.cp/ambiguous.exp or anywhere else that
calls get_compiler_info:

  if [get_compiler_info ${binfile} "c++"] {
      return -1;
  }
  ...
  if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug c++}] != "" } {
    gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }
  ...
  gdb_exit
  gdb_start
  gdb_reinitialize_dir $srcdir/$subdir
  gdb_load ${binfile}

get_compiler_info is always followed by gdb_compile.
get_compiler_info should use the same compiler as gdb_compile.

Also, read the comments at the beginning of get_compiler_info.
'Something based on CPP' has a lot of problems with any implementation
that I can think of.

gdb 6.0 had four different implementations:

  most targets with c
  most targets with c++
  hpux|irix with c
  hpux|irix with c++

"most targets with c" and "most targets with c++" depended on
a non-standard gcc extension, which is why the hpux|irix targets
needed special cases.

hpux|irix with c++ *did not work*.  It used about 100 lines of special
code but did not even use the same compiler as gdb_compile, so it
invoked a different compiler and set the variables wrong.
That's what drove me to rewrite get_compiler_info in the first place.

Michael C

Re: Problems with dejagnu and c++ tests...

[Andrew Cagney]

> ac> Something based on CPP would be more robust, and avoid assumptions such 
> ac> as the target has output and can correctly compile / execute code. 
> ac> Consider what happens when trying to bring up a new GDB+GCC+....
> 
> We're running the test suite.  If gdb_compile does not work,
> or the resulting executables cannot be run, then the test script
> cannot run its tests anyways.

Which would mean that a GCC code-gen bug in malloc, or printf would 
block all ability to run the testsuite :-(  We need to avoid making the 
testsuite fragile.

Andrew

Re: Problems with dejagnu and c++ tests...

[Daniel Jacobowitz]

On Wed, Feb 04, 2004 at 06:50:29PM -0500, Michael Chastain wrote:
> drow> I think assuming we can compile and run is fine.  Output is an
> drow> absolutely no-show, however.  Take a look at how many of our supported
> drow> targets don't have any kind of remote file I/O capability - gdbserver,
> drow> for one.
> 
> Argh.  Okay.  Although I'm not talking about file I/O, I'm talking
> about write to stdout.  There are 58 *.[Cc] files with printf already.

Yes.  They don't work on many remote setups, either :)  Most of them
are guarded by gdb,noinferiorio.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Problems with dejagnu and c++ tests...

[Michael Elizabeth Chastain]

drow> I think assuming we can compile and run is fine.  Output is an
drow> absolutely no-show, however.  Take a look at how many of our supported
drow> targets don't have any kind of remote file I/O capability - gdbserver,
drow> for one.

Argh.  Okay.  Although I'm not talking about file I/O, I'm talking
about write to stdout.  There are 58 *.[Cc] files with printf already.

With the pre-process strategy, I think I have to hit this code:

  # Source the output.
  foreach cppline ...
  {
    next if $cppline =~ m/^#/;
    next if $cppline =~ m/^\s*$/;
    eval { $cppline };
  }

(Oops, I wrote that in Perl!)

These need some more checks before eval'ing cppline.  The only lines I want
to eval are 'set' commands; anything else can be treated as a compiler
diagnostic.  Forward it with 'verbose -log' and set the compiler
variables to an "unknown" state.  That would fix Joel's case.

Michael C

Re: Problems with dejagnu and c++ tests...

[Daniel Jacobowitz]

On Wed, Feb 04, 2004 at 06:03:42PM -0500, Michael Chastain wrote:
> > Which would mean that a GCC code-gen bug in malloc, or printf would 
> > block all ability to run the testsuite :-(
> 
> Ah, I see.
> 
> So don't use printf ... use write(2).

I think assuming we can compile and run is fine.  Output is an
absolutely no-show, however.  Take a look at how many of our supported
targets don't have any kind of remote file I/O capability - gdbserver,
for one.

> There are 310 *.exp files in the test suite.
> 84 of them use get_compiler_info.
> 47 of them actually use one of the tests:
>   test_compiler_info
>   gcc_compiled, hp_aCC_compiler, hp_cc_compiler
>   signed_keyword_not_used
> 
> (Hmmm, I feel an obvious change coming to 37 files).
> 
> 84 out of 310 is not even close to "all".
> 
> If I did the compiler checks up front instead of inside get_compiler_info,
> then the compiler checks would have to do something nice if
> gdb_compile failed, such as leave compiler_info set to "no-compiler"
> for the language that failed.

And we'd save duplicating the tests 84 times...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Problems with dejagnu and c++ tests...

[Michael Elizabeth Chastain]

> Which would mean that a GCC code-gen bug in malloc, or printf would 
> block all ability to run the testsuite :-(

Ah, I see.

So don't use printf ... use write(2).

There are 310 *.exp files in the test suite.
84 of them use get_compiler_info.
47 of them actually use one of the tests:
  test_compiler_info
  gcc_compiled, hp_aCC_compiler, hp_cc_compiler
  signed_keyword_not_used

(Hmmm, I feel an obvious change coming to 37 files).

84 out of 310 is not even close to "all".

If I did the compiler checks up front instead of inside get_compiler_info,
then the compiler checks would have to do something nice if
gdb_compile failed, such as leave compiler_info set to "no-compiler"
for the language that failed.

Michael C

Re: Problems with dejagnu and c++ tests...

[Andrew Cagney]

> Well, you could just add "return 1" to skip_cplus_tests on that system.
> 
> But in the long run, get_compiler_info needs to be smarter.
> (Really, default_target_compile needs to have a better interface,
> but we can't touch that).
> 
> Perhaps we should just kill get_compiler_info and add some more
> code to initialization.  Have it compile and run two test programs,
> one in C, and one in C++.  Like this:
> 
>   #include <stdio.h>
>   int main ()
>   {
>   #if defined(__GNUC__)
>     printf ("set compiler_info gcc-%d-%d\n", __GNUC__, __GNUC__MINOR__);
>     printf ("set gcc_compiled %d\n", __GNUC__);
>   else
>     printf ("set gcc_compiled 0\n")
>   #endif
>   }

(aren't we trying to delete gcc_compiled? :-)

> just save the results and have get_compiler_info set the right
> results for the language specified.

Something based on CPP would be more robust, and avoid assumptions such 
as the target has output and can correctly compile / execute code. 
Consider what happens when trying to bring up a new GDB+GCC+....

Andrew

Re: Problems with dejagnu and c++ tests...

[Michael Elizabeth Chastain]

Well, you could just add "return 1" to skip_cplus_tests on that system.

But in the long run, get_compiler_info needs to be smarter.
(Really, default_target_compile needs to have a better interface,
but we can't touch that).

Perhaps we should just kill get_compiler_info and add some more
code to initialization.  Have it compile and run two test programs,
one in C, and one in C++.  Like this:

  #include <stdio.h>
  int main ()
  {
  #if defined(__GNUC__)
    printf ("set compiler_info gcc-%d-%d\n", __GNUC__, __GNUC__MINOR__);
    printf ("set gcc_compiled %d\n", __GNUC__);
  else
    printf ("set gcc_compiled 0\n")
  #endif
  }

Then just save the results and have get_compiler_info set the right
results for the language specified.

Michael C

Re: Problems with dejagnu and c++ tests...

[Joel Brobecker]

> Rats, this is my clever code in get_compiler_info blowing up.

Humph! I was certain that I tried backing out your last gdb.exp
patch, and that it didn't help. I just tried again, and now it
seems to be working better...

Blush... I am glad you were able to zero in the source of the
problem before anybody spent any thought on this.

> What was the previous behavior when you did not have a C++ compiler?

Here is the output I get after I backout your patch and all the other
changes in gdb.exp after yours:

<<
gdb compile failed, gcc: ./lib/compiler.cc: C++ compiler not installed on this system
ERROR: Couldn't make /usr/prague.a/brobecke/next_pb/gdb-public/gdb/testsuite/gdb.cp/ambiguous.ci file
>>

-- 
Joel

Re: Problems with dejagnu and c++ tests...

[Michael Elizabeth Chastain]

Joel Brobecker reports

  <<
  Running ./gdb.cp/ambiguous.exp ...
  ERROR: (DejaGnu) proc "default_target_compile: Can't find g++." does not exist.
  The error code is NONE
  The info on the error is:
  close: invalid spawn id (6)
      while executing
  "close -i 6"
      invoked from within
  "catch "close -i $spawn_id""
  >>

Rats, this is my clever code in get_compiler_info blowing up.

ambiguous.exp calls get_compiler_info.  get_compiler_info calls
gdb_compile, captures the output, and eval's the output.

That explains the weird message about "proc" not found.

What was the previous behavior when you did not have a C++ compiler?

Michael C

Problems with dejagnu and c++ tests...

[Joel Brobecker]

I was wondering if somebody could help understand a problem that
all of a sudden appeared on me.

I am running the testsuite on Tru64, and I don't have a C++ compiler
on this target (and I never have). Up until recently, the gdb.cp tests
where executed as best as they could. But I tried running it today, and
kaboum:

<<
Running ./gdb.cp/ambiguous.exp ...
ERROR: (DejaGnu) proc "default_target_compile: Can't find g++." does not exist.
The error code is NONE
The info on the error is:
close: invalid spawn id (6)
    while executing
"close -i 6"
    invoked from within
"catch "close -i $spawn_id""
>>

The error, unfortunately, is simply aborting my run, and I don't
understand why.

As best as I can determine, the sequence of calls goes like this:

   gdb_compile
    -> target_compile
      -> default_target_compile

target_compile returns what default_target_compile returned, which
is 

    return "default_target_compile: Can't find $compiler."

And then the postprocessing of the output by gdb_compile looks like:

    set result [target_compile $source $dest $type $options];
    regsub "\[\r\n\]*$" "$result" "" result;
    regsub "^\[\r\n\]*" "$result" "" result;
    if { $result != "" && [lsearch $options quiet] == -1} {
        clone_output "gdb compile failed, $result"
    }
    return $result;

Does anybody have a clue of what's happening?

Thanks,
-- 
Joel