Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Andrew Cagney]

Anyone?


	Andrew

> Here's the test I promised Andrew a while ago for the fix for the
> problem reported by Jonathan Larmour:
> 
>    http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
> 
> The fix has already been checked in, the problem is still mentioned in
> the TODO file (let's keep it there until this test has been added).
> 
> I verified that some of these tests (the "stepi" and "nexti" tests)
> do fail without my fix to infrun.c.
> 
> I'm not sure to what extent the use of setitimer() is portable.
> However, it is hard to come up with a test that doesn't use it.
> 
> 
> 2000-05-20  Mark Kettenis  <kettenis@gnu.org>
> 
> Add tests for stepping with pending signals.
> 	* gdb.base/step-alarm.exp: New file.
> 	* gdb.base/step-alarm.c: New file.
> 
> 
> --- /dev/null	Thu Feb 19 16:30:24 1998
> +++ testsuite/gdb.base/step-alarm.exp	Sat May 20 01:09:56 2000
> @@ -0,0 +1,226 @@
> +# Copyright (C) 1997, 1998, 1999, 2000 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
> +# the Free Software Foundation; either version 2 of the License, or
> +# (at your option) any later version.
> +# 
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +# 
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write to the Free Software
> +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
> +
> +# Please email any bugs, comments, and/or additions to this file to:
> +# bug-gdb@gnu.org
> +
> +# use this to debug:
> +#
> +#log_user 1
> +
> +# step-alarm.exp -- Expect script to test stepping in gdb
> +#                   with a pending signals
> +
> +# Most of this script is copied over from step-test.exp.  We run (almost)
> +# the same tests, except that we set a timer and install a SIGALRM signal
> +# handler.  The addition of these tests was prompted by the following fix:
> +#
> +# 2000-05-01  Mark Kettenis  <kettenis@gnu.org>
> +#
> +#	* infrun.c (handle_inferior_event): Add missing call to keep_going
> +#	and missing return when handling an ordinary signal from the
> +#	inferior.
> +#
> +# for a problem where "stepi" didn't make any progress if a signal
> +# was pending. 
> +
> +if $tracelevel then {
> +    strace $tracelevel
> +}
> +
> +set testfile step-alarm
> +set srcfile ${srcdir}/${subdir}/${testfile}.c
> +set binfile ${objdir}/${subdir}/${testfile}
> +
> +remote_exec build "rm -f ${binfile}"
> +if { [gdb_compile "${srcfile}" "${binfile}" executable {debug}] != "" } {
> +     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}
> +
> +if ![runto_main] then {
> +   fail "Can't run to main"
> +   return 0
> +}
> +
> +# Make sure that the signal handler is installed, and the timer is set.
> +#
> +gdb_test "break [gdb_get_line_number "w = 0"]" \
> +         ".*Breakpoint.* at .*" \
> +         "set breakpoint after timer activation"
> +gdb_test "continue" \
> +	 ".*Breakpoint ${decimal},.*w = 0.*" \
> +	 "run until timer is activated"
> +
> +
> +# Set a breakpoint at line 57, if stepi then finish fails, we would
> +# run to the end of the program, which would mess up the rest of the tests.
> +  
> +# Vanilla step/next
> +#
> +gdb_test "next" ".*${decimal}.*x = 1;.*" "next 1"
> +gdb_test "step" ".*${decimal}.*y = 2;.*" "step 1"
> +
> +# With count
> +#
> +gdb_test "next 2" ".*${decimal}.*w = w.*2;.*" "next 2"
> +gdb_test "step 3" ".*${decimal}.*z = z.*5;.*" "step 3"
> +gdb_test "next" ".*${decimal}.*callee.*OVER.*" "next 3"
> +
> +# Step over call
> +#
> +gdb_test "next" ".*${decimal}.*callee.*INTO.*" "next over"
> +
> +# Step into call
> +#
> +gdb_test "step" ".*${decimal}.*myglob.*"   "step into"
> +
> +# Step out of call
> +#
> +# I wonder if this is really portable.  Are there any caller-saves
> +# platforms, on which `finish' will return you to some kind of pop
> +# instruction, which is attributed to the line containing the function
> +# call?
> +
> +# On PA64, we end up at a different instruction than PA32.
> +# On IA-64, we also end up on callee instead of on the next line due
> +# to the restoration of the global pointer (which is a caller-save).
> +if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"]} {
> +    send_gdb "finish\n"
> +    gdb_expect {
> +        -re ".*${decimal}.*a.*5.*= a.*3.*$gdb_prompt $" { pass "step out 1" }
> +        -re ".*${decimal}.*callee.*INTO.*$gdb_prompt $" { pass "step out 2" }
> +        timeout { fail "step out" }
> +    }
> +} else {
> +    gdb_test "finish" ".*${decimal}.*a.*5.*= a.*3.*" "step out"
> +}
> +
> +### Testing nexti and stepi.
> +###
> +### test_i NAME COMMAND HERE THERE
> +###
> +### Send COMMAND to gdb over and over, while the output matches the
> +### regexp HERE, followed by the gdb prompt.  Pass if the output
> +### eventually matches the regexp THERE, followed by the gdb prompt;
> +### fail if we have to iterate more than a hundred times, we time out
> +### talking to gdb, or we get output which is neither HERE nor THERE.  :)
> +###
> +### Use NAME as the name of the test.
> +###
> +### The exact regexps used are "$HERE.*$gdb_prompt $"
> +###                        and "$THERE.*$gdb_prompt $"
> +### 
> +proc test_i {name command here there} {
> +    global gdb_prompt
> +    
> +    set i 0
> +    while 1 {
> +	send_gdb "${command}\n"
> +	gdb_expect {
> +	    -re "$here.*$gdb_prompt $" {
> +		# Okay, we're still on the same line.  Just step again.
> +	    }
> +	    -re "$there.*$gdb_prompt $" {
> +		# We've reached the next line.  Rah.
> +		pass "$name"
> +		return
> +	    }
> +	    -re "$gdb_prompt $" {
> +		# We got something else.  Fail.
> +		fail "$name"
> +		return
> +	    }
> +	    timeout {
> +		fail "$name (timeout)"
> +		return
> +	    }
> +	}
> +
> +	# Have we gone for too many steps without seeing any progress?
> +	if {[incr i] >= 100} {
> +	    fail "$name (no progress after 100 steps)"
> +	    return
> +	}
> +    }
> +}
> +
> +test_i "stepi to next line" "stepi" \
> +       ".*${decimal}.*a.*5.* = a.*3" \
> +       ".*${decimal}.*callee.*STEPI"
> +
> +test_i "stepi into function" "stepi" \
> +       ".*${decimal}.*callee.*STEPI" \
> +       ".*callee \\(\\) at .*step-alarm\\.c" 
> +
> +# Continue to step until we reach the function's body.  This makes it
> +# more likely that we've actually completed the prologue, so "finish"
> +# will work.
> +test_i "stepi into function's first source line" "stepi" \
> +	".*${decimal}.*\\{" \
> +	".*${decimal}.*myglob"
> +
> +# Have to be careful here, if the finish does not work, 
> +# then we may run to the end of the program, which
> +# will cause erroneous failures in the rest of the tests
> +send_gdb "finish\n"
> +gdb_expect {
> +  -re ".*(Program received|Program exited).*$gdb_prompt $" {
> +    # Oops... We ran to the end of the program...  Better reset     
> +    if {![runto_main]} then {
> +      fail "Can't run to main"
> +      return 0
> +    }
> +    if {![runto step-alarm.c:57]} {
> +      fail "Can't run to line 57"
> +      return 0
> +    }
> +    fail "stepi: finish call"
> +  }
> +  -re ".*${decimal}.*callee.*NEXTI.*$gdb_prompt $" {
> +    pass "stepi: finish call"
> +  }
> +  -re ".*${decimal}.*callee.*STEPI.*$gdb_prompt $" {
> +    # On PA64, we end up at a different instruction than PA32.
> +    # On IA-64, we end up on callee instead of on the following line due
> +    # to the restoration of the global pointer.
> +    if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"] } {
> +        pass "stepi: finish call 2"
> +    } else {
> +	fail "stepi: finish call 2"
> +        return
> +    }
> +  }
> +  -re "$gdb_prompt $" {
> +    # We got something else.  Fail.
> +    fail "stepi: finish call"
> +    return
> +  }
> +  timeout {
> +    fail "stepi: finish call (timeout)"
> +    return
> +  }
> +}
> +
> +test_i "nexti over function" "nexti" \
> +       ".*${decimal}.*callee.*NEXTI" \
> +       ".*${decimal}.*y = w \\+ z;"
> +
> +return 0
> --- /dev/null	Thu Feb 19 16:30:24 1998
> +++ testsuite/gdb.base/step-alarm.c	Sat May 20 01:01:21 2000
> @@ -0,0 +1,65 @@
> +#include <signal.h>
> +#include <stdio.h>
> +#include <sys/time.h>
> +
> +/* Test stepping with a pending signal.  */
> +
> +int myglob = 0;
> +
> +int callee (void)
> +{
> +  myglob++;
> +  return 0;
> +}
> +
> +static void
> +handler (int signum)
> +{
> +}
> +
> +int
> +main (void)
> +{
> +  struct sigaction sa;
> +  struct itimerval it;
> +  int w, x, y, z;
> +  int a[10];
> +
> +  sa.sa_handler = handler;
> +  sigemptyset (&sa.sa_mask);
> +  sa.sa_flags = 0;
> +  sigaction (SIGALRM, &sa, NULL);
> +
> +  it.it_interval.tv_usec = 5000;
> +  it.it_interval.tv_sec = 0;
> +  it.it_value.tv_usec = 5000;
> +  it.it_value.tv_sec = 0;
> +  setitimer (ITIMER_REAL, &it, NULL);
> +
> +  /* Test "next" and "step" */
> +  w = 0;
> +  x = 1;
> +  y = 2;
> +  z = 3;
> +  w = w + 2;
> +  x = x + 3;
> +  y = y + 4;
> +  z = z + 5;
> +
> +  /* Test that "next" goes over a call */
> +  callee(); /* OVER */
> +
> +  /* Test that "step" doesn't */
> +  callee(); /* INTO */
> +
> +  /* Test "stepi"  */
> +  a[5] = a[3] - a[4];
> +  callee(); /* STEPI */
> +
> +  /* Test "nexti" */
> +  callee(); /* NEXTI */
> +  
> +  y = w + z;
> +
> +  exit (0);
> +}
> 
> 

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Michael Snyder]

