[RFA] testsuite/gdb.c++/ref-types.exp: use runto

[RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

This is Sunday Project Patch #5 (try #2).  This is unchanged from
the previous version, submitted 2001-02024, which received no response.

gdb.c++/ref-types.exp has several places with control logic like this:

  send_gdb "break marker1\n" ; gdb_expect -re ".*$gdb_prompt $"

      send_gdb "cont\n"
      gdb_expect {
	  -re "Break.* marker1 \\(\\) at .*:$decimal.*$gdb_prompt $" {
	      send_gdb "up\n"
	      gdb_expect {
		  -re ".*main.*$gdb_prompt $" {
		    pass "up from marker1"
		}
		  -re ".*$gdb_prompt $" {
		    fail "up from marker1"
		}
		  timeout { fail "up from marker1 (timeout)" }
	      }
	  }
	  -re "$gdb_prompt $" { fail "continue to marker1"  }
	  timeout { fail "(timeout) continue to marker1"  }
      }

With FSF g++ v3, I am getting output like this:

  Breakpoint 2, marker1() () at /vittone/fsf/2001-02-21/source-src/gdb/testsuite/gdb.c++/ref-types.cc:6
  6	}
  (gdb) FAIL: gdb.c++/ref-types.exp: continue to marker1

So the test script never issues the "up" command, the test script goes
off the rails, and every test FAILs.

The "marker1() ()" output is a v3 bug and I have filed PR gdb/34 about it.

This patch changes the test script to:

  if ![runto 'marker1'] then {
      perror "couldn't run to marker1"
      continue
  }

  gdb_test "up" ".*main.*" "up from marker1"

... which is shorter and cleaner anyways.  This enables the test script
to run its real tests, which proceed to PASS.  This fixes 60 FAILs,
leaving no FAILs for this test script.

Testing: tested on Red Hat Linux 6.2 native and Solaris 2.6 native with
g++ v2 and g++ v3.

OK to apply?

Michael

===

2001-02-24  Michael Chastain  <chastain@redhat.com>

	* gdb.c++/ref-types.exp: Change handwritten code to library
	function 'runto'.

===

Index: gdb/testsuite/gdb.c++/ref-types.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/ref-types.exp,v
retrieving revision 1.3
diff -c -3 -p -r1.3 ref-types.exp
*** gdb/testsuite/gdb.c++/ref-types.exp	2000/12/05 23:57:36	1.3
--- gdb/testsuite/gdb.c++/ref-types.exp	2001/02/24 05:49:52
*************** if ![runto_main] then {
*** 54,123 ****
      continue
  }
  
! send_gdb "break marker1\n" ; gdb_expect -re ".*$gdb_prompt $"
! 
!     send_gdb "cont\n"
!     gdb_expect {
!         -re "Break.* marker1 \\(\\) at .*:$decimal.*$gdb_prompt $" {
!             send_gdb "up\n"
!             gdb_expect {
!                 -re ".*main.*$gdb_prompt $" {
! 		    pass "up from marker1"
! 		}
!                 -re ".*$gdb_prompt $" {
! 		    fail "up from marker1"
! 		}
!                 timeout { fail "up from marker1 (timeout)" }
!             }
!         }
!         -re "$gdb_prompt $" { fail "continue to marker1"  }
!         timeout { fail "(timeout) continue to marker1"  }
!     }
! 
! 
! proc gdb_start_again {} {
! global srcdir
! global subdir
! global binfile
! global gdb_prompt
! global decimal
! 
! gdb_start
! gdb_reinitialize_dir $srcdir/$subdir
! gdb_load ${binfile}
! 
! source ${binfile}.ci
! 
! #
! # set it up at a breakpoint so we can play with the variable values
! #
! if ![runto_main] then {
!     perror "couldn't run to breakpoint"
      continue
  }
  
! send_gdb "break marker1\n" ; gdb_expect -re ".*$gdb_prompt $"
  
!     send_gdb "cont\n"
!     gdb_expect {
!         -re "Break.* marker1 \\(\\) at .*:$decimal.*$gdb_prompt $" {
!             send_gdb "up\n"
!             gdb_expect {
!                 -re ".*main.*$gdb_prompt $" {
! 		    pass "up from marker1"
! 		}
!                 -re ".*$gdb_prompt $" {
! 		    fail "up from marker1"
! 		}
!                 timeout { fail "up from marker1 (timeout)" }
!             }
!         }
!         -re "$gdb_prompt $" { fail "continue to marker1"  }
!         timeout { fail "(timeout) continue to marker1"  }
      }
- }
  
  
  
  
  
