Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Michael Elizabeth Chastain]

>   gdb_breakpoint "main" {allow-pending}
>   runto "main" {allow-pending}

Something like that is okay with me -- exploiting the varargs features
of TCL rather than adding another proc.  I'm not fluent in TCL so
I definitely have no sense of style in that area.

I should just curl up with the TCL book already.

Michael C

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Daniel Jacobowitz]

On Mon, Feb 09, 2004 at 05:56:01PM -0500, Michael Chastain wrote:
> >   gdb_breakpoint "main" {allow-pending}
> >   runto "main" {allow-pending}
> 
> Something like that is okay with me -- exploiting the varargs features
> of TCL rather than adding another proc.  I'm not fluent in TCL so
> I definitely have no sense of style in that area.
> 
> I should just curl up with the TCL book already.

Something like this is what I had in mind.  Does it work for you?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-02-29  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.base/gdb1250.exp: Use runto {allow-pending}.
	* lib/gdb.exp (runto, gdb_breakpoint): Support {allow-pending}.

Index: testsuite/gdb.base/gdb1250.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/gdb1250.exp,v
retrieving revision 1.1
diff -u -p -r1.1 gdb1250.exp
--- testsuite/gdb.base/gdb1250.exp	15 Jul 2003 16:28:21 -0000	1.1
+++ testsuite/gdb.base/gdb1250.exp	29 Feb 2004 17:41:14 -0000
@@ -42,7 +42,7 @@ gdb_start
 gdb_reinitialize_dir $srcdir/$subdir
 gdb_load ${binfile}
 
-if ![runto abort] then {
+if ![runto abort {allow-pending}] then {
     perror "couldn't run to breakpoint"
     continue
 }
Index: testsuite/lib/gdb.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.49
diff -u -p -r1.49 gdb.exp
--- testsuite/lib/gdb.exp	23 Feb 2004 19:27:46 -0000	1.49
+++ testsuite/lib/gdb.exp	29 Feb 2004 17:41:14 -0000
@@ -265,18 +265,32 @@ proc gdb_run_cmd {args} {
     }
 }
 
