Re: [PATCH]: annota1.exp testsuite tweak

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Fri, 19 May 2000 12:09:26 -0700
   From: Kevin Buettner <kevinb@cygnus.com>

   On May 18,  5:19pm, msnyder@cygnus.com wrote:

   > This is a minor adjustment to a regular expression; having fewer 
   > wildcards gets it to pass on Solaris 8 where it was failing before.
   > It's actually more explicit than before.
   > 
   > 2000-05-18  Michael Snyder  <msnyder@seadog.cygnus.com>
   > 
   >         * gdb.base/annota1.exp (annotate-signal-handler-caller):
   >         Relax the regular expression a little, make it pass on Solaris 8.

   I'm not a testsuite maintainer, but I think this patch should be
   approved.  I tried it out on my IA-64 GNU/Linux box and this test
   passed very quickly whereas, before, it would run for over 10 minutes
   and then evenutally fail due to timing out.

I haven't tested it yet on my system, but I expect that the same holds
for GNU/Linux/x86.  It's probably related to the fact that with glibc
there is an extra frame.

   Thanks for fixing this problem.

Yeah!

Mark
From msnyder@cygnus.com Fri May 19 13:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com, shebs@apple.com
Subject: Re: [PATCH (RFA/RFC)]: annota1.exp testsuite tweak
Date: Fri, 19 May 2000 13:00:00 -0000
Message-id: <39259C98.39F8@cygnus.com>
References: <200005190019.RAA04889@seadog.cygnus.com> <1000519190926.ZM3497@ocotillo.lan>
X-SW-Source: 2000-05/msg00308.html
Content-length: 1020

Kevin Buettner wrote:
> 
> On May 18,  5:19pm, msnyder@cygnus.com wrote:
> 
> > This is a minor adjustment to a regular expression; having fewer
> > wildcards gets it to pass on Solaris 8 where it was failing before.
> > It's actually more explicit than before.
> >
> > 2000-05-18  Michael Snyder  <msnyder@seadog.cygnus.com>
> >
> >         * gdb.base/annota1.exp (annotate-signal-handler-caller):
> >         Relax the regular expression a little, make it pass on Solaris 8.
> 
> I'm not a testsuite maintainer, but I think this patch should be
> approved.  I tried it out on my IA-64 GNU/Linux box and this test
> passed very quickly whereas, before, it would run for over 10 minutes
> and then evenutally fail due to timing out.

That's what I get.  I think it's actually an expect or dejagnu
bug, but this works around it.

> (Note to Michael:  You might want to put RFA or RFC or some sort in
> the subject line next time.  When I first read it, I thought it had
> already been applied.)

Good suggestion, thanks.
From kettenis@wins.uva.nl Fri May 19 16:21:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Cc: cagney@cygnus.com
Subject: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix
Date: Fri, 19 May 2000 16:21:00 -0000
Message-id: <200005192321.e4JNLEv13368@delius.kettenis.local>
X-SW-Source: 2000-05/msg00309.html
Content-length: 9014

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);
+}
From ac131313@cygnus.com Fri May 19 17:10:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: remove target_memory_bfdsection and assorted cruft.
Date: Fri, 19 May 2000 17:10:00 -0000
Message-id: <3925D7B5.18FE080F@cygnus.com>
References: <5mln17471t.fsf@jtc.redback.com>
X-SW-Source: 2000-05/msg00310.html
Content-length: 225

"J.T. Conklin" wrote:
> 
> I submit the enclosed changes for approval.


J.T.

To follow up David's response.  Assume the remainder is approved.  As
you note it was discussed to death earlier.
Thanks for closing it,

	Andrew
From ac131313@cygnus.com Fri May 19 23:01:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mike Peck <allnight@webcom.com>
Cc: gdb-patches@sourceware.cygnus.com, GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: Problems building 5.0 on Solaris 8 x86
Date: Fri, 19 May 2000 23:01:00 -0000
Message-id: <392629E3.41EB3DB@cygnus.com>
References: <3926078B.54E7FAA3@webcom.com>
X-SW-Source: 2000-05/msg00311.html
Content-length: 2221

[reply-to set to gdb-patches]