--- 54,94 ----
      continue
  }
  
! if ![runto 'marker1'] then {
!     perror "couldn't run to marker1"
      continue
  }
  
! gdb_test "up" ".*main.*" "up from marker1 1"
  
! proc gdb_start_again {} {
!     global srcdir
!     global subdir
!     global binfile
!     global gdb_prompt
!     global decimal
! 
!     gdb_start
!     gdb_reinitialize_dir $srcdir/$subdir
!     gdb_load ${binfile}
! 
!     source ${binfile}.ci
! 
!     #
!     # set it up at a breakpoint so we can play with the variable values
!     #
!     if ![runto_main] then {
! 	perror "couldn't run to breakpoint"
! 	continue
      }
  
+     if ![runto 'marker1'] then {
+ 	perror "couldn't run to marker1"
+ 	continue
+     }
  
+     gdb_test "up" ".*main.*" "up from marker1 2"
+ }
  
  
  
*************** gdb_expect {
*** 289,315 ****
      timeout           { fail "(timeout) print value of ras\[3\]" }
    }
  
- 
- send_gdb "break f\n" ; gdb_expect -re ".*$gdb_prompt $"
  
!     send_gdb "cont\n"
!     gdb_expect {
!         -re "Break.* f \\(\\) at .*:$decimal.*$gdb_prompt $" {
!             send_gdb "up\n"
!             gdb_expect {
!                 -re ".*main2.*$gdb_prompt $" {
! 		    pass "up from f" 
! 		}
!                 -re ".*$gdb_prompt $" {
! 		    fail "up from f" 
! 		}
!                 timeout { fail "up from f (timeout)" }
!             }
!         }
!         -re "$gdb_prompt $" { fail "continue to f"  }
!         timeout { fail "(timeout) continue to f"  }
!     }
  
  
  send_gdb "print C\n"
  gdb_expect {
--- 260,272 ----
      timeout           { fail "(timeout) print value of ras\[3\]" }
    }
  
  
! if ![runto 'f'] then {
!     perror "couldn't run to f"
!     continue
! }
  
+ gdb_test "up" ".main2.*" "up from f"
  
  send_gdb "print C\n"
  gdb_expect {

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

Daniel Berlin writes:

> I think I can come up with a better heuristic.
> How bout i do a minimal symbol lookup on the address we think the
> virtual function is at, and make sure it's the start of some real
> function (and if you really want to go a bit further, i'll make sure
> it's a function in the class, or it's base classes)

That sounds good to me.

In the virtfunc.cc case, the test script calls pAe->f(), but gdb actually
calls VB::vvb, because it's using the wrong vtable.

When gdb goes off the wire, it winds up reading out of some memory
that's near the right memory.  The vtables appear close to each other
in memory so I think it will often pick a random word out of a random
nearby vtable.

Instead of, or in addition to, looking at the class membership, you
could look at the function name.  If the user calls "f", but gdb
wants to call "vvb", then it's always wrong.

Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

Hi Daniel,

> It's not "usually" erroneous, it's that virtfunc.cc is worst case.
> In reality, it works most of the time.

I tried this out with the canonical diamond class, and it did work in
all the cases I tried (gcc 2.95.2, gdb cvs 2001-03-17, red hat linux
native, stabs).

I spent some time looking at gdb with virtfunc.cc.  gdb is coming up
with a bizarre offset: it thinks the offset of the "A" object in class
"E" is 28, when it should be 0.  That's causing most (if not all) of
the problems.

Maybe this can be fixed without breaking something else.  I'm going
to investigate more.

Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Hi Daniel,
> 
> > It's not "usually" erroneous, it's that virtfunc.cc is worst case.
> > In reality, it works most of the time.
> 
> I tried this out with the canonical diamond class, and it did work in
> all the cases I tried (gcc 2.95.2, gdb cvs 2001-03-17, red hat linux
> native, stabs).
> 
> I spent some time looking at gdb with virtfunc.cc.  gdb is coming up
> with a bizarre offset: it thinks the offset of the "A" object in class
> "E" is 28, when it should be 0.  That's causing most (if not all) of
> the problems.

Yes, I know.


> 
> Maybe this can be fixed without breaking something else.  I'm going
> to investigate more.

Remember, just because it works on Linux, ....

If you are going to try to do it without breaking something else,
you'll need to test on the other platforms that have a different set
of default flags.

> 
> Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

Actually, I'm suggesting two things:

(1) In the gdb test suite, print FAIL when gdb gives a wrong answer.

(2) In gdb, figure out a cover set for the cases that fail, and
    don't execute those cases.
    
"virtual functions altogether" would certainly cover all the buggy cases,
but it's too broad.

Perhaps "virtual functions in for classes where the complete type has
a virtual base"?

Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Actually, I'm suggesting two things:
> 
> (1) In the gdb test suite, print FAIL when gdb gives a wrong answer.
> 
> (2) In gdb, figure out a cover set for the cases that fail, and
>     don't execute those cases.
>     
> "virtual functions altogether" would certainly cover all the buggy cases,
> but it's too broad.
> 
> Perhaps "virtual functions in for classes where the complete type has
> a virtual base"?
This is still a lot of cases, because of mixin use.

I think I can come up with a better heuristic.
How bout i do a minimal symbol lookup on the address we think the
virtual function is at, and make sure it's the start of some real
function (and if you really want to go a bit further, i'll make sure
it's a function in the class, or it's base classes)

It's going to be exteremely rare that we come up with an address that
happens to match this heuristic, but isn't correct (because we'll
end up not at the start address of a function 99% of the time if we
are wrong).


--Dan
> 
> Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

The test suite knows that gdb is printing erroneous information.

And gdb knows that it's doing something which is likely to be
erroneous.  It's better to not do that in the first place than return
data which is usually erroneous.

Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> The test suite knows that gdb is printing erroneous information.
> 
> And gdb knows that it's doing something which is likely to be
> erroneous. 
Not likely, sometimes is a better word.
>  It's better to not do that in the first place than return
> data which is usually erroneous.

Usually?
It's not "usually" erroneous, it's that virtfunc.cc is worst case.
In reality, it works most of the time.
This is why i haven't just disabled it. People would scream bloody
murder.

Like I said, i also have them all passing with the new abi, and as
soon as i get subobjects printing okay, i'll submit the patch.

> 
> Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

Michael Snyder asks:
> When are we going to stop doing that???

The new C++ ABI has a public multi-vendor specification:

  http://reality.sgi.com/dehnert_engr/cxx/cxx-summary.html

The existence of a spec is a very good thing for gdb.

Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

Fernando Nasser writes:
> Something is broken.  It is just not GDB ;-)

Of course.  It's never GDB.  :)

Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

On Fri, 16 Mar 2001, Michael Elizabeth Chastain wrote:

> Fernando Nasser writes:
> > Something is broken.  It is just not GDB ;-)
> 
> Of course.  It's never GDB.  :)
> 
What's GDB?


Oh wait, wrong line of jokes.
--DAn

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

Daniel Berlin writes:
> Um, what exactly *should* it print?

Ah, you are thinking about gdb, and I am thinking about the test suite.

As long as gdb stays the way it is, the test suite should print "FAIL".

gdb should print "20".  If it can't print "20", then it should print
"that's too hard for me" (perhaps refuse to call functions in classes with
virtual bases).

> Fine, mark them fail. Just put (Won't ever fix for v2 abi) in parentheses.

That's fine.  Then the FAIL count will reflect the actual state of the
software.

Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

On Fri, 16 Mar 2001, Michael Elizabeth Chastain wrote:

> Daniel Berlin writes:
> > Um, what exactly *should* it print?
> 
> Ah, you are thinking about gdb, and I am thinking about the test suite.
> 
> As long as gdb stays the way it is, the test suite should print "FAIL".
> 
> gdb should print "20".  If it can't print "20", then it should print
> "that's too hard for me" (perhaps refuse to call functions in classes with
> virtual bases).

> > Fine,  mark them fail. Just put (Won't ever fix for v2 abi) in 
> parentheses. > 
> That's fine.  Then the FAIL count will reflect the actual state of the
> software.

Go for it.

> 
> Michael
> 

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

Christopher Faylor <cgf@redhat.com> writes:

> On Fri, Mar 16, 2001 at 02:49:29PM -0800, Michael Elizabeth Chastain wrote:
> >Daniel Berlin writes:
> >> Um, what exactly *should* it print?
> >
> >Ah, you are thinking about gdb, and I am thinking about the test suite.
> >
> >As long as gdb stays the way it is, the test suite should print "FAIL".
> >
> >gdb should print "20".  If it can't print "20", then it should print
> >"that's too hard for me" (perhaps refuse to call functions in classes with
> >virtual bases).
> 
> I thought that the point was that gdb didn't know that it was printing
> erroneous information.
> 
> cgf

It doesn't. He's suggesting we avoid letting you call any of the
virtual functions altogether, since it sometimes may be erroneous.

However, this would basically make C++ function calling useless.
--Dan

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

Daniel Berlin writes:
> Insufficient information, too many possibilities, and
> too much of a performance hit.

Well, I'll see the information for myself when I get to virtfunc.exp
and see whether the stabs have sufficient information or not.

As far as "too many possibilities" and "too much of a performance hit"
goes: those are not good reasons for (a) the software to print wrong
answers and then (b) the maintainers to claim that the software isn't
broken.

Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> As far as "too many possibilities" and "too much of a performance hit"
> goes: those are not good reasons for (a) the software to print wrong
> answers and then (b) the maintainers to claim that the software isn't
> broken.
> 

Something is broken.  It is just not GDB ;-)

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

On Fri, 16 Mar 2001, Michael Elizabeth Chastain wrote:

> Daniel Berlin writes:
> > Insufficient information, too many possibilities, and
> > too much of a performance hit.
> 
> Well, I'll see the information for myself when I get to virtfunc.exp
> and see whether the stabs have sufficient information or not.
Sigh.

 > 
> As far as "too many possibilities" and "too much of a performance hit"
> goes: those are not good reasons for (a) the software to print wrong
> answers 

Um, what exactly *should* it print?

It doesn't know it's wrong.

You seem to not be getting how virtual function calling works. If we 
could tell we were wrong, we wouldn't have a problem in the first place.

Feel free to implement the code to make it work right, or determine its 
wrong.

With some patches i'm about to submit, the v3 abi passes all of 
virtfunc.cc, and I have no plans to write 1500 lines of code to handle 
all possible v2 cases.

>and then (b) the maintainers to  claim that the software isn't > broken.

Fine, mark them fail. Just put (Won't ever fix for v2 abi) in parentheses.


> 
> Michael
> 

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

On Fri, 16 Mar 2001, Michael Elizabeth Chastain wrote:

> Daniel Berlin writes:
> > Insufficient information, too many possibilities, and
> > too much of a performance hit.
> 
> Well, I'll see the information for myself when I get to virtfunc.exp
> and see whether the stabs have sufficient information or not.

I look forward to seeing your implementation if you claim they do.

I can give you a list of platforms that use each of the combinations, so 
you can make sure it works on all of them, if you like.

Because fixing it just for one will break all the others.
--Dan

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

Mmmm, a philosophical dispute.

Daniel Berlin writes:
> They need to be xfail'd for old-abi, but not for new-abi.

I believe that when gdb has a bug which is under its control, that the
test suite should issue a FAIL, not an XFAIL.

Here is a gdb log entry for gcc 2.95.2, gdb CVS, Red Hat Linux 7 native,
stabs:

  (gdb) print pAe->f()
  $1 = 134547192
  (gdb) XFAIL: gdb.c++/virtfunc.exp: print pAe->f()

If gdb said "I'm sorry, but pAe->f() is too complex for me", I would
accept that as an XFAIL.  But when gdb prints wrong answers, that should
be a FAIL.

I'm interested in other maintainer's opinions on this because I'm
planning to submit patches to change such XFAIL's to FAIL's, so that
the test suite can actually report what is broken in C++ support.

Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> Mmmm, a philosophical dispute.
> 
> Daniel Berlin writes:
> > They need to be xfail'd for old-abi, but not for new-abi.
> 
> I believe that when gdb has a bug which is under its control, that the
> test suite should issue a FAIL, not an XFAIL.
> 

Yes, but what Dan is trying to say (I guess) is that this is _not_ under GDB's control. I.e., it was not possible for GDB to do the right thing because of insufficient information from the compiler.  Is that right Dan?

If that is the case, it is correct to mark those as XFAILs. Something besides GDB -- something in the execution environment or on another piece of the toolchain -- causes this test to fail and there is not that can be done inside GDB, so the "expected failure".

Maybe you guys can come up with a simple quick test to determine if we are dealing with v2 or v3.  It would be useful to condition tests.


> Here is a gdb log entry for gcc 2.95.2, gdb CVS, Red Hat Linux 7 native,
> stabs:
> 
>   (gdb) print pAe->f()
>   $1 = 134547192
>   (gdb) XFAIL: gdb.c++/virtfunc.exp: print pAe->f()
> 
> If gdb said "I'm sorry, but pAe->f() is too complex for me", I would
> accept that as an XFAIL.  But when gdb prints wrong answers, that should
> be a FAIL.
> 
> I'm interested in other maintainer's opinions on this because I'm
> planning to submit patches to change such XFAIL's to FAIL's, so that
> the test suite can actually report what is broken in C++ support.
> 
> Michael

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Peter.Schauer]

If you look at the CVS history of these tests, you will note that not all of
those tests were XFAIL'ed in the past.

gdb-4.17/gcc-2.8.1 handled most of these tests just fine, and they got
broken by the HP snowball, so it's not simply a matter of old-abi.

> Michael Elizabeth Chastain wrote:
> > 
> > Mmmm, a philosophical dispute.
> > 
> > Daniel Berlin writes:
> > > They need to be xfail'd for old-abi, but not for new-abi.
> > 
> > I believe that when gdb has a bug which is under its control, that the
> > test suite should issue a FAIL, not an XFAIL.
> > 
> 
> Yes, but what Dan is trying to say (I guess) is that this is _not_ under GDB's control. I.e., it was not possible for GDB to do the right thing because of insufficient information from the compiler.  Is that right Dan?
> 
> If that is the case, it is correct to mark those as XFAILs. Something besides GDB -- something in the execution environment or on another piece of the toolchain -- causes this test to fail and there is not that can be done inside GDB, so the "expected fai> lure".
> 
> Maybe you guys can come up with a simple quick test to determine if we are dealing with v2 or v3.  It would be useful to condition tests.
> 
> 
> > Here is a gdb log entry for gcc 2.95.2, gdb CVS, Red Hat Linux 7 native,
> > stabs:
> > 
> >   (gdb) print pAe->f()
> >   $1 = 134547192
> >   (gdb) XFAIL: gdb.c++/virtfunc.exp: print pAe->f()
> > 
> > If gdb said "I'm sorry, but pAe->f() is too complex for me", I would
> > accept that as an XFAIL.  But when gdb prints wrong answers, that should
> > be a FAIL.
> > 
> > I'm interested in other maintainer's opinions on this because I'm
> > planning to submit patches to change such XFAIL's to FAIL's, so that
> > the test suite can actually report what is broken in C++ support.
> > 
> > Michael
> 
> -- 
> Fernando Nasser
> Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
> 
> 


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

On Sat, 17 Mar 2001, Peter.Schauer wrote:

> If you look at the CVS history of these tests, you will note that not all of
> those tests were XFAIL'ed in the past.
> 
> gdb-4.17/gcc-2.8.1 handled most of these tests just fine, and they got
> broken by the HP snowball, so it's not simply a matter of old-abi.

The C++ ABI has changed since 2.8.1 (3 times since then, IIRC), in ways 
that break gdb.


--Dan

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Snyder]

Daniel Berlin wrote:
> 
> On Sat, 17 Mar 2001, Peter.Schauer wrote:
> 
> > If you look at the CVS history of these tests, you will note that not all of
> > those tests were XFAIL'ed in the past.
> >
> > gdb-4.17/gcc-2.8.1 handled most of these tests just fine, and they got
> > broken by the HP snowball, so it's not simply a matter of old-abi.
> 
> The C++ ABI has changed since 2.8.1 (3 times since then, IIRC), in ways
> that break gdb.

When are we going to stop doing that???

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

On Fri, 16 Mar 2001, Michael Snyder wrote:

> Daniel Berlin wrote:
> > 
> > On Sat, 17 Mar 2001, Peter.Schauer wrote:
> > 
> > > If you look at the CVS history of these tests, you will note that not all of
> > > those tests were XFAIL'ed in the past.
> > >
> > > gdb-4.17/gcc-2.8.1 handled most of these tests just fine, and they got
> > > broken by the HP snowball, so it's not simply a matter of old-abi.
> > 
> > The C++ ABI has changed since 2.8.1 (3 times since then, IIRC), in ways
> > that break gdb.
> 
> When are we going to stop doing that???
> 

The 3.0 ABI will be around for a *long* time. It's been agreed to by 
multiple vendors (It's also the official C++ ABI for IA64), so it's not 
really going to change for a long time.
--Dan

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Andrew Cagney]