-proc gdb_breakpoint { function } {
+# Set a breakpoint at FUNCTION.  If there is an additional argument it is
+# a list of options; the only currently supported option is allow-pending.
+
+proc gdb_breakpoint { function args } {
     global gdb_prompt
     global decimal
 
+    set pending_response n
+    if {[lsearch -exact [lindex $args 0] allow-pending] != -1} {
+	set pending_response y
+    }
+
     send_gdb "break $function\n"
     # The first two regexps are what we get with -g, the third is without -g.
     gdb_expect 30 {
 	-re "Breakpoint \[0-9\]* at .*: file .*, line $decimal.\r\n$gdb_prompt $" {}
 	-re "Breakpoint \[0-9\]*: file .*, line $decimal.\r\n$gdb_prompt $" {}
 	-re "Breakpoint \[0-9\]* at .*$gdb_prompt $" {}
+	-re "Breakpoint \[0-9\]* \\(.*\\) pending.*$gdb_prompt $" {
+		if {$pending_response == "n"} {
+			fail "setting breakpoint at $function"
+			return 0
+		}
+	}
 	-re "Make breakpoint pending.*y or \\\[n\\\]. $" { 
-		send_gdb "n\n"
+		send_gdb "$pending_response\n"
 		exp_continue
 	}
 	-re "$gdb_prompt $" { fail "setting breakpoint at $function" ; return 0 }
@@ -289,15 +303,16 @@ proc gdb_breakpoint { function } {
 # Since this is the only breakpoint that will be set, if it stops
 # at a breakpoint, we will assume it is the one we want.  We can't
 # just compare to "function" because it might be a fully qualified,
-# single quoted C++ function specifier.
+# single quoted C++ function specifier.  If there's an additional argument,
+# pass it to gdb_breakpoint.
 
-proc runto { function } {
+proc runto { function args } {
     global gdb_prompt
     global decimal
 
     delete_breakpoints
 
-    if ![gdb_breakpoint $function] {
+    if ![gdb_breakpoint $function [lindex $args 0]] {
 	return 0;
     }
 

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Michael Elizabeth Chastain]

This patch works great for me:

  native i686-pc-linux-gnu
  gcc 2.95.3, 3.3.3, HEAD
  binutils 2.14, HEAD
  dwarf-2, stabs+

It fixes the problem in gdb1250.exp and doesn't break anything else.

Michael C

===

2004-02-29  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.base/gdb1250.exp: Use runto {allow-pending}.
	* lib/gdb.exp (runto, gdb_breakpoint): Support {allow-pending}.

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Michael Elizabeth Chastain]

This patch works great for me:

  native i686-pc-linux-gnu
  gcc 2.95.3, 3.3.3, HEAD
  binutils 2.14, HEAD
  dwarf-2, stabs+

It fixes the problem in gdb1250.exp and doesn't break anything else.

Michael C

===

2004-02-29  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.base/gdb1250.exp: Use runto {allow-pending}.
	* lib/gdb.exp (runto, gdb_breakpoint): Support {allow-pending}.

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Daniel Jacobowitz]

On Tue, Mar 02, 2004 at 10:48:29AM -0500, Michael Chastain wrote:
> This patch works great for me:
> 
>   native i686-pc-linux-gnu
>   gcc 2.95.3, 3.3.3, HEAD
>   binutils 2.14, HEAD
>   dwarf-2, stabs+
> 
> It fixes the problem in gdb1250.exp and doesn't break anything else.
> 
> Michael C
> 
> ===
> 
> 2004-02-29  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* gdb.base/gdb1250.exp: Use runto {allow-pending}.
> 	* lib/gdb.exp (runto, gdb_breakpoint): Support {allow-pending}.

I've checked this in.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Michael Elizabeth Chastain]

> None of that reference was in your message, and I don't run tests with
> binutils HEAD regularly...

No big deal.  I wrote to binutils@ when it happened, and I've been
whining it about it my "60 versus HEAD" comparisons.  I figured it
was just information overload.

If you could take a look at pr gdb/1470 now just to get it into your L2
cache I'd be grateful.

> I suppose.  I don't much care either way though the new parameter seems
> awkward to me - isn't the _with_pending in the name enough?

My intuition says "no".  An interface with a parameter is more flexible.

But my intuition can be wrong, and my taste can be misguided.

Michael C

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Daniel Jacobowitz]

On Mon, Feb 09, 2004 at 05:45:45PM -0500, Michael Chastain wrote:
> > None of that reference was in your message, and I don't run tests with
> > binutils HEAD regularly...
> 
> No big deal.  I wrote to binutils@ when it happened, and I've been
> whining it about it my "60 versus HEAD" comparisons.  I figured it
> was just information overload.
> 
> If you could take a look at pr gdb/1470 now just to get it into your L2
> cache I'd be grateful.
> 
> > I suppose.  I don't much care either way though the new parameter seems
> > awkward to me - isn't the _with_pending in the name enough?
> 
> My intuition says "no".  An interface with a parameter is more flexible.
> 
> But my intuition can be wrong, and my taste can be misguided.

I think the options are:
  gdb_breakpoint_with_pending_flag "main" "yes"
  gdb_breakpoint "main" "yes"
  gdb_breakpoint_with_pending "main"

Hmm, that second one is nice.  Or:
  gdb_breakpoint "main" {allow-pending}
  runto "main" {allow-pending}

How do you feel about that?  This is TCL, after all, we can use it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Michael Elizabeth Chastain]

mec> This test is sensitive to the version of binutils because binutils HEAD
mec> has a PLT optimization for shared library functions.

drow> So it used to fail with binutils HEAD, right?

"Used to" as in "has been failing since 2003-11-27 to 2004-02-09", yes.
It was pr gdb/1470.  Maybe it slipped off your radar screen.

> - Should there be a version of gdb_breakpoint that answers yes to the
> pending question?
> - If so, should runto use it?  Or should there be a version of runto
> that does?

Err, yeah.  I suppose the right thing is to make

  gdb_breakpoint_with_pending $name $pendingp

Then:

  proc gdb_breakpoint { name } {
    return gdb_breakpoint_with_pending "$name" "no"
  }

I see 3 instance of "gdb_breakpoint exit" and they need to be
investigated.

On principle, same with "runto".

I don't know what the right name is, either.  But I do think that the
the new functions should take a second parameter.

Michael C

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Daniel Jacobowitz]

On Mon, Feb 09, 2004 at 05:05:29PM -0500, Michael Chastain wrote:
> mec> This test is sensitive to the version of binutils because binutils HEAD
> mec> has a PLT optimization for shared library functions.
> 
> drow> So it used to fail with binutils HEAD, right?
> 
> "Used to" as in "has been failing since 2003-11-27 to 2004-02-09", yes.
> It was pr gdb/1470.  Maybe it slipped off your radar screen.

None of that reference was in your message, and I don't run tests with
binutils HEAD regularly...

> > - Should there be a version of gdb_breakpoint that answers yes to the
> > pending question?
> > - If so, should runto use it?  Or should there be a version of runto
> > that does?
> 
> Err, yeah.  I suppose the right thing is to make
> 
>   gdb_breakpoint_with_pending $name $pendingp
> 
> Then:
> 
>   proc gdb_breakpoint { name } {
>     return gdb_breakpoint_with_pending "$name" "no"
>   }
> 
> I see 3 instance of "gdb_breakpoint exit" and they need to be
> investigated.
> 
> On principle, same with "runto".
> 
> I don't know what the right name is, either.  But I do think that the
> the new functions should take a second parameter.

I suppose.  I don't much care either way though the new parameter seems
awkward to me - isn't the _with_pending in the name enough?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Michael Elizabeth Chastain]

This patch enhances gdb.base/gdb1250.exp so that it works with
the new pending-breakpoint interface.  This test wants to set a
breakpoint on 'abort', which may be in a shared library.

Of course it still works with the old 'just quietly set the breakpoint'
interface.

I tested on native i686-pc-linux-gnu, red hat 8.0, glibc 2.2.93-5-rh.
I tested with gdb 6.0 and gdb HEAD, gcc 3.3.2, binutils 2.14 and
binutils HEAD, dwarf-2 and stabs+.  All the tests PASSed in all
configurations.

This test is sensitive to the version of binutils because binutils HEAD
has a PLT optimization for shared library functions.

Okay to commit?

Michael C

2004-02-09  Michael Chastain  <mec.gnu@mindspring.com>

	* gdb.base/gdb1250.exp: Improve 'break abort' to work with new
	pending-breakpoint user interface.

Index: gdb1250.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/gdb1250.exp,v
retrieving revision 1.1
diff -c -3 -p -r1.1 gdb1250.exp
*** gdb1250.exp	15 Jul 2003 16:28:21 -0000	1.1
--- gdb1250.exp	9 Feb 2004 07:17:30 -0000
***************
*** 1,4 ****
! # Copyright 2003 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
--- 1,4 ----
! # Copyright 2003, 2004 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
*************** gdb_start
*** 42,51 ****
  gdb_reinitialize_dir $srcdir/$subdir
  gdb_load ${binfile}
  
! if ![runto abort] then {
      perror "couldn't run to breakpoint"
      continue
  }
  
  # See http://sources.redhat.com/gdb/bugs/1250
  #
--- 42,67 ----
  gdb_reinitialize_dir $srcdir/$subdir
  gdb_load ${binfile}
  
! # Set a breakpoint on 'abort' and run to it.  gdb_breakpoint and runto
! # do not work because they answer 'no' to the breakpoint-pending
! # question.
! 
! if { ![runto_main] } then {
      perror "couldn't run to breakpoint"
      continue
  }
+ 
+ gdb_test_multiple "break abort" "break on abort" {
+     -re "Breakpoint $decimal .*$gdb_prompt $" {
+ 	pass "break on abort"
+     }
+     -re "Function \"abort\" not defined.\r\n.*Make breakpoint pending on future shared library load? \\(y or n\\) $" {
+ 	send_gdb "yes\n"
+ 	exp_continue
+     }
+ }
+ 
+ gdb_test "continue" "Breakpoint $decimal.*" "continue to abort"
  
  # See http://sources.redhat.com/gdb/bugs/1250
  #

Re: [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints

[Daniel Jacobowitz]

On Mon, Feb 09, 2004 at 02:23:40AM -0500, Michael Chastain wrote:
> This patch enhances gdb.base/gdb1250.exp so that it works with
> the new pending-breakpoint interface.  This test wants to set a
> breakpoint on 'abort', which may be in a shared library.
> 
> Of course it still works with the old 'just quietly set the breakpoint'
> interface.
> 
> I tested on native i686-pc-linux-gnu, red hat 8.0, glibc 2.2.93-5-rh.
> I tested with gdb 6.0 and gdb HEAD, gcc 3.3.2, binutils 2.14 and
> binutils HEAD, dwarf-2 and stabs+.  All the tests PASSed in all
> configurations.
> 
> This test is sensitive to the version of binutils because binutils HEAD
> has a PLT optimization for shared library functions.

So it used to fail with binutils HEAD, right?

> 
> Okay to commit?

This I'm not so sure about.

- Should there be a version of gdb_breakpoint that answers yes to the
pending question?
- If so, should runto use it?  Or should there be a version of runto
that does?

I think the latter might be best but I don't know what to call them. 
Maybe:
  gdb_breakpoint_allow_pending
  runto_allow_pending

> 2004-02-09  Michael Chastain  <mec.gnu@mindspring.com>
> 
> 	* gdb.base/gdb1250.exp: Improve 'break abort' to work with new
> 	pending-breakpoint user interface.

Fixing this is great though!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer