From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: kevinb@cygnus.com Cc: msnyder@cygnus.com, ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com, shebs@apple.com Subject: Re: [PATCH]: annota1.exp testsuite tweak Date: Fri, 19 May 2000 12:33:00 -0000 Message-id: <200005191933.e4JJXNU00372@delius.kettenis.local> References: <200005190019.RAA04889@seadog.cygnus.com> <1000519190926.ZM3497@ocotillo.lan> X-SW-Source: 2000-05/msg00307.html Date: Fri, 19 May 2000 12:09:26 -0700 From: Kevin Buettner 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 > > * 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 To: Kevin Buettner 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 > > > > * 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 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 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 +# +# * 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 +#include +#include + +/* 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 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 To: Mike Peck Cc: gdb-patches@sourceware.cygnus.com, GDB Discussion 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 ? > 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 #endif #ifdef HAVE_TERM_H #include #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 To: GDB Patches 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 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: 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?