Andrew Cagney wrote:
> 
> Anyone?

I think the test is good.  Just a couple of comments:
1) There are a couple of instances of the following:
  if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"]} {
      send_gdb "finish\n"
      gdb_expect {
          -re ".*${decimal}.*a.*5.*= a.*3.*$gdb_prompt $" { pass "step out 1" }
          -re ".*${decimal}.*callee.*INTO.*$gdb_prompt $" { pass "step out 2" }
          timeout { fail "step out" }
      }
  } else {
      gdb_test "finish" ".*${decimal}.*a.*5.*= a.*3.*" "step out"
  }
I think that the "hppa2.0" clause should be used for all targets, 
because there are numerous targets on which a "finish" command will
end up on the same line as the function call, rather than on the 
next line.  I don't think it is important enough to try to 
distinguish which targets can expect this behavior -- instead, 
it is good enough to just accept either result.

2) Do the gnu coding standards apply to testsuite source files?
If so, "callee()" should be replaced by "callee ()".

Michael

\x13

> 
>         Andrew
> 
> > Here's the test I promised Andrew a while ago for the fix for the
> > problem reported by Jonathan Larmour:
> >
> >    http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
> >
> > The fix has already been checked in, the problem is still mentioned in
> > the TODO file (let's keep it there until this test has been added).
> >
> > I verified that some of these tests (the "stepi" and "nexti" tests)
> > do fail without my fix to infrun.c.
> >
> > I'm not sure to what extent the use of setitimer() is portable.
> > However, it is hard to come up with a test that doesn't use it.
> >
> >
> > 2000-05-20  Mark Kettenis  <kettenis@gnu.org>
> >
> > Add tests for stepping with pending signals.
> >       * gdb.base/step-alarm.exp: New file.
> >       * gdb.base/step-alarm.c: New file.
> >
> >
> > --- /dev/null Thu Feb 19 16:30:24 1998
> > +++ testsuite/gdb.base/step-alarm.exp Sat May 20 01:09:56 2000
> > @@ -0,0 +1,226 @@
> > +# Copyright (C) 1997, 1998, 1999, 2000 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
> > +# the Free Software Foundation; either version 2 of the License, or
> > +# (at your option) any later version.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +# GNU General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU General Public License
> > +# along with this program; if not, write to the Free Software
> > +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
> > +
> > +# Please email any bugs, comments, and/or additions to this file to:
> > +# bug-gdb@gnu.org
> > +
> > +# use this to debug:
> > +#
> > +#log_user 1
> > +
> > +# step-alarm.exp -- Expect script to test stepping in gdb
> > +#                   with a pending signals
> > +
> > +# Most of this script is copied over from step-test.exp.  We run (almost)
> > +# the same tests, except that we set a timer and install a SIGALRM signal
> > +# handler.  The addition of these tests was prompted by the following fix:
> > +#
> > +# 2000-05-01  Mark Kettenis  <kettenis@gnu.org>
> > +#
> > +#    * infrun.c (handle_inferior_event): Add missing call to keep_going
> > +#    and missing return when handling an ordinary signal from the
> > +#    inferior.
> > +#
> > +# for a problem where "stepi" didn't make any progress if a signal
> > +# was pending.
> > +
> > +if $tracelevel then {
> > +    strace $tracelevel
> > +}
> > +
> > +set testfile step-alarm
> > +set srcfile ${srcdir}/${subdir}/${testfile}.c
> > +set binfile ${objdir}/${subdir}/${testfile}
> > +
> > +remote_exec build "rm -f ${binfile}"
> > +if { [gdb_compile "${srcfile}" "${binfile}" executable {debug}] != "" } {
> > +     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}
> > +
> > +if ![runto_main] then {
> > +   fail "Can't run to main"
> > +   return 0
> > +}
> > +
> > +# Make sure that the signal handler is installed, and the timer is set.
> > +#
> > +gdb_test "break [gdb_get_line_number "w = 0"]" \
> > +         ".*Breakpoint.* at .*" \
> > +         "set breakpoint after timer activation"
> > +gdb_test "continue" \
> > +      ".*Breakpoint ${decimal},.*w = 0.*" \
> > +      "run until timer is activated"
> > +
> > +
> > +# Set a breakpoint at line 57, if stepi then finish fails, we would
> > +# run to the end of the program, which would mess up the rest of the tests.
> > +
> > +# Vanilla step/next
> > +#
> > +gdb_test "next" ".*${decimal}.*x = 1;.*" "next 1"
> > +gdb_test "step" ".*${decimal}.*y = 2;.*" "step 1"
> > +
> > +# With count
> > +#
> > +gdb_test "next 2" ".*${decimal}.*w = w.*2;.*" "next 2"
> > +gdb_test "step 3" ".*${decimal}.*z = z.*5;.*" "step 3"
> > +gdb_test "next" ".*${decimal}.*callee.*OVER.*" "next 3"
> > +
> > +# Step over call
> > +#
> > +gdb_test "next" ".*${decimal}.*callee.*INTO.*" "next over"
> > +
> > +# Step into call
> > +#
> > +gdb_test "step" ".*${decimal}.*myglob.*"   "step into"
> > +
> > +# Step out of call
> > +#
> > +# I wonder if this is really portable.  Are there any caller-saves
> > +# platforms, on which `finish' will return you to some kind of pop
> > +# instruction, which is attributed to the line containing the function
> > +# call?
> > +
> > +# On PA64, we end up at a different instruction than PA32.
> > +# On IA-64, we also end up on callee instead of on the next line due
> > +# to the restoration of the global pointer (which is a caller-save).
> > +if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"]} {
> > +    send_gdb "finish\n"
> > +    gdb_expect {
> > +        -re ".*${decimal}.*a.*5.*= a.*3.*$gdb_prompt $" { pass "step out 1" }
> > +        -re ".*${decimal}.*callee.*INTO.*$gdb_prompt $" { pass "step out 2" }
> > +        timeout { fail "step out" }
> > +    }
> > +} else {
> > +    gdb_test "finish" ".*${decimal}.*a.*5.*= a.*3.*" "step out"
> > +}
> > +
> > +### Testing nexti and stepi.
> > +###
> > +### test_i NAME COMMAND HERE THERE
> > +###
> > +### Send COMMAND to gdb over and over, while the output matches the
> > +### regexp HERE, followed by the gdb prompt.  Pass if the output
> > +### eventually matches the regexp THERE, followed by the gdb prompt;
> > +### fail if we have to iterate more than a hundred times, we time out
> > +### talking to gdb, or we get output which is neither HERE nor THERE.  :)
> > +###
> > +### Use NAME as the name of the test.
> > +###
> > +### The exact regexps used are "$HERE.*$gdb_prompt $"
> > +###                        and "$THERE.*$gdb_prompt $"
> > +###
> > +proc test_i {name command here there} {
> > +    global gdb_prompt
> > +
> > +    set i 0
> > +    while 1 {
> > +     send_gdb "${command}\n"
> > +     gdb_expect {
> > +         -re "$here.*$gdb_prompt $" {
> > +             # Okay, we're still on the same line.  Just step again.
> > +         }
> > +         -re "$there.*$gdb_prompt $" {
> > +             # We've reached the next line.  Rah.
> > +             pass "$name"
> > +             return
> > +         }
> > +         -re "$gdb_prompt $" {
> > +             # We got something else.  Fail.
> > +             fail "$name"
> > +             return
> > +         }
> > +         timeout {
> > +             fail "$name (timeout)"
> > +             return
> > +         }
> > +     }
> > +
> > +     # Have we gone for too many steps without seeing any progress?
> > +     if {[incr i] >= 100} {
> > +         fail "$name (no progress after 100 steps)"
> > +         return
> > +     }
> > +    }
> > +}
> > +
> > +test_i "stepi to next line" "stepi" \
> > +       ".*${decimal}.*a.*5.* = a.*3" \
> > +       ".*${decimal}.*callee.*STEPI"
> > +
> > +test_i "stepi into function" "stepi" \
> > +       ".*${decimal}.*callee.*STEPI" \
> > +       ".*callee \\(\\) at .*step-alarm\\.c"
> > +
> > +# Continue to step until we reach the function's body.  This makes it
> > +# more likely that we've actually completed the prologue, so "finish"
> > +# will work.
> > +test_i "stepi into function's first source line" "stepi" \
> > +     ".*${decimal}.*\\{" \
> > +     ".*${decimal}.*myglob"
> > +
> > +# Have to be careful here, if the finish does not work,
> > +# then we may run to the end of the program, which
> > +# will cause erroneous failures in the rest of the tests
> > +send_gdb "finish\n"
> > +gdb_expect {
> > +  -re ".*(Program received|Program exited).*$gdb_prompt $" {
> > +    # Oops... We ran to the end of the program...  Better reset
> > +    if {![runto_main]} then {
> > +      fail "Can't run to main"
> > +      return 0
> > +    }
> > +    if {![runto step-alarm.c:57]} {
> > +      fail "Can't run to line 57"
> > +      return 0
> > +    }
> > +    fail "stepi: finish call"
> > +  }
> > +  -re ".*${decimal}.*callee.*NEXTI.*$gdb_prompt $" {
> > +    pass "stepi: finish call"
> > +  }
> > +  -re ".*${decimal}.*callee.*STEPI.*$gdb_prompt $" {
> > +    # On PA64, we end up at a different instruction than PA32.
> > +    # On IA-64, we end up on callee instead of on the following line due
> > +    # to the restoration of the global pointer.
> > +    if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"] } {
> > +        pass "stepi: finish call 2"
> > +    } else {
> > +     fail "stepi: finish call 2"
> > +        return
> > +    }
> > +  }
> > +  -re "$gdb_prompt $" {
> > +    # We got something else.  Fail.
> > +    fail "stepi: finish call"
> > +    return
> > +  }
> > +  timeout {
> > +    fail "stepi: finish call (timeout)"
> > +    return
> > +  }
> > +}
> > +
> > +test_i "nexti over function" "nexti" \
> > +       ".*${decimal}.*callee.*NEXTI" \
> > +       ".*${decimal}.*y = w \\+ z;"
> > +
> > +return 0
> > --- /dev/null Thu Feb 19 16:30:24 1998
> > +++ testsuite/gdb.base/step-alarm.c   Sat May 20 01:01:21 2000
> > @@ -0,0 +1,65 @@
> > +#include <signal.h>
> > +#include <stdio.h>
> > +#include <sys/time.h>
> > +
> > +/* Test stepping with a pending signal.  */
> > +
> > +int myglob = 0;
> > +
> > +int callee (void)
> > +{
> > +  myglob++;
> > +  return 0;
> > +}
> > +
> > +static void
> > +handler (int signum)
> > +{
> > +}
> > +
> > +int
> > +main (void)
> > +{
> > +  struct sigaction sa;
> > +  struct itimerval it;
> > +  int w, x, y, z;
> > +  int a[10];
> > +
> > +  sa.sa_handler = handler;
> > +  sigemptyset (&sa.sa_mask);
> > +  sa.sa_flags = 0;
> > +  sigaction (SIGALRM, &sa, NULL);
> > +
> > +  it.it_interval.tv_usec = 5000;
> > +  it.it_interval.tv_sec = 0;
> > +  it.it_value.tv_usec = 5000;
> > +  it.it_value.tv_sec = 0;
> > +  setitimer (ITIMER_REAL, &it, NULL);
> > +
> > +  /* Test "next" and "step" */
> > +  w = 0;
> > +  x = 1;
> > +  y = 2;
> > +  z = 3;
> > +  w = w + 2;
> > +  x = x + 3;
> > +  y = y + 4;
> > +  z = z + 5;
> > +
> > +  /* Test that "next" goes over a call */
> > +  callee(); /* OVER */
> > +
> > +  /* Test that "step" doesn't */
> > +  callee(); /* INTO */
> > +
> > +  /* Test "stepi"  */
> > +  a[5] = a[3] - a[4];
> > +  callee(); /* STEPI */
> > +
> > +  /* Test "nexti" */
> > +  callee(); /* NEXTI */
> > +
> > +  y = w + z;
> > +
> > +  exit (0);
> > +}
> >
> >

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Andrew Cagney wrote:
> 
> Anyone?
> 
>         Andrew
> 
> > Here's the test I promised Andrew a while ago for the fix for the
> > problem reported by Jonathan Larmour:
> >
> >    http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
> >
> > The fix has already been checked in, the problem is still mentioned in
> > the TODO file (let's keep it there until this test has been added).
> >
> > I verified that some of these tests (the "stepi" and "nexti" tests)
> > do fail without my fix to infrun.c.
> >
> > I'm not sure to what extent the use of setitimer() is portable.
> > However, it is hard to come up with a test that doesn't use it.
> >
> >
> > 2000-05-20  Mark Kettenis  <kettenis@gnu.org>
> >
> > Add tests for stepping with pending signals.
> >       * gdb.base/step-alarm.exp: New file.
> >       * gdb.base/step-alarm.c: New file.
> >
> >

> > +        -re ".*${decimal}.*a.*5.*= a.*3.*$gdb_prompt $" { pass "step out 1" }
> > +        -re ".*${decimal}.*callee.*INTO.*$gdb_prompt $" { pass "step out 2" }

These should be just "step out"


> > +      fail "Can't run to main"
> > +      fail "Can't run to line 57"

> > +        pass "stepi: finish call 2"
> > +     fail "stepi: finish call 2"

These should just be "stepi: finish call"



W.r.t. the tests for HP and IA64 I sincerely regret that we do not have two commands: "finishi" and "finish".  The current behavior of "finish" (stop at the assembler instruction after the call) is very unsettling for someone who is doing source level debugging  --  in this case it should, after returning, single step until the end of the sourceline where the call is ("if it is not at the beginning of a source line after the return, single step to the end of it" would do).


Anyway, since we have such weird behavior, I agree that, in this specific case, we can accept both results as there is always a possibility that arbitrary targets will have extra instructions in a source line after the call instruction.



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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Daniel Jacobowitz]