Mike Peck wrote:

> gcc -c -O3    -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode
> -I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl
> -I./../intl -I./tui  -DUSE_INCLUDED_REGEX   utils.c
> In file included from utils.c:31:
> /usr/include/term.h:1034: parse error before `bool'
> /usr/include/term.h:1034: warning: no semicolon at end of struct or

As a work around, can you try deleting the #include <term.h>?

> I would really prefer to be on a released version, so if anyone knows
> what's up with this, I'd appreciate some help.  Also, why this
> flip-flopped between 4.18, the 4/19 snapshot, and later snapshots/5.0
> kinda confuses me.  Did something get backed out of the source, since
> that's what it looks like?

(4/19 is the ``-D 2000-04-19-gmt -r gdb_5_0-2000-04-10-branch''
snapshot)

I'm somewhat puzzled.  The only change to utils.c post branch was:

cagney@b1.cygnus.com$ cvs diff -p -r gdb_5_0-2000-04-10-branchpoint -r
gdb_5_0-2000-05-19-release utils.c
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.6
retrieving revision 1.6.2.1
diff -p -r1.6 -r1.6.2.1
*** utils.c     2000/03/30 18:54:28     1.6
--- utils.c     2000/04/21 04:10:46     1.6.2.1
*************** restore_my_cleanups (pmy_chain, chain)
*** 375,384 ****
     to arrange to free the object thus allocated.  */
  
  void
! free_current_contents (location)
!      char **location;
  {
!   free (*location);
  }
  
  /* Provide a known function that does nothing, to use as a base for
--- 375,385 ----
     to arrange to free the object thus allocated.  */
  
  void
! free_current_contents (void *ptr)
  {
!   void **location = ptr;
!   if (*location != NULL)
!     free (*location);
  }
  
  /* Provide a known function that does nothing, to use as a base for


There has been another report of a system having problems with:

#ifdef HAVE_CURSES_H
#include <curses.h>
#endif
#ifdef HAVE_TERM_H
#include <term.h>
#endif

but that was tracked down to a scrambled /usr/include directory.  On
your system, which of these headers are installed and where (check
$builddir/gdb/config.h)?

	Andrew
From ac131313@cygnus.com Sat May 20 00:14:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: sizeof diff (gdb-5.0, trunk) > 1mb
Date: Sat, 20 May 2000 00:14:00 -0000
Message-id: <39263B15.A4B9E854@cygnus.com>
X-SW-Source: 2000-05/msg00312.html
Content-length: 349

Trivia,

For what it is worth, there are more than 1mb of differences between
gdb-5.0 release and the current trunk (and that is just within GDB)! 
This hopefully suggests that releasing GDB 5.0 didn't bog down any going
development of GDB.

On top of this, the GDB 5.0 branch managed to separatly accumulate some
400k of patches.

	enjoy,
		Andrew
From aoliva@cygnus.com Sat May 20 00:21:00 2000
From: Alexandre Oliva <aoliva@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: GDB 5.0 won't build on GNU/Linux/sparc
Date: Sat, 20 May 2000 00:21:00 -0000
Message-id: <oraehlelgf.fsf@tamanduatei.dcc.unicamp.br>
X-SW-Source: 2000-05/msg00313.html
Content-length: 829

gdb/sparc-tdep.c contains code in supply_gregset() and fill_gregset()
that will only compile on Solaris/sparc.  glibc doesn't define
prgreg_t, R_I7, R_PS, R_PC, R_nPC nor R_Y.  In fact, registers from i0
to i7 aren't even available in glibc's gregset.  The solution is to
disable USE_PROC_FS, which can be accomplished by #including the
generic config/nm-linux.h from config/sparc/nm-linux.h, as all other
architecture-specific `nm-linux.h's do (actually, it's also missing
from config/powerpc/nm-linux.h).  Unfortunately, I don't have access to a
GNU/Linux/powerpc platform to test the second change.  On
GNU/Linux/sparc, it builds correctly, but it still doesn't work :-(
child_resume is called with step==1, and aborts because
SOFTWARE_SINGLE_STEP_P is also 1.  I'm investigating.  Meanwhile, ok
to install?  Release branch?