Fernando Nasser wrote:

> Maybe you guys can come up with a simple quick test to determine if we are dealing with v2 or v3.  It would be useful to condition tests.

Is there a (something like):

	{info,show,set}? cplusplus-abi

command?  If there isn't there probably should be :-)

I'd imagine a test that:

	o	some how checks that the ABI
		has been selected correctly

while most C++ tests would:

	o	ask GDB what the C++ ABI is and
		then expect results accordingly.

of course, if GDB gets the first one wrong, the second one is pretty
bad.  sizeof.exp plays this trick.

	Andrew

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

On Fri, 16 Mar 2001, Andrew Cagney wrote:

> Fernando Nasser wrote:
> 
> > Maybe you guys can come up with a simple quick test to determine if we are dealing with v2 or v3.  It would be useful to condition tests.
> 
> Is there a (something like):
> 
> 	{info,show,set}? cplusplus-abi
> 
> command?  If there isn't there probably should be :-)

There is with the latest abstraction patch  revision, there is.
--Dan

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

On Fri, 16 Mar 2001, Fernando Nasser wrote:

> Michael Elizabeth Chastain wrote:
> > 
> > Mmmm, a philosophical dispute.
> > 
> > Daniel Berlin writes:
> > > They need to be xfail'd for old-abi, but not for new-abi.
> > 
> > I believe that when gdb has a bug which is under its control, that the
> > test suite should issue a FAIL, not an XFAIL.
> > 
> 
> Yes, but what Dan is trying to say (I guess) is that this is _not_
> under GDB's control. I.e., it was not possible for GDB to do the right
> thing because of insufficient information from the compiler.  Is that
> right Dan?
> 
Yes.
Insufficient information, too many possibilities, and
too much of a performance hit.
There are too many combinations, and no easy way to tell them apart.
You'd end up with like at least 96 cases (4 possible vtable-thunks
flags * 2 cases for each type of vtbl_ptr_type * 3 normal cases * the ABI
changed four times)
in just to determine which virtual function to call.
Then another 96 to determine how to offset the pointer, etc.

This doesn't even count the logic necessary to fill in the information we
don't have from the debug info (the offset of the virtual thunk, etc),
which would take a huge performance hit to try to figure out.
 > If that is
the case, it is correct to mark those as XFAILs.
>Something besides GDB -- something in the execution environment or on
>another piece of the toolchain -- causes this test to fail and there is
>not that can be done inside GDB, so the "expected failure".
> 
> Maybe you guys can come up with a simple quick test to determine if we
> are dealing with v2 or v3.  It would be useful to condition tests.

I added a simple if to the minsym demangling (where it goes through all
the minimal symbols and demangles them) to determine if we were dealing
with v3 or v2, and set the ABI approriately.

I can add a simple maintenance command to print out the C++ ABI shortname
(gnu-v3, gnu-v2, hpaCC), and you could use that, I think.
> > If gdb said "I'm sorry, but pAe->f() is too complex for me", I would
> > accept that as an XFAIL.  But when gdb prints wrong answers, that should
> > be a FAIL.
> > 
> > I'm interested in other maintainer's opinions on this because I'm
> > planning to submit patches to change such XFAIL's to FAIL's, so that
> > the test suite can actually report what is broken in C++ support.
Pleaes don't do this for v2.
It's not broken. It's something we can't fix.
I've already got them *all* working for v3 ABI.

--Dan

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> Fernando Nasser writes:
> > But I wonder if we should not call gdb_start_again() the first time
> > around instead of having the code duplicated.  It is exactly the same
> > thing.
> 
> Doh!  I'm so busy with individual lines, I missed an opportunity to
> take out a whole section.
> 

No sweat!  Just add it to you TODO list.

> ref_types.exp works now, so I am going to leave it alone and fix more
> pressing problems first: like gdb.c++/userdef.exp, which has no code,
> and gdb.c++/virtfunc.exp, which XFAILs some tests because gdb doesn't
> do the right thing.
> 