On Mon, Jul 09, 2001 at 05:21:26PM -0400, Fernando Nasser wrote:
> W.r.t. the tests for HP and IA64 I sincerely regret that we do not
> have two commands: "finishi" and "finish".  The current behavior of
> "finish" (stop at the assembler instruction after the call) is very
> unsettling for someone who is doing source level debugging -- in this
> case it should, after returning, single step until the end of the
> sourceline where the call is ("if it is not at the beginning of a
> source line after the return, single step to the end of it" would
> do).

I think that the current behavior of finish, while awkward, is better
than what you're suggesting here.  Suppose we have:
  foo (bar (x));
and we want to step in to foo.  There's two ways to do it; a breakpoint
on foo, or step - finish - step.  Stepping in to bar, typing finish,
and ending up after the call to foo would be exceedingly non-intuitive.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Daniel Jacobowitz]

On Mon, Jul 09, 2001 at 06:13:16PM -0400, Fernando Nasser wrote:
> > Stepping in to bar, typing finish,
> > and ending up after the call to foo would be exceedingly non-intuitive.
> > 
> 
> This is true. But a finish would not stop after the call to foo() in
> this case.  The stepping would be aborted as we entered foo() itself
> (note that I said "step", not "next").  The result is quite intuitive
> in this case and you just provided one good example of how we could
> use it -- one could go "finish"-ing until the desired function was
> entered (without the need to step again and without the weird thing
> of appearing to stop at the same line you were before).

