From: Joel Brobecker <brobecker@gnat.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA/testsuite] test hand function call in commands list
Date: Mon, 14 Apr 2003 15:40:00 -0000 [thread overview]
Message-ID: <20030414154048.GC1151@gnat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]
The attached patch to break.exp was written by Klee Dienes and
submitted in the following message:
http://sources.redhat.com/ml/gdb-patches/2002-10/msg00586.html
The purpose of the test is to make sure that a problem occuring with
function calls inside a commands list does not cause a SIGSEGV.
2003-04-14 J. Brobecker <brobecker@gnat.com>
From Klee Dienne <kdienes@apple.com>
* gdb.base/break.exp: Add multiple calls to the inferior in
the user-commands for 'break 79'. Add a check for the calls
to the inferior in the check for the result. Add new test, to
check that user-defined breakpoint commands are called for functions
called by the user (currently fails).
When I ran the test, I was very surprised to see one FAIL. I am
describing below the symptoms (no time to investigate this today), but I
think the test is worthwhile adding anyway. Ok to apply?
Here is a small description of the problem:
The test itself inserted a breakpoint in marker2. It then makes a hand
function call to this function. Here is the output from the logs:
| print marker2(99)
|
| Breakpoint 26, marker2 (a=99) at ./gdb.base/break.c:49 <<<---
| 49 int marker2 (a) int a; { return (1); }
| The program being debugged stopped while in a function called from GDB.
| When the function (marker2) is done executing, GDB will silently
| stop (instead of continuing to evaluate the expression containing
| the function call).
Klee's patch then adds a commands list to the breakpoint in maker2:
| commands 26
| Type commands for when breakpoint 26 is hit, one per line.
| End with a line saying just "end".
| >silent
| >call (int) printf ("PREFIXbobo\n" + (int) strlen ("PREFIXbobo\n") - 5)
| >end
And calls marker2 again:
| print marker2(99)
| The program being debugged stopped while in a function called from GDB.
| When the function (marker2) is done executing, GDB will silently
| stop (instead of continuing to evaluate the expression containing
| the function call).
The fact that GDB did not print the breakpoint number shows that GDB
started evaluating the commands list. However, we did not get the
output from the printf command, which means that the evaluation stopped
prematurely for some reason.
I will be happy to have a look at this problem sometime in the future.
But, if somebody else would like to have a look, no problem either.
Thanks,
--
Joel
[-- Attachment #2: break.exp.diff --]
[-- Type: text/plain, Size: 4430 bytes --]
Index: break.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/break.exp,v
retrieving revision 1.17
diff -c -3 -p -r1.17 break.exp
*** break.exp 5 Apr 2003 13:35:25 -0000 1.17
--- break.exp 14 Apr 2003 14:46:41 -0000
*************** gdb_expect {
*** 423,429 ****
}
# Verify that a "silent" breakpoint can be set, and that GDB is indeed
! # "silent" about its triggering.
#
if ![runto_main] then { fail "break tests suppressed" }
--- 423,431 ----
}
# Verify that a "silent" breakpoint can be set, and that GDB is indeed
! # "silent" about its triggering. Include multiple nested calls to the
! # inferior in the user-commands for the breakpoint, to verify that the
! # cleanup code isn't trashing stop_bpstat.
#
if ![runto_main] then { fail "break tests suppressed" }
*************** gdb_expect {
*** 438,443 ****
--- 440,446 ----
send_gdb "commands $expect_out(1,string)\n"
send_gdb "silent\n"
+ send_gdb "call (int) printf (\"PREFIXbobo\\n\" + (int) strlen (\"PREFIXbobo\\n\") - 5)\n"
send_gdb "end\n"
gdb_expect {
-re ".*$gdb_prompt $"\
*************** gdb_expect {
*** 455,461 ****
}
send_gdb "continue\n"
gdb_expect {
! -re "Continuing.\r\n$gdb_prompt $"\
{pass "hit silent break 79"}
-re "$gdb_prompt $"\
{fail "hit silent break 79"}
--- 458,464 ----
}
send_gdb "continue\n"
gdb_expect {
! -re "Continuing.\r\nbobo\r\n\\\$\[0-9\]* = 5\r\n$gdb_prompt $"\
{pass "hit silent break 79"}
-re "$gdb_prompt $"\
{fail "hit silent break 79"}
*************** gdb_expect {
*** 585,590 ****
--- 588,600 ----
{fail "set breakpoint on to-be-called function"}
timeout {fail "(timeout) set breakpoint on to-be-called function"}
}
+
+ # save the breakpoint identifier for future use
+ #
+ set marker2_bpnum $expect_out(1,string)
+
+ # Call the function.
+ #
send_gdb "print marker2(99)\n"
gdb_expect {
-re "The program being debugged stopped while in a function called from GDB.\r\nWhen the function .marker2$proto. is done executing, GDB will silently\r\nstop .instead of continuing to evaluate the expression containing\r\nthe function call...*$gdb_prompt $"\
*************** gdb_expect {
*** 609,614 ****
--- 619,664 ----
-re "$gdb_prompt $"\
{fail "backtrace while in called function"}
timeout {fail "(timeout) backtrace while in called function"}
+ }
+
+ # Return from the called function. For remote targets, it's important to do
+ # this before runto_main, which otherwise may silently stop on the dummy
+ # breakpoint inserted by GDB at the program's entry point.
+ #
+ send_gdb "finish\n"
+ gdb_expect {
+ -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.* in _sr4export.*$gdb_prompt $"\
+ {pass "finish from called function"}
+ -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.*function called from gdb.*$gdb_prompt $"\
+ {pass "finish from called function"}
+ -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.*Value returned.*$gdb_prompt $"\
+ {pass "finish from called function"}
+ -re "$gdb_prompt $"\
+ {fail "finish from called function"}
+ timeout {fail "(timeout) finish from called function"}
+ }
+
+ # Add a user-command that calls the inferior to the breakpoint for marker2.
+ #
+ send_gdb "commands $marker2_bpnum\n"
+ send_gdb "silent\n"
+ send_gdb "call (int) printf (\"PREFIXbobo\\n\" + (int) strlen (\"PREFIXbobo\\n\") - 5)\n"
+ send_gdb "end\n"
+ gdb_expect {
+ -re ".*$gdb_prompt $"\
+ {pass "set printf break marker2"}
+ timeout {fail "(timeout) set printf break marker2"}
+ }
+
+ # Call the function again.
+ #
+ send_gdb "print marker2(99)\n"
+ gdb_expect {
+ -re "The program being debugged stopped while in a function called from GDB.\r\nWhen the function .marker2$proto. is done executing, GDB will silently\r\nstop .instead of continuing to evaluate the expression containing\r\nthe function call...*bobo.*$gdb_prompt $"\
+ {pass "called user-defined function on breakpoint in called function"}
+ -re "$gdb_prompt $"\
+ {fail "called user-defined function on breakpoint in called function"}
+ timeout {fail "called user-defined function on breakpoint in called function"}
}
# Return from the called function. For remote targets, it's important to do
next reply other threads:[~2003-04-14 15:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 15:40 Joel Brobecker [this message]
2003-04-16 14:23 ` Daniel Jacobowitz
2003-04-16 23:09 ` Joel Brobecker
2003-04-17 2:40 ` Daniel Jacobowitz
2003-04-23 0:50 ` Joel Brobecker
2003-04-23 2:42 ` Michael Snyder
2003-06-29 20:11 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030414154048.GC1151@gnat.com \
--to=brobecker@gnat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox