This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[commit, testsuite] Fix spurious foll-fork.exp failures


Hello,

when hitting a fork catchpoint, GDB will show the current location, which
happens to be whatever routine within libc that actually performs the fork
system call.  The foll-fork.exp test case now goes and verifies that this
catchpoint hits at a location it expects.

However, the name of that function may be platform dependent: it could be
called simply "fork", or some derivative like "__fork", but on some systems
there are helper routines like "__kernel_syscall" or "__kernel_vsyscall"
that actually do the system call.

While foll-fork.exp regexps match those variants, on ARM the call is done
by a routine called __libc_do_syscall (which might not even by recognizable
by GDB if libc is stripped).  This causes spurious failures of the test.

On the other hand, some of those regexps are so vague they accidentally
even match on ARM.  For example, this regexp

    gdb_test "continue" "in .*(fork|__kernel_v?syscall).*" \

matches 

Reading in symbols for ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S...done.^M
^M
Catchpoint 14 (forked process 5150), __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S:47^M
47      ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S: No such file or directory.^M
        in ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S^M
Current language:  auto^M
The current source language is "auto; currently asm".^M


(The "in" from "Reading in symbols" followed by "fork" from
"forked process 5150".)

It seems to me that it's really no business of the test how libc is
structured internally, and which subroutine actually issues the
system call.  On the other hand, the regexps should be tightened
to actually match the specific "Catchpoint ..." messages.

The following patch implements this.  Tested on armv7l-linux-gnueabi
and i386-linux.  Fixes spurious failures on ARM.

Committed to mainline.

Bye,
Ulrich


ChangeLog:

	* gdb.base/foll-fork.exp: Make regexps to match catchpoint hits more
	strict, but do not check for any particular function name within libc.

Index: gdb/testsuite/gdb.base/foll-fork.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/foll-fork.exp,v
retrieving revision 1.20
diff -u -p -r1.20 foll-fork.exp
--- gdb/testsuite/gdb.base/foll-fork.exp	1 Jun 2010 21:29:21 -0000	1.20
+++ gdb/testsuite/gdb.base/foll-fork.exp	19 Oct 2010 17:27:03 -0000
@@ -122,7 +122,7 @@ proc catch_fork_child_follow {} {
 
     set bp_after_fork [gdb_get_line_number "set breakpoint here"]
 
-    gdb_test "catch fork" "Catchpoint .*(fork).*" \
+    gdb_test "catch fork" "Catchpoint \[0-9\]* \\(fork\\)" \
 	"explicit child follow, set catch fork"
 
     # Verify that the catchpoint is mentioned in an "info breakpoints",
@@ -136,7 +136,7 @@ proc catch_fork_child_follow {} {
     }
 
     gdb_test "continue" \
-	"Catchpoint.*(forked process.*),.*in .*(fork|__kernel_v?syscall).*" \
+	"Catchpoint \[0-9\]* \\(forked process \[0-9\]*\\),.*" \
 	"explicit child follow, catch fork"
 
     # Verify that the catchpoint is mentioned in an "info breakpoints",
@@ -184,7 +184,7 @@ proc catch_fork_unpatch_child {} {
 	"unpatch child, set catch fork"
 
     gdb_test "continue" \
-	"Catchpoint.*\\(forked process.*\\).*,.*in .*(fork|__kernel_v?syscall).*" \
+	"Catchpoint \[0-9\]* \\(forked process \[0-9\]*\\),.*" \
 	"unpatch child, catch fork"
 
     # Delete all breakpoints and catchpoints.
@@ -225,14 +225,15 @@ proc tcatch_fork_parent_follow {} {
 
     set bp_after_fork [gdb_get_line_number "set breakpoint here"]
 
-    gdb_test "catch fork" "Catchpoint .*(fork).*" \
+    gdb_test "catch fork" "Catchpoint \[0-9\]* \\(fork\\)" \
 	"explicit parent follow, set tcatch fork"
 
 # ??rehrauer: I don't yet know how to get the id of the tcatch
 # via this script, so that I can add a -do list to it.  For now,
 # do the follow stuff after the catch happens.
 
-    gdb_test "continue" "in .*(fork|__kernel_v?syscall).*" \
+    gdb_test "continue" \
+	"Catchpoint \[0-9\]* \\(forked process \[0-9\]*\\),.*" \
 	"explicit parent follow, tcatch fork"
 
     gdb_test_no_output "set follow-fork parent"
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]