I personally think that this would be more confusing - I finish a
function and end up, not in its caller, but in some other function
called from the caller?  But I've no strong opinion; both options seem
a little clunky.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Daniel Jacobowitz wrote:
> 
> On Mon, Jul 09, 2001 at 06:13:16PM -0400, Fernando Nasser wrote:
> > > Stepping in to bar, typing finish,
> > > and ending up after the call to foo would be exceedingly non-intuitive.
> > >
> >
> > This is true. But a finish would not stop after the call to foo() in
> > this case.  The stepping would be aborted as we entered foo() itself
> > (note that I said "step", not "next").  The result is quite intuitive
> > in this case and you just provided one good example of how we could
> > use it -- one could go "finish"-ing until the desired function was
> > entered (without the need to step again and without the weird thing
> > of appearing to stop at the same line you were before).
> 
> I personally think that this would be more confusing - I finish a
> function and end up, not in its caller, but in some other function
> called from the caller?  But I've no strong opinion; both options seem
> a little clunky.
> 

Of course, this could be made an option, so different tastes are accommodated (default to current behavior).  But I won't have time to implement it in the near future, so you don't have to worry about it :-)

Regards and thanks for the comments,
Fernando

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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Michael Snyder]

Fernando Nasser wrote:
> 
> Daniel Jacobowitz wrote:
> >
> > On Mon, Jul 09, 2001 at 05:21:26PM -0400, Fernando Nasser wrote:
> > > W.r.t. the tests for HP and IA64 I sincerely regret that we do not
> > > have two commands: "finishi" and "finish".  The current behavior of
> > > "finish" (stop at the assembler instruction after the call) is very
> > > unsettling for someone who is doing source level debugging -- in this
> > > case it should, after returning, single step until the end of the
> > > sourceline where the call is ("if it is not at the beginning of a
> > > source line after the return, single step to the end of it" would
> > > do).
> >
> > I think that the current behavior of finish, while awkward, is better
> > than what you're suggesting here.  Suppose we have:
> >   foo (bar (x));
> > and we want to step in to foo.  There's two ways to do it; a breakpoint
> > on foo, or step - finish - step.
> 
> The breakpoint is the correct way.  The latter is an artifact.