OK.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Fernando Nasser writes:
> > But I wonder if we should not call gdb_start_again() the first time
> > around instead of having the code duplicated.  It is exactly the same
> > thing.
> 
> Doh!  I'm so busy with individual lines, I missed an opportunity to
> take out a whole section.
> 
> ref_types.exp works now, so I am going to leave it alone and fix more
> pressing problems first: like gdb.c++/userdef.exp, which has no code,
> and gdb.c++/virtfunc.exp, which XFAILs some tests because gdb
> doesn't
^^^^^^^
can't
Not doesn't.
Can't.

They need to be xfail'd for old-abi, but not for new-abi.

> do the right thing.
> 
> Michael

Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Snyder]

Daniel Berlin wrote:
> 
> Michael Elizabeth Chastain <chastain@cygnus.com> writes:
> 
> > Fernando Nasser writes:
> > > But I wonder if we should not call gdb_start_again() the first time
> > > around instead of having the code duplicated.  It is exactly the same
> > > thing.
> >
> > Doh!  I'm so busy with individual lines, I missed an opportunity to
> > take out a whole section.
> >
> > ref_types.exp works now, so I am going to leave it alone and fix more
> > pressing problems first: like gdb.c++/userdef.exp, which has no code,
> > and gdb.c++/virtfunc.exp, which XFAILs some tests because gdb
> > doesn't   [do the right thing]
> ^^^^^^^
> can't
> Not doesn't.
> Can't.
> 
> They need to be xfail'd for old-abi, but not for new-abi.

In that case, (and without having looked at the test), 
I wonder if it would be possible to do something like the following?

  send_gdb "whatever\n
"
  gdb_expect {
    -re "new_abi_pattern" {
	pass "this test";
    }
    -re "old_abi_pattern" {
	setup_xfail "this test";
	fail "this test"
    }
    default {
	fail "this test";
    }
  }

[RFA] testsuite/gdb.c++/ref-types.exp: use runto

[Michael Elizabeth Chastain]

This is Sunday Project Patch #5.

gdb.c++/ref-types.exp has several places with control logic like this:

  send_gdb "break marker1\n" ; gdb_expect -re ".*$gdb_prompt $"

      send_gdb "cont\n"
      gdb_expect {
	  -re "Break.* marker1 \\(\\) at .*:$decimal.*$gdb_prompt $" {
	      send_gdb "up\n"
	      gdb_expect {
		  -re ".*main.*$gdb_prompt $" {
		    pass "up from marker1"
		}
		  -re ".*$gdb_prompt $" {
		    fail "up from marker1"
		}
		  timeout { fail "up from marker1 (timeout)" }
	      }
	  }
	  -re "$gdb_prompt $" { fail "continue to marker1"  }
	  timeout { fail "(timeout) continue to marker1"  }
      }

With FSF g++ v3, I am getting output like this:

  Breakpoint 2, marker1() () at /vittone/fsf/2001-02-21/source-src/gdb/testsuite/gdb.c++/ref-types.cc:6
  6	}
  (gdb) FAIL: gdb.c++/ref-types.exp: continue to marker1

So the test script never issues the "up" command, the test script goes
off the rails, and every test FAILs.

The "marker1() ()" output is a v3 bug and I have filed PR gdb/34 about it.

This patch changes the test script to:

  if ![runto 'marker1'] then {
      perror "couldn't run to marker1"
      continue
  }

  gdb_test "up" ".*main.*" "up from marker1"

... which is shorter and cleaner anyways.  This enables the test script
to run its real tests, which proceed to PASS.  This fixes 60 FAILs,
leaving no FAILs for this test script.

Testing: tested on Red Hat Linux 6.2 native, Red Hat Linux 7.0 native,
and Solaris 2.6 native with g++ v2 and g++ v3.

OK to apply?

Michael

===

2001-02-24  Michael Chastain  <chastain@redhat.com>

	* gdb.c++/ref-types.exp: Change handwritten code to library
	function 'runto'.

===

Index: gdb/testsuite/gdb.c++/ref-types.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/ref-types.exp,v
retrieving revision 1.3
diff -c -3 -p -r1.3 ref-types.exp
*** gdb/testsuite/gdb.c++/ref-types.exp	2000/12/05 23:57:36	1.3
--- gdb/testsuite/gdb.c++/ref-types.exp	2001/02/24 05:49:52
*************** if ![runto_main] then {
*** 54,123 ****
      continue
  }
  
! send_gdb "break marker1\n" ; gdb_expect -re ".*$gdb_prompt $"
! 
!     send_gdb "cont\n"
!     gdb_expect {
!         -re "Break.* marker1 \\(\\) at .*:$decimal.*$gdb_prompt $" {
!             send_gdb "up\n"
!             gdb_expect {
!                 -re ".*main.*$gdb_prompt $" {
! 		    pass "up from marker1"
! 		}
!                 -re ".*$gdb_prompt $" {
! 		    fail "up from marker1"
! 		}
!                 timeout { fail "up from marker1 (timeout)" }
!             }
!         }
!         -re "$gdb_prompt $" { fail "continue to marker1"  }
!         timeout { fail "(timeout) continue to marker1"  }
!     }
! 
! 
! proc gdb_start_again {} {
! global srcdir
! global subdir
! global binfile
! global gdb_prompt
! global decimal
! 
! gdb_start
! gdb_reinitialize_dir $srcdir/$subdir
! gdb_load ${binfile}
! 
! source ${binfile}.ci
! 
! #
! # set it up at a breakpoint so we can play with the variable values
! #
! if ![runto_main] then {
!     perror "couldn't run to breakpoint"
      continue
  }
  
! send_gdb "break marker1\n" ; gdb_expect -re ".*$gdb_prompt $"
  
!     send_gdb "cont\n"
!     gdb_expect {
!         -re "Break.* marker1 \\(\\) at .*:$decimal.*$gdb_prompt $" {
!             send_gdb "up\n"
!             gdb_expect {
!                 -re ".*main.*$gdb_prompt $" {
! 		    pass "up from marker1"
! 		}
!                 -re ".*$gdb_prompt $" {
! 		    fail "up from marker1"
! 		}
!                 timeout { fail "up from marker1 (timeout)" }
!             }
!         }
!         -re "$gdb_prompt $" { fail "continue to marker1"  }
!         timeout { fail "(timeout) continue to marker1"  }
      }
- }
  
  
  
  
  
--- 54,94 ----
      continue
  }
  
! if ![runto 'marker1'] then {
!     perror "couldn't run to marker1"
      continue
  }
  
! gdb_test "up" ".*main.*" "up from marker1 1"
  
! proc gdb_start_again {} {
!     global srcdir
!     global subdir
!     global binfile
!     global gdb_prompt
!     global decimal
! 
!     gdb_start
!     gdb_reinitialize_dir $srcdir/$subdir
!     gdb_load ${binfile}
! 
!     source ${binfile}.ci
! 
!     #
!     # set it up at a breakpoint so we can play with the variable values
!     #
!     if ![runto_main] then {
! 	perror "couldn't run to breakpoint"
! 	continue
      }
  
+     if ![runto 'marker1'] then {
+ 	perror "couldn't run to marker1"
+ 	continue
+     }
  
+     gdb_test "up" ".*main.*" "up from marker1 2"
+ }
  
  
  
*************** gdb_expect {
*** 289,315 ****
      timeout           { fail "(timeout) print value of ras\[3\]" }
    }
  
- 
- send_gdb "break f\n" ; gdb_expect -re ".*$gdb_prompt $"
  
!     send_gdb "cont\n"
!     gdb_expect {
!         -re "Break.* f \\(\\) at .*:$decimal.*$gdb_prompt $" {
!             send_gdb "up\n"
!             gdb_expect {
!                 -re ".*main2.*$gdb_prompt $" {
! 		    pass "up from f" 
! 		}
!                 -re ".*$gdb_prompt $" {
! 		    fail "up from f" 
! 		}
!                 timeout { fail "up from f (timeout)" }
!             }
!         }
!         -re "$gdb_prompt $" { fail "continue to f"  }
!         timeout { fail "(timeout) continue to f"  }
!     }
  
  
  send_gdb "print C\n"
  gdb_expect {
--- 260,272 ----
      timeout           { fail "(timeout) print value of ras\[3\]" }
    }
  
  
! if ![runto 'f'] then {
!     perror "couldn't run to f"
!     continue
! }
  
+ gdb_test "up" ".main2.*" "up from f"
  
  send_gdb "print C\n"
  gdb_expect {