I must disagree.  Often, when you reach this line and you 
want to step into foo, you will not notice the call to bar
until it is too late and you have stepped into bar.

When that happens, the only way to reach foo is to "finish" from
bar, and then step again.

If the debugger forces the "finish" to reach the next line, 
the user will be very frustrated.

> 
> > Stepping in to bar, typing finish,
> > and ending up after the call to foo would be exceedingly non-intuitive.
> >
> 
> This is true. But a finish would not stop after the call to foo() in this case.  The stepping would be aborted as we entered foo() itself (note that I said "step", not "next").  The result is quite intuitive in this case and you just provided one good example of how we could use it -- one could go "finish"-ing until the desired function was entered (without the need to step again and without the weird thing of appearing to stop at the same line you were before).
> 
> --
> Fernando Nasser
> Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Michael Snyder wrote:
> 
> I must disagree.  Often, when you reach this line and you
> want to step into foo, you will not notice the call to bar
> until it is too late and you have stepped into bar.
> 
> When that happens, the only way to reach foo is to "finish" from
> bar, and then step again.
> 

As I have explained in this thread (one month ago), the single stepping
caused by finish would stop as soon as foo is entered -- exactly the
behavior you want.


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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Andrew Cagney]

> Michael Snyder wrote:
> 
>> 
>> I must disagree.  Often, when you reach this line and you
>> want to step into foo, you will not notice the call to bar
>> until it is too late and you have stepped into bar.
>> 
>> When that happens, the only way to reach foo is to "finish" from
>> bar, and then step again.
>> 
> 
> 
> As I have explained in this thread (one month ago), the single stepping
> caused by finish would stop as soon as foo is entered -- exactly the
> behavior you want.


I think that would be very counter intuitive.  The primatives are:

	o	step executes instructions until you
		leave the current line
		(be it enter a function or reach a new
		line)

	o	finish leaves the current function
		(reducing the stack depth by one)

	Andrew

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Andrew Cagney wrote:
> 
> > Michael Snyder wrote:
> >
> >>
> >> I must disagree.  Often, when you reach this line and you
> >> want to step into foo, you will not notice the call to bar
> >> until it is too late and you have stepped into bar.
> >>
> >> When that happens, the only way to reach foo is to "finish" from
> >> bar, and then step again.
> >>
> >
> >
> > As I have explained in this thread (one month ago), the single stepping
> > caused by finish would stop as soon as foo is entered -- exactly the
> > behavior you want.
> 
> I think that would be very counter intuitive.  The primatives are:
> 
>         o       step executes instructions until you
>                 leave the current line
>                 (be it enter a function or reach a new
>                 line)
> 

'step' should never leave you in the same line from where you've issued
it.  That is counter intuitive, even if you had a stop-finish in the
middle.

>         o       finish leaves the current function
>                 (reducing the stack depth by one)

Exactly.  We are talking about a source line with 'foo (bar ())' on it.

The problem (as I said one month ago) is that we do not have a "finishi'
which could perfectly leave the program at the return point, without
concerns of return value handling, source line numbers etc.  But
"finish" is a source level command and source level commands should not
leave you in the middle of source lines.

Once finished the call it was in it should either:
1) stop at the beginning of the next source level instruction -- the one
after the call (remember, it is a source level command)
2) stop after the prolog of a subroutine if there is another call in the
same originating upper level source line.


When the user issues a "step" on 'foo (bar ())' source line, he/she may
want to enter either bar() or foo().  We cannot know that, so we must
stop at each one and he/she can go to the next by issuing "finish",
i.e., "finish _this_ subroutine".  When he/she doesn't want to stop
anymore (i.e., bar() was the one they were interested into), a "next"
can be used.




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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Eli Zaretskii]

On Thu, 26 Jul 2001, Fernando Nasser wrote:

> "finish" is a source level command and source level commands should not
> leave you in the middle of source lines.

I think I could agree with the general principle, but the wording is 
probably somewhat ambiguous.  We could have 

> 
> Once finished the call it was in it should either:
> 1) stop at the beginning of the next source level instruction -- the one
> after the call (remember, it is a source level command)
> 2) stop after the prolog of a subroutine if there is another call in the
> same originating upper level source line.
> 
> 
> When the user issues a "step" on 'foo (bar ())' source line, he/she may
> want to enter either bar() or foo().  We cannot know that, so we must
> stop at each one and he/she can go to the next by issuing "finish",
> i.e., "finish _this_ subroutine".  When he/she doesn't want to stop
> anymore (i.e., bar() was the one they were interested into), a "next"
> can be used.
> 
> 
> 
> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
> 

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Eli Zaretskii]

On Thu, 26 Jul 2001, I wrote:

> 
> On Thu, 26 Jul 2001, Fernando Nasser wrote:
> 
> > "finish" is a source level command and source level commands should not
> > leave you in the middle of source lines.
> 
> I think I could agree with the general principle, but the wording is 
> probably somewhat ambiguous.  We could have 

Sorry, please disregard this.

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Eli Zaretskii]

On Thu, 26 Jul 2001, Fernando Nasser wrote:

> >         o       step executes instructions until you
> >                 leave the current line
> >                 (be it enter a function or reach a new
> >                 line)
> > 
> 
> 'step' should never leave you in the same line from where you've issued
> it.  That is counter intuitive, even if you had a stop-finish in the
> middle.

Agreed.

> "finish" is a source level command and source level commands should not
> leave you in the middle of source lines.

I'm not sure I understand what you mean here (or that you mean what I 
understand ;-).  We could have a source line like this:

	int i = (foo (), bar ());

or even like this:

	int i = foo (); bar ();

Where would you suggest that "finish" leaves you in these cases, and what 
does ``in the middle of source lines'' mean in these cases?  Also, do you 
think these two cases are fundamentally different from "foo (bar ());", 
and if so, how are they different?

> When the user issues a "step" on 'foo (bar ())' source line, he/she may
> want to enter either bar() or foo().  We cannot know that, so we must
> stop at each one and he/she can go to the next by issuing "finish",
> i.e., "finish _this_ subroutine".

Now I'm confused: this seems to suggest that the first "step" gets her 
inside bar(), and if she then types "finish", she will be after the call 
to bar(), but before the call to foo() (that's how I interpret ``finish 
_this_ subroutine'').  But that is in the middle of a source line, which 
seems to contradict your previous requirement.

What am I missing?

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Eli Zaretskii wrote:
> 
> On Thu, 26 Jul 2001, Fernando Nasser wrote:
> 
> > >         o       step executes instructions until you
> > >                 leave the current line
> > >                 (be it enter a function or reach a new
> > >                 line)
> > >
> >
> > 'step' should never leave you in the same line from where you've issued
> > it.  That is counter intuitive, even if you had a stop-finish in the
> > middle.
> 
> Agreed.
> 
> > "finish" is a source level command and source level commands should not
> > leave you in the middle of source lines.
> 
> I'm not sure I understand what you mean here (or that you mean what I
> understand ;-).  We could have a source line like this:
> 
>         int i = (foo (), bar ());
> 
> or even like this:
> 
>         int i = foo (); bar ();
> 
> Where would you suggest that "finish" leaves you in these cases, and what
> does ``in the middle of source lines'' mean in these cases?  Also, do you
> think these two cases are fundamentally different from "foo (bar ());",
> and if so, how are they different?
> 

All are the same.  "step" gets into foo(), a "finish" finishes foo(),
but then there is bar() so you stop there next.  Another "finish" and
you will stop on the line that follows the above lines.

Note that a "finishi" command would leave you at the return point at
some PC in the middle of the above source lines.  



> > When the user issues a "step" on 'foo (bar ())' source line, he/she may
> > want to enter either bar() or foo().  We cannot know that, so we must
> > stop at each one and he/she can go to the next by issuing "finish",
> > i.e., "finish _this_ subroutine".
> 
> Now I'm confused: this seems to suggest that the first "step" gets her
> inside bar(), and if she then types "finish", she will be after the call
> to bar(), but before the call to foo() (that's how I interpret ``finish
> _this_ subroutine'').  But that is in the middle of a source line, which
> seems to contradict your previous requirement.
> 

No, that would be a "finishi" (assemble level debugging).  For the
"finish (source level debugging) see above.


Regards,
Fernando


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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Eli Zaretskii]

On Thu, 26 Jul 2001, Fernando Nasser wrote:

> >         int i = (foo (), bar ());
> > 
> > or even like this:
> > 
> >         int i = foo (); bar ();
> > 
> > Where would you suggest that "finish" leaves you in these cases, and what
> > does ``in the middle of source lines'' mean in these cases?  Also, do you
> > think these two cases are fundamentally different from "foo (bar ());",
> > and if so, how are they different?
> 
> All are the same.  "step" gets into foo(), a "finish" finishes foo(),
> but then there is bar() so you stop there next.

So you are saying that "finish" should run all the way until the first 
call exits, then print the return value (if any), and then do one more 
"step" automatically, to get inside of the second call, is that it?

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Eli Zaretskii wrote:
> 
> On Thu, 26 Jul 2001, Fernando Nasser wrote:
> 
> > >         int i = (foo (), bar ());
> > >
> > > or even like this:
> > >
> > >         int i = foo (); bar ();
> > >
> > > Where would you suggest that "finish" leaves you in these cases, and what
> > > does ``in the middle of source lines'' mean in these cases?  Also, do you
> > > think these two cases are fundamentally different from "foo (bar ());",
> > > and if so, how are they different?
> >
> > All are the same.  "step" gets into foo(), a "finish" finishes foo(),
> > but then there is bar() so you stop there next.
> 
> So you are saying that "finish" should run all the way until the first
> call exits, then print the return value (if any), and then do one more
> "step" automatically, to get inside of the second call, is that it?

Yes, but it does it to leave the line with the call.  As any step, it will stop if there is a call in the way.  That is why it will stop at the second.

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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Just to clarify one thing: I did not post any RFC/RFA for a change in the GDB CLI command set.

A month or so ago I made a comment, when we were discussing some testsuite changes, about a _what if_ scenario where we would have a "finishi" command.  For the sake of intellectual exercise of a few interested parties, a few details of this _what if_ scenario were discussed. As it was just an exercise, the thing died up quickly.

Suddenly, someone found the old thread and made a comment (perhaps without re-reading the complete old thread?) and I don't know how the whole thing started to be refereed to as "proposed changes"!

Although I still believe that we should have two commands and that they should try and behave at the abstraction level they are defined to, I am not proposing any changes.  So, unless someone is really considering the possibility of adding a command or two, in which case I would gladly continue the discussion until we reach some conclusion, I suggest that we may just resume our regular activities.

Regards to all,
Fernando


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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Andrew Cagney]

> 
> All are the same.  "step" gets into foo(), a "finish" finishes foo(),
> but then there is bar() so you stop there next.  Another "finish" and
> you will stop on the line that follows the above lines.
> 
> Note that a "finishi" command would leave you at the return point at
> some PC in the middle of the above source lines.  


So what happens if you're sitting in foo() and type finish but the 
previous command wasn't step.  Do you still find yourself in bar()?

> 
> 'step' should never leave you in the same line from where you've issued
> it.  That is counter intuitive, even if you had a stop-finish in the
> middle.


This actually throws me.  Reading it one way it suggests that ``step ; 
finish'' should have special behavour.  See question above.

Anyway try thinking of ``finish'' as a special form of step.  What 
happens if you step through foo()?  When foo() exits do you jump to 
bar() or go back to the caller?

	Andrew

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Andrew Cagney wrote:
> 
> >
> > All are the same.  "step" gets into foo(), a "finish" finishes foo(),
> > but then there is bar() so you stop there next.  Another "finish" and
> > you will stop on the line that follows the above lines.
> >
> > Note that a "finishi" command would leave you at the return point at
> > some PC in the middle of the above source lines.
> 
> So what happens if you're sitting in foo() and type finish but the
> previous command wasn't step.  Do you still find yourself in bar()?
> 

The current model is that one can switch between the source and assembler debugging at any time by issuing a control command with "i" or without it.  So the previous command does not matter -- what matters is if you issued "finish" or "finishi".

> >
> > 'step' should never leave you in the same line from where you've issued
> > it.  That is counter intuitive, even if you had a stop-finish in the
> > middle.
> 
> This actually throws me.  Reading it one way it suggests that ``step ;
> finish'' should have special behavour.  See question above.
> 

No (see above).

> Anyway try thinking of ``finish'' as a special form of step.  What
> happens if you step through foo()?  When foo() exits do you jump to
> bar() or go back to the caller?
> 

"step" over a subroutine return should behave like "finish" from any other point in that subroutine.  A "stepi" should do what "finishi" would do.

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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Andrew Cagney]

> 
> The current model is that one can switch between the source and assembler debugging at any time by issuing a control command with "i" or without it.  So the previous command does not matter -- what matters is if you issued "finish" or "finishi".


I'm sorry but I think this getting silly.

Think about my example, you step out of the current function only to 
find you've landed in a totally different function that doesn't even 
appear on the call stack!

	Andrew

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Andrew Cagney wrote:
> 
> >
> > The current model is that one can switch between the source and assembler debugging at any time by issuing a control command with "i" or without it.  So the previous command does not matter -- what matters is if you issued "finish" or "finishi".
> 
> I'm sorry but I think this getting silly.
> 

I have the same feeling....

> Think about my example, you step out of the current function only to
> find you've landed in a totally different function that doesn't even
> appear on the call stack!
> 

But it appears on the source code line.  Again, thinking assembler debugging is different from thinking source level debugging.



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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Michael Snyder]

Fernando Nasser wrote:
> 
> Michael Snyder wrote:
> >
> > I must disagree.  Often, when you reach this line and you
> > want to step into foo, you will not notice the call to bar
> > until it is too late and you have stepped into bar.
> >
> > When that happens, the only way to reach foo is to "finish" from
> > bar, and then step again.
> >
> 
> As I have explained in this thread (one month ago), the single stepping
> caused by finish would stop as soon as foo is entered -- exactly the
> behavior you want.

But that's not the behavior I want.  "Finish"
should take me to the function that called bar.
Foo did not call bar.

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Michael Snyder wrote:
> 
> Fernando Nasser wrote:
> >
> > Michael Snyder wrote:
> > >
> > > I must disagree.  Often, when you reach this line and you
> > > want to step into foo, you will not notice the call to bar
> > > until it is too late and you have stepped into bar.
> > >
> > > When that happens, the only way to reach foo is to "finish" from
> > > bar, and then step again.
> > >
> >
> > As I have explained in this thread (one month ago), the single stepping
> > caused by finish would stop as soon as foo is entered -- exactly the
> > behavior you want.
> 
> But that's not the behavior I want.  "Finish"
> should take me to the function that called bar.
> Foo did not call bar.


It depends on how you're thinking about it.  You are thinking
"assembler", which calls bar(), stores the result and then calls foo().

You you think source code, the line is:

foo (bar ());

It is like peeling an onion.  The outermost shell (the last stop) is
foo().  But before you have to go through bar() and any other inner
calls.


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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Michael Snyder]

Fernando Nasser wrote:
> 
> Michael Snyder wrote:
> >
> > Fernando Nasser wrote:
> > >
> > > Michael Snyder wrote:
> > > >
> > > > I must disagree.  Often, when you reach this line and you
> > > > want to step into foo, you will not notice the call to bar
> > > > until it is too late and you have stepped into bar.
> > > >
> > > > When that happens, the only way to reach foo is to "finish" from
> > > > bar, and then step again.
> > > >
> > >
> > > As I have explained in this thread (one month ago), the single stepping
> > > caused by finish would stop as soon as foo is entered -- exactly the
> > > behavior you want.
> >
> > But that's not the behavior I want.  "Finish"
> > should take me to the function that called bar.
> > Foo did not call bar.
> 
> It depends on how you're thinking about it.  You are thinking
> "assembler", which calls bar(), stores the result and then calls foo().

No, I'm thinking "finish", which means "take me back
one stack frame."  It does not mean "and then finish
executing the line from which the call took place".
That's a separate operation.

> 
> You you think source code, the line is:
> 
> foo (bar ());
> 
> It is like peeling an onion.  The outermost shell (the last stop) is
> foo().  But before you have to go through bar() and any other inner
> calls.
> 
> --
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Fernando Nasser]

Michael Snyder wrote:
> 
> No, I'm thinking "finish", which means "take me back
> one stack frame." 

That is not the meaning of "finish" as an English word.  And for GDB it
means: "finish executing the current subroutine".  

Where it should stop is a consequence of that.  And this is what we are
discussing.



> It does not mean "and then finish
> executing the line from which the call took place".
> That's a separate operation.

You are still thinking "assembler".


There are two distinct paradigms" "source level debugging" and
"assembler level debugging".  They are similar but not equal.


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

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Stan Shebs]

Michael Elizabeth Chastain wrote:
> 
> Michael Snyder writes:
> > 2) Do the gnu coding standards apply to testsuite source files?
> > If so, "callee()" should be replaced by "callee ()".
> 
> I recall seeing somewhere that the testsuite programs should come in
> a variety of styles, because gcc and gdb should work on all legal
> programs, not just those written to the GNU coding standards.
> 
> I don't have a reference though.

I suggested this a couple years ago, probably around the time of
the Big Reformat. :-)  The theory was to not force the testsuite
to be a "monoculture" of code all in the same style, on the off
chance that maybe someday we'll catch a source listing or line
number bug that would not be noticed in GNU-formatted code.

Stan

Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix

[Michael Elizabeth Chastain]

Ah, I have an example in the existing test suite.

gdb.base/funcargs.c has several functions with one-line bodies:

  #ifdef PROTOTYPES
  void call5a (struct stag st)
  #else
  call5a (st)
  struct stag st;
  #endif
  {st.s1 = 5;}

In some configurations, this causes problems because gcc optimizes away
the stabn for the end of the prologue.  gdb needs that stabn; without
that stabn, it ultimately comes up with a bogus place to breakpoint and
thus prints incorrect values of the "st" argument.

I've seen this happen on native i686-pc-cygwin and native i686-pc-linux
with a gcc v2 compiler.  I haven't seen it happen with a gcc v3 compiler.
I haven't filed a bug report yet.

The bug depends on the fact that the whole function body is one line.
The Gnu Coding Standard prohibits this:

  http://www.gnu.org/prep/standards_22.html#SEC22

MichaelC