2026-01-05 08:13:29 -07:00
|
|
|
# Copyright (C) 2008-2026 Free Software Foundation, Inc.
|
2008-08-06 19:41:33 +00:00
|
|
|
|
|
|
|
|
# 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 3 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, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
|
|
# This file is part of the GDB testsuite. It tests the mechanism
|
|
|
|
|
# exposing values to Python.
|
|
|
|
|
|
2010-10-01 17:03:50 +00:00
|
|
|
load_lib gdb-python.exp
|
|
|
|
|
|
* gdb.python/lib-types.exp: Use standard_testfile,
prepare_for_testing.
* gdb.python/py-block.exp: Use standard_testfile.
* gdb.python/py-breakpoint.exp: Use standard_testfile.
* gdb.python/py-events.exp: Use standard_testfile,
standard_output_file.
* gdb.python/py-evsignal.exp: Use standard_testfile.
* gdb.python/py-evethreads.exp: Use standard_testfile.
* gdb.python/py-explore-cc.exp: Use standard_testfile.
* gdb.python/py-explore.exp: Use standard_testfile.
* gdb.python/py-finish-breakpoint.exp: Use standard_testfile,
standard_output_file.
* gdb.python/py-finish-breakpoint2.exp: Use standard_testfile,
prepare_for_testing.
* gdb.python/py-frame-inline.exp: Use standard_testfile.
* gdb.python/py-frame.exp: Use standard_testfile.
* gdb.python/py-inferior.exp: Use standard_testfile.
* gdb.python/py-infthread.exp: Use standard_testfile.
* gdb.python/py-mi.exp: Use standard_testfile.
* gdb.python/py-objfile-script.exp: Use standard_testfile,
build_executable.
* gdb.python/py-objfile.exp: Use standard_testfile.
* gdb.python/py-pp-maint.exp: Use standard_testfile,
prepare_for_testing.
* gdb.python/py-prettyprint.exp: Use standard_testfile.
* gdb.python/py-progspace.exp: Use standard_testfile,
build_executable.
* gdb.python/py-prompt.exp: Use standard_testfile,
build_executable.
* gdb.python/py-section-script.exp: Use standard_testfile,
build_executable.
* gdb.python/py-shared.exp: Use standard_testfile,
standard_output_file, clean_restart.
* gdb.python/py-symbol.exp: Use standard_output_file,
prepare_for_testing.
* gdb.python/py-symtab.exp: Use standard_output_file,
prepare_for_testing
* gdb.python/py-template.exp: Use standard_testfile.
* gdb.python/py-type.exp: Use standard_testfile.
* gdb.python/py-value-cc.exp: Use standard_testfile.
* gdb.python/py-value.exp: Use standard_testfile.
* gdb.python/python.exp: Use standard_testfile, build_executable.
2012-06-22 17:59:33 +00:00
|
|
|
standard_testfile python.c python-1.c
|
|
|
|
|
|
|
|
|
|
if {[build_executable $testfile.exp $testfile \
|
|
|
|
|
[list $srcfile $srcfile2] debug] == -1} {
|
2026-04-29 20:04:13 -03:00
|
|
|
return
|
2010-08-11 12:48:24 +00:00
|
|
|
}
|
2008-08-06 19:41:33 +00:00
|
|
|
|
2023-01-25 14:48:55 -07:00
|
|
|
clean_restart
|
2008-08-06 19:41:33 +00:00
|
|
|
|
2014-08-14 14:16:56 +08:00
|
|
|
set remote_source2_py [gdb_remote_download host \
|
|
|
|
|
${srcdir}/${subdir}/source2.py]
|
|
|
|
|
|
2013-11-23 15:08:28 -08:00
|
|
|
# Do this instead of the skip_python_check.
|
|
|
|
|
# We want to do some tests when Python is not present.
|
2012-12-10 21:22:21 +00:00
|
|
|
gdb_test_multiple "python print (23)" "verify python support" {
|
2008-08-06 19:41:33 +00:00
|
|
|
-re "not supported.*$gdb_prompt $" {
|
|
|
|
|
unsupported "python support is disabled"
|
2010-01-18 06:31:24 +00:00
|
|
|
|
|
|
|
|
# If Python is not supported, verify that sourcing a python script
|
|
|
|
|
# causes an error.
|
2014-08-14 14:16:56 +08:00
|
|
|
gdb_test "source $remote_source2_py" \
|
2011-10-18 14:14:01 +00:00
|
|
|
"Error in sourced command file:.*" \
|
|
|
|
|
"source source2.py when python disabled"
|
2014-03-22 02:44:39 -04:00
|
|
|
|
|
|
|
|
# Verify multi-line python commands cause an error.
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "multi-line python command" \
|
2014-03-22 02:44:39 -04:00
|
|
|
"python" "" \
|
|
|
|
|
"print (23)" "" \
|
|
|
|
|
"end" "not supported.*"
|
|
|
|
|
|
2026-04-29 20:04:15 -03:00
|
|
|
return
|
2008-08-06 19:41:33 +00:00
|
|
|
}
|
|
|
|
|
-re "$gdb_prompt $" {}
|
|
|
|
|
}
|
|
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "multi-line python command" \
|
2008-08-06 19:41:33 +00:00
|
|
|
"python" "" \
|
2012-12-10 21:22:21 +00:00
|
|
|
"print (23)" "" \
|
2008-08-06 19:41:33 +00:00
|
|
|
"end" "23"
|
|
|
|
|
|
PR python/17372 - Python hangs when displaying help()
This is more of a readline/terminal issue than a Python one.
PR17372 is a regression in 7.8 caused by the fix for PR17072:
commit 0017922d0292d8c374584f6100874580659c9973
Author: Pedro Alves <palves@redhat.com>
Date: Mon Jul 14 19:55:32 2014 +0100
Background execution + pagination aborts readline/gdb
gdb_readline_wrapper_line removes the handler after a line is
processed. Usually, we'll end up re-displaying the prompt, and that
reinstalls the handler. But if the output is coming out of handling
a stop event, we don't re-display the prompt, and nothing restores the
handler. So the next input wakes up the event loop and calls into
readline, which aborts.
...
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* top.c (gdb_readline_wrapper_line): Tweak comment.
(gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
the input handler callback.
The problem is that installing the input handler callback also preps
the terminal, putting it in raw mode and with echo disabled, which is
bad if we're going to call a command that assumes cooked/canonical
mode, and echo enabled, like in the case of the PR, Python's
interactive shell. Another example I came up with that doesn't depend
on Python is starting a subshell with "(gdb) shell /bin/sh" from a
multi-line command. Tests covering both these examples are added.
The fix is to revert the original fix for PR gdb/17072, and instead
restore the callback handler after processing an asynchronous target
event.
Furthermore, calling rl_callback_handler_install when we already have
some input in readline's line buffer discards that input, which is
obviously a bad thing to do while the user is typing. No specific
test is added for that, because I first tried calling it even if the
callback handler was still installed and that resulted in hundreds of
failures in the testsuite.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* event-top.c (change_line_handler): Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(callback_handler_installed): New global.
(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New functions.
(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
gdb_rl_callback_handler_install instead of
rl_callback_handler_remove and rl_callback_handler_install.
(gdb_disable_readline): Call gdb_rl_callback_handler_remove
instead of rl_callback_handler_remove.
* event-top.h (gdb_rl_callback_handler_remove)
(gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New declarations.
* infrun.c (reinstall_readline_callback_handler_cleanup): New
cleanup function.
(fetch_inferior_event): Install it.
* top.c (gdb_readline_wrapper_line) Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(gdb_readline_wrapper_cleanup): Don't call
rl_callback_handler_install.
gdb/testsuite/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* gdb.python/python.exp: Test a multi-line command that spawns
interactive Python.
* gdb.base/multi-line-starts-subshell.exp: New file.
2014-10-23 17:13:35 +01:00
|
|
|
# Spawn interactive Python help from a multi-line command, thus, after
|
|
|
|
|
# a secondary prompt.
|
|
|
|
|
|
|
|
|
|
with_test_prefix "python interactive help" {
|
|
|
|
|
set test "python; help(); end"
|
|
|
|
|
gdb_test_multiple "python\nhelp()\nend" $test {
|
2014-12-01 08:08:06 -05:00
|
|
|
-re ".*help utility.*help> $" {
|
PR python/17372 - Python hangs when displaying help()
This is more of a readline/terminal issue than a Python one.
PR17372 is a regression in 7.8 caused by the fix for PR17072:
commit 0017922d0292d8c374584f6100874580659c9973
Author: Pedro Alves <palves@redhat.com>
Date: Mon Jul 14 19:55:32 2014 +0100
Background execution + pagination aborts readline/gdb
gdb_readline_wrapper_line removes the handler after a line is
processed. Usually, we'll end up re-displaying the prompt, and that
reinstalls the handler. But if the output is coming out of handling
a stop event, we don't re-display the prompt, and nothing restores the
handler. So the next input wakes up the event loop and calls into
readline, which aborts.
...
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* top.c (gdb_readline_wrapper_line): Tweak comment.
(gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
the input handler callback.
The problem is that installing the input handler callback also preps
the terminal, putting it in raw mode and with echo disabled, which is
bad if we're going to call a command that assumes cooked/canonical
mode, and echo enabled, like in the case of the PR, Python's
interactive shell. Another example I came up with that doesn't depend
on Python is starting a subshell with "(gdb) shell /bin/sh" from a
multi-line command. Tests covering both these examples are added.
The fix is to revert the original fix for PR gdb/17072, and instead
restore the callback handler after processing an asynchronous target
event.
Furthermore, calling rl_callback_handler_install when we already have
some input in readline's line buffer discards that input, which is
obviously a bad thing to do while the user is typing. No specific
test is added for that, because I first tried calling it even if the
callback handler was still installed and that resulted in hundreds of
failures in the testsuite.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* event-top.c (change_line_handler): Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(callback_handler_installed): New global.
(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New functions.
(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
gdb_rl_callback_handler_install instead of
rl_callback_handler_remove and rl_callback_handler_install.
(gdb_disable_readline): Call gdb_rl_callback_handler_remove
instead of rl_callback_handler_remove.
* event-top.h (gdb_rl_callback_handler_remove)
(gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New declarations.
* infrun.c (reinstall_readline_callback_handler_cleanup): New
cleanup function.
(fetch_inferior_event): Install it.
* top.c (gdb_readline_wrapper_line) Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(gdb_readline_wrapper_cleanup): Don't call
rl_callback_handler_install.
gdb/testsuite/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* gdb.python/python.exp: Test a multi-line command that spawns
interactive Python.
* gdb.base/multi-line-starts-subshell.exp: New file.
2014-10-23 17:13:35 +01:00
|
|
|
pass $test
|
|
|
|
|
|
|
|
|
|
# The "quit" must be seen on the output. A buggy GDB
|
|
|
|
|
# would not display it.
|
gdb/testsuite: special case '^' in gdb_test pattern
In this commit I propose that we add special handling for the '^' when
used at the start of a gdb_test pattern. Consider this usage:
gdb_test "some_command" "^command output pattern"
I think the intention here is pretty clear - run 'some_command', and
the output from the command should be exactly 'command output
pattern'.
After the previous commit which tightened up how gdb_test matches the
final newline and prompt we know that the only thing after the output
pattern will be a single newline and prompt, and the leading '^'
ensures that there's no output before 'command output pattern', so
this will do what I want, right?
... except it doesn't. The command itself will also needs to be
matched, so I should really write:
gdb_test "some_command" "^some_command\r\ncommand output pattern"
which will do what I want, right? Well, that's fine until I change
the command and include some regexp character, then I have to write:
gdb_test "some_command" \
"^[string_to_regexp some_command]\r\ncommand output pattern"
but this all gets a bit verbose, so in most cases I simply don't
bother anchoring the output with a '^', and a quick scan of the
testsuite would indicate that most other folk don't both either.
What I propose is this: the *only* thing that can appear immediately
after the '^' is the command converted into a regexp, so lets do that
automatically, moving the work into gdb_test. Thus, when I write:
gdb_test "some_command" "^command output pattern"
Inside gdb_test we will spot the leading '^' in the pattern, and
inject the regexp version of the command after the '^', followed by a
'\r\n'.
My hope is that given this new ability, folk will be more inclined to
anchor their output patterns when this makes sense to do so. This
should increase our ability to catch any unexpected output from GDB
that appears as a result of running a particular command.
There is one problem case we need to consider, sometime people do
this:
gdb_test "" "^expected output pattern"
In this case no command is sent to GDB, but we are still expecting
some output from GDB. This might be a result of some asynchronous
event for example. As there is no command sent to GDB (from the
gdb_test) there will be no command text to parse.
In this case my proposed new feature injects the command regexp, which
is the empty string (as the command itself is empty), but still
injects the '\r\n' after the command regexp, thus we end up with this
pattern:
^\r\nexpected output pattern
This extra '\r\n' is not what we should expected here, and so there is
a special case inside gdb_test -- if the command is empty then don't
add anything after the '^' character.
There are a bunch of tests that do already use '^' followed by the
command, and these can all be simplified in this commit.
I've tried to run all the tests that I can to check this commit, but I
am certain that there will be some tests that I manage to miss.
Apologies for any regressions this commit causes, hopefully fixing the
regressions will not be too hard.
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-29 10:41:07 +01:00
|
|
|
gdb_test "quit" "^\r\nYou are now leaving help.*" "quit help"
|
PR python/17372 - Python hangs when displaying help()
This is more of a readline/terminal issue than a Python one.
PR17372 is a regression in 7.8 caused by the fix for PR17072:
commit 0017922d0292d8c374584f6100874580659c9973
Author: Pedro Alves <palves@redhat.com>
Date: Mon Jul 14 19:55:32 2014 +0100
Background execution + pagination aborts readline/gdb
gdb_readline_wrapper_line removes the handler after a line is
processed. Usually, we'll end up re-displaying the prompt, and that
reinstalls the handler. But if the output is coming out of handling
a stop event, we don't re-display the prompt, and nothing restores the
handler. So the next input wakes up the event loop and calls into
readline, which aborts.
...
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* top.c (gdb_readline_wrapper_line): Tweak comment.
(gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
the input handler callback.
The problem is that installing the input handler callback also preps
the terminal, putting it in raw mode and with echo disabled, which is
bad if we're going to call a command that assumes cooked/canonical
mode, and echo enabled, like in the case of the PR, Python's
interactive shell. Another example I came up with that doesn't depend
on Python is starting a subshell with "(gdb) shell /bin/sh" from a
multi-line command. Tests covering both these examples are added.
The fix is to revert the original fix for PR gdb/17072, and instead
restore the callback handler after processing an asynchronous target
event.
Furthermore, calling rl_callback_handler_install when we already have
some input in readline's line buffer discards that input, which is
obviously a bad thing to do while the user is typing. No specific
test is added for that, because I first tried calling it even if the
callback handler was still installed and that resulted in hundreds of
failures in the testsuite.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* event-top.c (change_line_handler): Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(callback_handler_installed): New global.
(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New functions.
(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
gdb_rl_callback_handler_install instead of
rl_callback_handler_remove and rl_callback_handler_install.
(gdb_disable_readline): Call gdb_rl_callback_handler_remove
instead of rl_callback_handler_remove.
* event-top.h (gdb_rl_callback_handler_remove)
(gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New declarations.
* infrun.c (reinstall_readline_callback_handler_cleanup): New
cleanup function.
(fetch_inferior_event): Install it.
* top.c (gdb_readline_wrapper_line) Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(gdb_readline_wrapper_cleanup): Don't call
rl_callback_handler_install.
gdb/testsuite/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* gdb.python/python.exp: Test a multi-line command that spawns
interactive Python.
* gdb.base/multi-line-starts-subshell.exp: New file.
2014-10-23 17:13:35 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "show python command" \
|
2008-08-06 19:41:33 +00:00
|
|
|
"define zzq" "Type commands for definition of .* just \"end\"\\.*" \
|
|
|
|
|
"python" "" \
|
2012-12-10 21:22:21 +00:00
|
|
|
"print (23)" "" \
|
2008-08-06 19:41:33 +00:00
|
|
|
"end" "" \
|
|
|
|
|
"end" "" \
|
gdb/testsuite: more newline pattern cleanup
After this commit:
commit e2f620135d92f7cd670af4e524fffec7ac307666
Date: Thu Mar 30 13:26:25 2023 +0100
gdb/testsuite: change newline patterns used in gdb_test
It was pointed out in PR gdb/30403 that the same patterns can be found
in other lib/gdb.exp procs and that it would probably be a good idea
if these procs remained in sync with gdb_test. Actually, the bug
specifically calls out gdb_test_multiple when using with '-wrap', but
I found a couple of other locations in gdb_continue_to_breakpoint,
gdb_test_multiline, get_valueof, and get_local_valueof.
In all these locations one or both of the following issues are
addressed:
1. A leading pattern of '[\r\n]*' is pointless. If there is a
newline it will be matched, but if there is not then the testsuite
doesn't care. Also, as expect is happy to skip non-matched output
at the start of a pattern, if there is a newline expect is happy to
skip over it before matching the rest. As such, this leading
pattern is removed.
2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow
unexpected blank lines at the end of a command's output, but also,
if the pattern from the test script ends with a '\r', '\n', or '.'
then these will partially match the trailing newline, with the
remainder of the newline matched by the pattern from gdb.exp. This
split matching doesn't add any value, it's just something that has
appeared as a consequence of how gdb.exp was originally written. In
this case the '\[\r\n\]*' is replaced with '\r\n'.
I've rerun the testsuite and fixed the regressions that I saw, these
were places where GDB emits a blank line at the end of the command
output, which we now need to explicitly match in the test script, this
was for:
gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
gdb.guile/guile.exp
gdb.python/python.exp
Or a location where the test script was matching part of the newline
sequence, while gdb.exp was previously matching the remainder of the
newline sequence. Now we rely on gdb.exp to match the complete
newline sequence, this was for:
gdb.base/commands.exp
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30403
2023-05-02 10:56:55 +01:00
|
|
|
"show user zzq" "User command \"zzq\":.* python.*print \\(23\\).* end\r\n"
|
2008-08-16 20:36:30 +00:00
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "indented multi-line python command" \
|
2008-08-16 20:36:30 +00:00
|
|
|
"python" "" \
|
|
|
|
|
"def foo ():" "" \
|
2012-12-10 21:22:21 +00:00
|
|
|
" print ('hello, world!')" "" \
|
2008-08-16 20:36:30 +00:00
|
|
|
"foo ()" "" \
|
|
|
|
|
"end" "hello, world!"
|
2009-05-28 00:40:24 +00:00
|
|
|
|
2014-08-14 14:16:56 +08:00
|
|
|
gdb_test "source $remote_source2_py" "yes" "source source2.py"
|
2010-01-18 06:31:24 +00:00
|
|
|
|
2019-10-31 23:03:25 +01:00
|
|
|
gdb_test "source -s source2.py" "yes"
|
2011-10-27 15:46:11 +00:00
|
|
|
|
2015-10-26 14:33:19 -07:00
|
|
|
set remote_source2_symlink_notpy \
|
|
|
|
|
[gdb_remote_download host ${srcdir}/${subdir}/source2.py \
|
|
|
|
|
[standard_output_file "source2-symlink.notpy"]]
|
|
|
|
|
set remote_source2_symlink_py [standard_output_file "source2-symlink.py"]
|
|
|
|
|
remote_file host delete $remote_source2_symlink_py
|
|
|
|
|
set status [remote_exec host "ln -sf $remote_source2_symlink_notpy $remote_source2_symlink_py"]
|
|
|
|
|
set test "source -s source2-symlink.py"
|
|
|
|
|
if {[lindex $status 0] == 0} {
|
|
|
|
|
gdb_test "source -s $remote_source2_symlink_py" "yes" $test
|
|
|
|
|
} else {
|
|
|
|
|
unsupported "$test (host does not support symbolic links)"
|
|
|
|
|
}
|
|
|
|
|
|
2012-12-10 21:22:21 +00:00
|
|
|
gdb_test "python print (gdb.current_objfile())" "None"
|
|
|
|
|
gdb_test "python print (gdb.objfiles())" "\\\[\\\]"
|
2010-06-08 16:41:45 +00:00
|
|
|
|
|
|
|
|
# Test http://bugs.python.org/issue4434 workaround in configure.ac
|
2012-12-10 21:22:21 +00:00
|
|
|
gdb_test "python import itertools; print ('IMPOR'+'TED')" "IMPORTED" "pythonX.Y/lib-dynload/*.so"
|
2010-06-25 18:15:18 +00:00
|
|
|
|
|
|
|
|
gdb_test_no_output \
|
|
|
|
|
"python x = gdb.execute('printf \"%d\", 23', to_string = True)"
|
2012-12-10 21:22:21 +00:00
|
|
|
gdb_test "python print (x)" "23"
|
2010-08-07 15:00:39 +00:00
|
|
|
|
2018-04-18 20:10:43 -06:00
|
|
|
gdb_test "python gdb.execute('echo 2\\necho 3\\\\n\\n')" "23" \
|
|
|
|
|
"multi-line execute"
|
2018-11-21 17:06:05 +00:00
|
|
|
gdb_test " " "23" "gdb.execute does not affect repeat history"
|
2018-04-18 20:10:43 -06:00
|
|
|
|
Rewrite output redirection and logging
This patch changes how gdb output redirection is done.
Currently, output is done via the UI. gdb_stdout, for example, is a
define the expands to an lvalue referencing a field in the current UI.
When redirecting, this field may temporarily be reset; and when
logging is enabled or disabled, this is also done.
This has lead to bugs where the combination of redirection and logging
results in use-after-free. Crashes are readily observable; see the
new test cases.
This patch upends this. Now, gdb_stdout is simply an rvalue, and
refers to the current interpreter. The interpreter provides ui_files
that do whatever rewriting is needed (mostly for MI); then output is
forward to the current UI via an indirection (see the new
ui::passthrough_file).
The ui provides paging, logging, timestamps, and the final stream that
writes to an actual file descriptor.
Redirection is handled at the ui layer. Rather than changing the
output pipeline, new ui_files are simply swapped in by rewriting
pointers, hopefully with a scoped_restore.
Redirecting at the ui layer means that interpreter rewriting is still
applied when capturing output. This fixes one of the reported bugs.
Not changing the pipeline means that the problems with the combination
of redirect and logging simply vanish. Logging just changes a flag
and doesn't involve object destruction.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17697
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28620
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28798
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28948
Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-12-06 15:12:37 -06:00
|
|
|
gdb_test_no_output \
|
|
|
|
|
"python x = gdb.execute(\"interpreter-exec mi '-data-evaluate-expression 23'\", to_string=True)" \
|
|
|
|
|
"execute MI command from python"
|
|
|
|
|
gdb_test "python print(x)" \
|
|
|
|
|
"\\^done,value=\"23\"\r\n" \
|
|
|
|
|
"output of MI command"
|
|
|
|
|
|
2010-08-11 20:54:12 +00:00
|
|
|
# Test post_event.
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "post event insertion" \
|
2010-08-11 20:54:12 +00:00
|
|
|
"python" "" \
|
|
|
|
|
"someVal = 0" "" \
|
2010-08-16 18:01:40 +00:00
|
|
|
"class Foo(object):" "" \
|
2010-08-11 20:54:12 +00:00
|
|
|
" def __call__(self):" "" \
|
|
|
|
|
" global someVal" "" \
|
|
|
|
|
" someVal += 1" "" \
|
|
|
|
|
"gdb.post_event(Foo())" "" \
|
|
|
|
|
"end" ""
|
|
|
|
|
|
2012-12-10 21:22:21 +00:00
|
|
|
gdb_test "python print (someVal)" "1" "test post event execution"
|
2024-02-15 13:14:43 -07:00
|
|
|
gdb_test "python gdb.post_event(str(1))" "RuntimeError.*: Posted event is not callable.*" \
|
2018-09-15 00:07:32 -06:00
|
|
|
"test non callable class"
|
|
|
|
|
|
|
|
|
|
send_gdb "python gdb.post_event(lambda: invalid())\n"
|
|
|
|
|
gdb_expect {
|
|
|
|
|
-re "name 'invalid' is not defined" {
|
|
|
|
|
pass "test post_event error on receipt"
|
|
|
|
|
}
|
|
|
|
|
default {
|
|
|
|
|
fail "test post_event error on receipt"
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-08-11 20:54:12 +00:00
|
|
|
|
2010-08-07 15:00:39 +00:00
|
|
|
# Test (no) pagination of the executed command.
|
|
|
|
|
gdb_test "show height" {Number of lines gdb thinks are in a page is unlimited\.}
|
|
|
|
|
set lines 10
|
|
|
|
|
gdb_test_no_output "set height $lines"
|
|
|
|
|
|
|
|
|
|
set test "verify pagination beforehand"
|
2012-12-10 21:22:21 +00:00
|
|
|
gdb_test_multiple "python print (\"\\n\" * $lines)" $test {
|
2025-07-17 22:06:38 +02:00
|
|
|
-re "$pagination_prompt$" {
|
2010-08-07 15:00:39 +00:00
|
|
|
pass $test
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-02-15 13:14:43 -07:00
|
|
|
gdb_test "q" "Quit.*" "verify pagination beforehand: q"
|
2010-08-07 15:00:39 +00:00
|
|
|
|
2025-09-20 14:48:57 +02:00
|
|
|
gdb_test "python if gdb.execute('python print (\"\\\\n\" * $lines)', to_string=True) == \"\\n\" * [expr {$lines + 1}]: print (\"yes\")" "yes" "gdb.execute does not page"
|
2010-08-07 15:00:39 +00:00
|
|
|
|
|
|
|
|
set test "verify pagination afterwards"
|
2012-12-10 21:22:21 +00:00
|
|
|
gdb_test_multiple "python print (\"\\n\" * $lines)" $test {
|
2025-07-17 22:06:38 +02:00
|
|
|
-re "$pagination_prompt$" {
|
2010-08-07 15:00:39 +00:00
|
|
|
pass $test
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-02-15 13:14:43 -07:00
|
|
|
gdb_test "q" "Quit.*" "verify pagination afterwards: q"
|
2010-08-11 12:48:24 +00:00
|
|
|
|
2010-09-11 16:00:27 +00:00
|
|
|
gdb_test_no_output "set height 0"
|
|
|
|
|
|
|
|
|
|
gdb_test_no_output "python a = gdb.execute('help', to_string=True)" "collect help from uiout"
|
|
|
|
|
|
2019-06-23 23:13:57 +02:00
|
|
|
gdb_test "python print (a)" ".*aliases -- User-defined aliases of other commands.*" "verify help to uiout"
|
2010-09-11 16:00:27 +00:00
|
|
|
|
2010-11-23 13:33:23 +00:00
|
|
|
# Test PR 12212, using InfThread.selected_thread() when no inferior is
|
|
|
|
|
# loaded.
|
2023-06-03 22:43:57 +02:00
|
|
|
gdb_py_test_silent_cmd "python nothread = gdb.selected_thread()" "Attempt to acquire thread with no inferior" 1
|
2021-06-07 23:14:55 +01:00
|
|
|
gdb_test "python print (nothread is None)" "True" "ensure that no threads are returned"
|
2010-11-23 13:33:23 +00:00
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "register atexit function" \
|
2012-09-20 20:54:11 +00:00
|
|
|
"python" "" \
|
|
|
|
|
"import atexit" "" \
|
|
|
|
|
"def printit(arg):" "" \
|
2012-12-10 21:22:21 +00:00
|
|
|
" print (arg)" "" \
|
2012-09-20 20:54:11 +00:00
|
|
|
"atexit.register(printit, 'good bye world')" "" \
|
|
|
|
|
"end" ""
|
|
|
|
|
|
|
|
|
|
send_gdb "quit\n"
|
|
|
|
|
gdb_expect {
|
|
|
|
|
-re "good bye world" {
|
|
|
|
|
pass "atexit handling"
|
|
|
|
|
}
|
|
|
|
|
default {
|
|
|
|
|
fail "atexit handling"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-08-11 12:48:24 +00:00
|
|
|
# Start with a fresh gdb.
|
|
|
|
|
clean_restart ${testfile}
|
|
|
|
|
|
|
|
|
|
# The following tests require execution.
|
|
|
|
|
|
2022-11-14 14:12:07 +00:00
|
|
|
if {![runto_main]} {
|
2026-04-29 20:04:14 -03:00
|
|
|
return
|
2010-08-11 12:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
PR gdb/13860: make -interpreter-exec console "list" behave more like "list".
I noticed that "list" behaves differently in CLI vs MI. Particularly:
$ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli
Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli...done.
(gdb) start
Temporary breakpoint 1 at 0x40054d: file ../../../src/gdb/testsuite/gdb.mi/basics.c, line 62.
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli
Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62
62 callee1 (2, "A string argument.", 3.5);
(gdb) list
57 {
58 }
59
60 main ()
61 {
62 callee1 (2, "A string argument.", 3.5);
63 callee1 (2, "A string argument.", 3.5);
64
65 do_nothing (); /* Hello, World! */
66
(gdb)
Note the list started at line 57. IOW, the program stopped at line
62, and GDB centered the list on that.
compare with:
$ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli..."
~"done.\n"
(gdb)
start
&"start\n"
...
~"\nTemporary breakpoint "
~"1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62\n"
~"62\t callee1 (2, \"A string argument.\", 3.5);\n"
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x000000000040054d",func="main",args=[],file="../../../src/gdb/testsuite/gdb.mi/basics.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/basics.c",line="62"},thread-id="1",stopped-threads="all",core="0"
=breakpoint-deleted,id="1"
(gdb)
-interpreter-exec console list
~"62\t callee1 (2, \"A string argument.\", 3.5);\n"
~"63\t callee1 (2, \"A string argument.\", 3.5);\n"
~"64\t\n"
~"65\t do_nothing (); /* Hello, World! */\n"
~"66\t\n"
~"67\t callme (1);\n"
~"68\t callme (2);\n"
~"69\t\n"
~"70\t return 0;\n"
~"71\t}\n"
^done
(gdb)
Here the list starts at line 62, where the program was stopped.
This happens because print_stack_frame, called from both normal_stop
and mi_on_normal_stop, is the function responsible for setting the
current sal from the selected frame, overrides the PRINT_WHAT
argument, and only after that does it decide whether to center the
current sal line or not, based on the overridden value, and it will
always decide false.
(The print_stack_frame call in mi_on_normal_stop is a little different
from the call in normal_stop, in that it is an unconditional
SRC_AND_LOC call. A future patch will make those uniform.)
A previous version of this patch made MI uniform with CLI here, by
making print_stack_frame also center when MI is active. That changed
the output of a "list" command in mi-cli.exp, to expect line 57
instead of 62, as per the example above.
However, looking deeper, that list in question is the first "list"
after the program stops, and right after the stop, before the "list",
the test did "set listsize 1". Let's try the same thing with the CLI:
(gdb) start
62 callee1 (2, "A string argument.", 3.5);
(gdb) set listsize 1
(gdb) list
57 {
Huh, that's unexpected. Why the 57? It's because print_stack_frame,
called in reaction to the breakpoint stop, expecting the next "list"
to show 10 lines (the listsize at the time) around line 62, sets the
lines listed range to 57-67 (62 +/- 5). If the user changes the
listsize before "list", why would we still show that range? Looks
bogus to me.
So the fix for this whole issue should be delay trying to center the
listing to until actually listing, so that the correct listsize can be
taken into account. This makes MI and CLI uniform too, as it deletes
the center code from print_stack_frame.
A series of tests are added to list.exp to cover this. mi-cli.exp was
after all correct all along, but it now gains an additional test that
lists lines with listsize 10, to ensure the centering is consistent
with CLI's.
One related Python test changed related output -- it's a test that
prints the line number after stopping for a breakpoint, similar to the
new list.exp tests. Previously we'd print the stop line minus 5 (due
to the premature centering), now we print the stop line. I think
that's a good change.
Tested on x86_64 Fedora 20.
gdb/
2014-05-21 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (list_command): Handle the first "list" after the
current source line having changed.
* frame.h (set_current_sal_from_frame): Remove 'center' parameter.
* infrun.c (normal_stop): Adjust call to
set_current_sal_from_frame.
* source.c (clear_lines_listed_range): New function.
(set_current_source_symtab_and_line, identify_source_line): Clear
the lines listed range.
(line_info): Handle the first "info line" after the current source
line having changed.
* stack.c (print_stack_frame): Remove center handling.
(set_current_sal_from_frame): Remove 'center' parameter. Don't
center sal.line.
gdb/testsuite/
2014-05-21 Pedro Alves <palves@redhat.com>
* gdb.base/list.exp (build_pattern, test_list): New procedures.
Use them to test variations of "list" after reaching a breakpoint.
* gdb.mi/mi-cli.exp (line_main_callme_2): New global.
Test "list" with listsize 10 after reaching a breakpoint.
* gdb.python/python.exp (decode_line current location line
number): Adjust expected line number.
2014-05-21 23:15:27 +01:00
|
|
|
set lineno [gdb_get_line_number "Break to end."]
|
|
|
|
|
runto $lineno
|
2010-08-11 12:48:24 +00:00
|
|
|
|
|
|
|
|
# Test gdb.decode_line.
|
|
|
|
|
gdb_test "python gdb.decode_line(\"main.c:43\")" \
|
2024-02-15 13:14:43 -07:00
|
|
|
"gdb.error.*: No source file named main.c.*" "test decode_line no source named main"
|
2010-08-11 12:48:24 +00:00
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
with_test_prefix "test decode_line current location" {
|
|
|
|
|
gdb_py_test_silent_cmd "python symtab = gdb.decode_line()" "decode current line" 1
|
|
|
|
|
gdb_test "python print (len(symtab))" "2" "length of result"
|
|
|
|
|
gdb_test "python print (symtab\[0\])" "None" "no unparsed text"
|
|
|
|
|
gdb_test "python print (len(symtab\[1\]))" "1" "length of result locations"
|
|
|
|
|
}
|
2014-09-15 17:40:54 +08:00
|
|
|
|
2019-12-21 09:51:05 -07:00
|
|
|
# Test that decode_line with an empty string argument does not crash.
|
|
|
|
|
gdb_py_test_silent_cmd "python symtab2 = gdb.decode_line('')" \
|
|
|
|
|
"test decode_line with empty string" 1
|
|
|
|
|
|
2014-09-15 17:40:54 +08:00
|
|
|
if { [is_remote host] } {
|
|
|
|
|
set python_c [string_to_regexp "python.c"]
|
|
|
|
|
} else {
|
|
|
|
|
set python_c [string_to_regexp "gdb.python/python.c"]
|
|
|
|
|
}
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
with_test_prefix "test decode_line" {
|
|
|
|
|
gdb_test "python print (symtab\[1\]\[0\].symtab)" ".*${python_c}" "current location filename"
|
|
|
|
|
gdb_test "python print (symtab\[1\]\[0\].line)" "$lineno" "current location line number"
|
|
|
|
|
|
|
|
|
|
gdb_py_test_silent_cmd "python symtab = gdb.decode_line(\"python.c:26 if foo\")" "python.c:26 decode" 1
|
|
|
|
|
gdb_test "python print (len(symtab))" "2" "python.c:26 length 2"
|
|
|
|
|
gdb_test "python print (symtab\[0\])" "if foo" "expression parse"
|
|
|
|
|
gdb_test "python print (len(symtab\[1\]))" "1" "python.c:26 length 1"
|
|
|
|
|
gdb_test "python print (symtab\[1\]\[0\].symtab)" ".*${python_c}" "python.c:26 filename"
|
|
|
|
|
gdb_test "python print (symtab\[1\]\[0\].line)" "26" "python.c:26 line number"
|
|
|
|
|
|
|
|
|
|
gdb_test "python gdb.decode_line(\"randomfunc\")" \
|
2024-02-15 13:14:43 -07:00
|
|
|
"gdb.error.*: Function \"randomfunc\" not defined.*" "randomfunc"
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_py_test_silent_cmd "python symtab = gdb.decode_line(\"func1\")" "func1()" 1
|
|
|
|
|
gdb_test "python print (len(symtab))" "2" "func1 length 2"
|
|
|
|
|
gdb_test "python print (len(symtab\[1\]))" "1" "func1 length 1"
|
|
|
|
|
}
|
2014-09-15 17:40:54 +08:00
|
|
|
|
|
|
|
|
if { [is_remote host] } {
|
|
|
|
|
set python_1_c [string_to_regexp "python-1.c"]
|
|
|
|
|
} else {
|
|
|
|
|
set python_1_c [string_to_regexp "gdb.python/python-1.c"]
|
|
|
|
|
}
|
2016-12-01 14:41:23 -06:00
|
|
|
gdb_test "python print (symtab\[1\]\[0\].symtab)" ".*${python_1_c}" "test decode_line func1 filename"
|
2017-01-20 13:15:36 -06:00
|
|
|
|
|
|
|
|
# Set a default value for func1_lineno in case we fail to fetch the line number
|
|
|
|
|
# below.
|
|
|
|
|
set func1_lineno "noline"
|
|
|
|
|
|
|
|
|
|
# Fetch the line GDB thinks func1 starts at. This may change depending
|
|
|
|
|
# on the architecture and on how GDB handles the prologue of the function.
|
|
|
|
|
gdb_test_multiple "info line func1" "info line func1" {
|
|
|
|
|
-re "Line ($decimal) of .* starts at address $hex <func1> and ends at $hex <func1\\+$decimal>\.\[\r\n\]+$gdb_prompt $" {
|
|
|
|
|
# Fetch the line number.
|
|
|
|
|
set func1_lineno $expect_out(1,string)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_test "python print (symtab\[1\]\[0\].line)" "$func1_lineno" "test decode_line func1 line number"
|
2012-03-30 19:16:52 +00:00
|
|
|
gdb_py_test_silent_cmd {python symtab = gdb.decode_line ("func1,func2")} \
|
|
|
|
|
"test decode_line func1,func2" 1
|
2012-12-10 21:22:21 +00:00
|
|
|
gdb_test {python print (symtab[0])} ",func2" "stop at comma in linespec"
|
2011-03-18 08:44:47 +00:00
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
with_test_prefix "test decode_line" {
|
|
|
|
|
gdb_py_test_silent_cmd "python symtab = gdb.decode_line(\"*0\")" "*0" 1
|
|
|
|
|
gdb_test "python print (len(symtab))" "2" "*0 result length"
|
|
|
|
|
gdb_test "python print (symtab\[0\])" "None" "*0 unparsed"
|
|
|
|
|
gdb_test "python print (len(symtab\[1\]))" "1" "*0 locations length"
|
|
|
|
|
gdb_test "python print (symtab\[1\]\[0\].symtab)" "None" "*0 filename"
|
|
|
|
|
gdb_test "python print (symtab\[1\]\[0\].pc)" "0" "*0 pc"
|
|
|
|
|
}
|
2016-06-20 11:12:14 +02:00
|
|
|
|
2011-03-18 08:44:47 +00:00
|
|
|
# gdb.write
|
2022-08-15 12:45:43 -06:00
|
|
|
gdb_test "python print (sys.stderr)" ".*gdb._GdbFile (instance|object) at.*" "test stderr location"
|
|
|
|
|
gdb_test "python print (sys.stdout)" ".*gdb._GdbFile (instance|object) at.*" "test stdout location"
|
2016-12-01 14:41:23 -06:00
|
|
|
gdb_test "python gdb.write(\"Foo\\n\")" "Foo" "test default write"
|
|
|
|
|
gdb_test "python gdb.write(\"Error stream\\n\", stream=gdb.STDERR)" "Error stream" "test stderr write"
|
|
|
|
|
gdb_test "python gdb.write(\"Normal stream\\n\", stream=gdb.STDOUT)" "Normal stream" "test stdout write"
|
2019-05-17 15:35:08 +01:00
|
|
|
|
2025-09-20 14:48:57 +02:00
|
|
|
if {![gdb_debug_enabled]} {
|
2019-05-17 15:35:08 +01:00
|
|
|
gdb_test "python gdb.write(\"Log stream\\n\", stream=gdb.STDLOG)" "Log stream" "test stdlog write"
|
|
|
|
|
}
|
2011-07-11 13:07:38 +00:00
|
|
|
|
2013-10-01 20:36:01 +00:00
|
|
|
# Turn on full stack printing for subsequent tests.
|
2011-12-16 15:55:40 +00:00
|
|
|
gdb_py_test_silent_cmd "set python print-stack full" \
|
2013-10-01 20:36:01 +00:00
|
|
|
"Set print-stack full for prompt tests" 1
|
2011-07-21 11:03:48 +00:00
|
|
|
|
2026-06-10 11:43:35 +02:00
|
|
|
# Test prompt substitution
|
2011-07-21 11:03:48 +00:00
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "prompt substitution" \
|
2011-07-21 11:03:48 +00:00
|
|
|
"python" "" \
|
|
|
|
|
"someCounter = 0" "" \
|
|
|
|
|
"def prompt(current):" "" \
|
|
|
|
|
" global someCounter" "" \
|
|
|
|
|
" if (current == \"testfake \"):" "" \
|
|
|
|
|
" return None" "" \
|
|
|
|
|
" someCounter = someCounter + 1" "" \
|
|
|
|
|
" return \"py prompt \" + str (someCounter) + \" \"" "" \
|
|
|
|
|
"end" ""
|
|
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "prompt substitution readline" \
|
2011-07-21 11:03:48 +00:00
|
|
|
"python" "" \
|
|
|
|
|
"pCounter = 0" "" \
|
|
|
|
|
"def program_prompt(current):" "" \
|
|
|
|
|
" global pCounter" "" \
|
|
|
|
|
" if (current == \">\"):" "" \
|
|
|
|
|
" pCounter = pCounter + 1" "" \
|
|
|
|
|
" return \"python line \" + str (pCounter) + \": \"" "" \
|
|
|
|
|
" return None" "" \
|
|
|
|
|
"end" ""
|
|
|
|
|
|
|
|
|
|
set newprompt "py prompt 1"
|
|
|
|
|
set newprompt2 "py prompt 2"
|
|
|
|
|
set testfake "testfake"
|
|
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiple "python gdb.prompt_hook = prompt" "set the hook = prompt" {
|
2011-07-21 11:03:48 +00:00
|
|
|
-re "\[\r\n\]$newprompt $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-07-21 11:03:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_test_multiple "set prompt testfake " "set testfake prompt in GDB" {
|
|
|
|
|
-re "\[\r\n\]$testfake $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-07-21 11:03:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_test_multiple "show prompt" "show testfake prompt" {
|
|
|
|
|
-re "Gdb's prompt is \"$testfake \"..* $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-07-21 11:03:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_test_multiple "set prompt blah " "set blah in GDB" {
|
|
|
|
|
-re "\[\r\n\]$newprompt2 $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-07-21 11:03:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-01 14:43:42 -06:00
|
|
|
gdb_test_multiple "python gdb.prompt_hook = None" "delete hook" {
|
2011-07-21 11:03:48 +00:00
|
|
|
-re "\[\r\n\]$newprompt2 $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-07-21 11:03:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_test_multiple "set prompt $gdb_prompt " "set default prompt" {
|
|
|
|
|
-re "\[\r\n\]$gdb_prompt $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-07-21 11:03:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-11-02 21:08:06 +08:00
|
|
|
set working_dir ""
|
|
|
|
|
gdb_test_multiple "pwd" "pwd" {
|
|
|
|
|
-re "Working directory (.*)\\.\[\r\n\]+$gdb_prompt $" {
|
|
|
|
|
set working_dir $expect_out(1,string)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiple "python gdb.prompt_hook = program_prompt" "set the programming hook" {
|
2011-07-21 11:03:48 +00:00
|
|
|
-re "\[\r\n\]$gdb_prompt $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-07-21 11:03:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-10 11:43:35 +02:00
|
|
|
gdb_test_multiple "python" "test we ignore substitution for secondary prompts" {
|
2011-07-21 11:03:48 +00:00
|
|
|
-re "\r\n>$" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-07-21 11:03:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_test_multiple "end" "end programming" {
|
|
|
|
|
-re "\[\r\n\]$gdb_prompt $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-07-21 11:03:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
2011-08-17 10:41:22 +00:00
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "prompt substitution readline import" \
|
2011-08-17 10:41:22 +00:00
|
|
|
"python" "" \
|
|
|
|
|
"import gdb.command.prompt" "" \
|
|
|
|
|
"end" ""
|
|
|
|
|
|
|
|
|
|
gdb_test_multiple "set extended-prompt one two three " \
|
|
|
|
|
"set basic extended prompt" {
|
|
|
|
|
-re "\[\r\n\]one two three $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-08-17 10:41:22 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_test_multiple "set extended-prompt \\w " \
|
|
|
|
|
"set extended prompt working directory" {
|
2014-11-02 21:08:06 +08:00
|
|
|
-re "\[\r\n\][string_to_regexp $working_dir] $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-08-17 10:41:22 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_test_multiple "set extended-prompt some param \\p{python print-stack} " \
|
|
|
|
|
"set extended prompt parameter" {
|
2011-12-16 15:55:40 +00:00
|
|
|
-re "\[\r\n\]some param full $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-08-17 10:41:22 +00:00
|
|
|
}
|
|
|
|
|
}
|
2011-12-16 15:55:40 +00:00
|
|
|
|
|
|
|
|
# Start with a fresh gdb.
|
|
|
|
|
clean_restart ${testfile}
|
|
|
|
|
|
|
|
|
|
# The following tests require execution.
|
|
|
|
|
|
2022-11-14 14:12:07 +00:00
|
|
|
if {![runto_main]} {
|
2026-04-29 20:04:14 -03:00
|
|
|
return
|
2011-12-16 15:55:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# print-stack settings
|
|
|
|
|
gdb_test "show python print-stack" \
|
|
|
|
|
"The mode of Python stack printing on error is \"message\".*" \
|
2013-10-01 20:36:01 +00:00
|
|
|
"Test print-stack show setting. Default is message."
|
2011-12-16 15:55:40 +00:00
|
|
|
gdb_py_test_silent_cmd "set python print-stack full" \
|
2013-10-01 20:36:01 +00:00
|
|
|
"Test print-stack set setting to full" 1
|
2011-12-16 15:55:40 +00:00
|
|
|
gdb_test "show python print-stack" \
|
|
|
|
|
"The mode of Python stack printing on error is \"full\".*" \
|
2013-10-01 20:36:01 +00:00
|
|
|
"Test print-stack show setting to full"
|
2011-12-16 15:55:40 +00:00
|
|
|
gdb_py_test_silent_cmd "set python print-stack none" \
|
2013-10-01 20:36:01 +00:00
|
|
|
"Test print-stack set setting to none" 1
|
2011-12-16 15:55:40 +00:00
|
|
|
gdb_test "show python print-stack" \
|
|
|
|
|
"The mode of Python stack printing on error is \"none\".*" \
|
2016-12-01 14:44:38 -06:00
|
|
|
"test print-stack show setting to none"
|
2011-12-16 15:55:40 +00:00
|
|
|
|
|
|
|
|
gdb_py_test_silent_cmd "set python print-stack message" \
|
2013-10-01 20:36:01 +00:00
|
|
|
"Test print-stack set setting to message" 1
|
2011-12-16 15:55:40 +00:00
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiline "prompt substitution readline error_prompt" \
|
2011-12-16 15:55:40 +00:00
|
|
|
"python" "" \
|
|
|
|
|
"pCounter = 0" "" \
|
|
|
|
|
"def error_prompt(current):" "" \
|
|
|
|
|
" raise RuntimeError(\"Python exception called\")" "" \
|
|
|
|
|
"end" ""
|
|
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook error_prompt" {
|
gdb/python: reformat an error string
While working on another patch I noticed an oddly formatted error
message in the Python code.
When 'set python print-stack message' is in effect then consider this
Python script:
class TestCommand (gdb.Command):
def __init__ (self):
gdb.Command.__init__ (self, "test-cmd", gdb.COMMAND_DATA)
def invoke(self, args, from_tty):
raise RuntimeError ("bad")
TestCommand ()
And this GDB session:
(gdb) source path/to/python/script.py
(gdb) test-cmd
Python Exception <class 'RuntimeError'> bad:
Error occurred in Python: bad
The line 'Python Exception <class 'RuntimeError'> bad:' doesn't look
terrible in this situation, the colon at the end of the first line
makes sense given the second line.
However, there are places in GDB where there is no second line
printed, for example consider this python script:
def stop_listener (e):
raise RuntimeError ("bad")
gdb.events.stop.connect (stop_listener)
Then this GDB session:
(gdb) file helloworld.exe
(gdb) start
Temporary breakpoint 1 at 0x40112a: file hello.c, line 6.
Starting program: helloworld.exe
Temporary breakpoint 1, main () at hello.c:6
6 printf ("Hello World\n");
Python Exception <class 'RuntimeError'> bad:
(gdb) si
0x000000000040112f 6 printf ("Hello World\n");
Python Exception <class 'RuntimeError'> bad:
In this case there is no auxiliary information displayed after the
warning, and the line ending in the colon looks weird to me.
A quick survey of the code seems to indicate that it is not uncommon
for there to be no auxiliary information line printed, its not just
the one case I found above.
I propose that the line that currently looks like this:
Python Exception <class 'RuntimeError'> bad:
Be reformatted like this:
Python Exception <class 'RuntimeError'>: bad
I think this looks fine then in either situation. The first now looks
like this:
(gdb) test-cmd
Python Exception <class 'RuntimeError'>: bad
Error occurred in Python: bad
And the second like this:
(gdb) si
0x000000000040112f 6 printf ("Hello World\n");
Python Exception <class 'RuntimeError'>: bad
There's just two tests that needed updating. Errors are checked for
in many more tests, but most of the time the pattern doesn't care
about the colon.
gdb/ChangeLog:
* python/python.c (gdbpy_print_stack): Reformat an error message.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter.exp: Update expected results.
* gdb.python/python.exp: Update expected results.
2021-01-18 10:03:21 +00:00
|
|
|
-re "Python Exception (exceptions.RuntimeError|<(type 'exceptions.|class ')RuntimeError'>): Python exception called\r\n$gdb_prompt $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-12-16 15:55:40 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_py_test_silent_cmd "python gdb.prompt_hook = None" \
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
"set the hook to default 1" 1
|
2011-12-16 15:55:40 +00:00
|
|
|
|
|
|
|
|
gdb_py_test_silent_cmd "set python print-stack full" \
|
2013-10-01 20:36:01 +00:00
|
|
|
"set print-stack full for prompt error test" 1
|
2011-12-16 15:55:40 +00:00
|
|
|
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook error_prompt traceback" {
|
2019-07-29 15:07:47 +02:00
|
|
|
-re "Traceback.*File.*line.*RuntimeError.*Python exception called.*$gdb_prompt $" {
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
pass $gdb_test_name
|
2011-12-16 15:55:40 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_py_test_silent_cmd "python gdb.prompt_hook = None" \
|
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-22 21:56:59 +02:00
|
|
|
"set the hook to default 2" 1
|
2012-05-13 11:33:44 +00:00
|
|
|
|
|
|
|
|
# Start with a fresh gdb.
|
|
|
|
|
clean_restart ${testfile}
|
|
|
|
|
|
|
|
|
|
# The following tests require execution.
|
|
|
|
|
|
2022-11-14 14:12:07 +00:00
|
|
|
if {![runto_main]} {
|
2026-04-29 20:04:14 -03:00
|
|
|
return
|
2012-05-13 11:33:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
runto [gdb_get_line_number "Break at func2 call site."]
|
|
|
|
|
|
|
|
|
|
gdb_py_test_silent_cmd "python line = gdb.selected_frame().find_sal().line" "Get line number of func2 call site" 1
|
2021-07-22 13:33:59 -05:00
|
|
|
|
|
|
|
|
gdb_py_test_silent_cmd "python pc_call = gdb.selected_frame().pc()" \
|
|
|
|
|
"Get pc of func2 call site" 1
|
|
|
|
|
|
2016-12-01 14:41:23 -06:00
|
|
|
gdb_test "python print (gdb.find_pc_line(gdb.selected_frame().pc()).line == line)" "True" "test find_pc_line at func2 call site"
|
2012-05-13 11:33:44 +00:00
|
|
|
|
|
|
|
|
gdb_py_test_silent_cmd "step" "Step into func2" 1
|
|
|
|
|
gdb_py_test_silent_cmd "up" "Step out of func2" 1
|
|
|
|
|
|
2021-07-22 13:33:59 -05:00
|
|
|
# The point of the following test is to see if gdb has advanced past the
|
|
|
|
|
# location where the branch to a function was made.
|
|
|
|
|
set test_name "test find_pc_line with resume address"
|
|
|
|
|
|
|
|
|
|
gdb_py_test_silent_cmd "python pc_rtn = gdb.selected_frame().pc()" \
|
|
|
|
|
"Get pc at func2 return site" 1
|
|
|
|
|
|
|
|
|
|
gdb_test "python print (pc_rtn > pc_call)" "True" \
|
|
|
|
|
"test resume address greater then call address"
|
|
|
|
|
|
|
|
|
|
gdb_test "python print (gdb.find_pc_line(pc_rtn).line >= line)" "True" \
|
|
|
|
|
"test find_pc_line with resume address"
|
2022-06-05 07:42:12 -06:00
|
|
|
gdb_test "python print (gdb.find_pc_line(pc_rtn).line == gdb.find_pc_line(gdb.Value(pc_rtn)).line)" \
|
|
|
|
|
"True" \
|
|
|
|
|
"test find_pc_line using Value"
|
2018-04-22 15:13:09 -06:00
|
|
|
|
|
|
|
|
gdb_test_no_output "set variable \$cvar1 = 23" "set convenience variable"
|
|
|
|
|
gdb_test "python print(gdb.convenience_variable('cvar1'))" "23"
|
|
|
|
|
gdb_test "python print(gdb.convenience_variable('cvar2'))" "None"
|
|
|
|
|
gdb_test_no_output "python gdb.set_convenience_variable('cvar1', 89)" \
|
|
|
|
|
"change convenience variable from python"
|
|
|
|
|
gdb_test "python print(gdb.convenience_variable('cvar1'))" "89" \
|
|
|
|
|
"print new value of convenience variable from python"
|
|
|
|
|
gdb_test "print \$cvar1" " = 89" \
|
|
|
|
|
"print new value of convenience variable from CLI"
|
|
|
|
|
gdb_test_no_output "python gdb.set_convenience_variable('cvar3', -5)" \
|
|
|
|
|
"make convenience variable from python"
|
|
|
|
|
gdb_test "python print(gdb.convenience_variable('cvar3'))" "-5" \
|
|
|
|
|
"print value of new convenience variable from python"
|
|
|
|
|
gdb_test_no_output "python gdb.set_convenience_variable('cvar3', None)" \
|
|
|
|
|
"reset convenience variable from python"
|
|
|
|
|
gdb_test "python print(gdb.convenience_variable('cvar3'))" "None" \
|
|
|
|
|
"print reset convenience variable from python"
|
|
|
|
|
gdb_test "print \$cvar3" "= void" \
|
|
|
|
|
"print reset convenience variable from CLI"
|
2018-09-17 08:26:24 -04:00
|
|
|
|
|
|
|
|
# Test PR 23669, the following would invoke the "commands" command instead of
|
|
|
|
|
# "show commands".
|
|
|
|
|
gdb_test "python gdb.execute(\"show commands\")" "$decimal print \\\$cvar3.*"
|
gdb: Fix from_tty argument to gdb.execute in Python.
Prior to commit 56bcdbea2b, the from_tty keyword argument to the
Python function gdb.execute controlled whether the command took input
from the terminal. When from_tty=True, "starti" and similar commands
prompted the user:
(gdb) python gdb.execute("starti", from_tty=True)
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /bin/true
Program stopped.
When from_tty=False, these commands did not prompt the user, and "yes"
was assumed:
(gdb) python gdb.execute("starti", from_tty=False)
Program stopped.
However, after commit 56bcdbea2b, the from_tty keyword argument no
longer had this effect. For example, as of commit 7ade7fba75:
(gdb) python gdb.execute("starti", from_tty=True)
The program being debugged has been started already.
Start it from the beginning? (y or n) [answered Y; input not from terminal]
Starting program: /bin/true
Program stopped.
Note the "[answered Y; input not from terminal]" in the output even
though from_tty=True was requested.
Looking at commit 56bcdbea2b, it seems that the behaviour of the
from_tty argument was changed accidentally. The commit message said:
Let gdb.execute handle multi-line commands
This changes the Python API so that gdb.execute can now handle
multi-line commands, like "commands" or "define".
and there was no mention of changing the effect of the from_tty
argument. It looks as though the code for setting the instream to
nullptr was accidentally moved from execute_user_command() to
execute_control_commands() along with the other scoped restores.
Accordingly, the simplest way to fix this is to partially reverse
commit 56bcdbea2b by moving the code for setting the instream to
nullptr back to execute_user_command() where it was to begin with.
Additionally, add a test case to reduce the risk of similar breakage
in future.
gdb/ChangeLog:
PR python/26586
* cli/cli-script.c (execute_control_commands): don't set
instream to nullptr here as this breaks the from_tty argument
to gdb.execute in Python.
(execute_user_command): set instream to nullptr here instead.
gdb/testsuite/ChangeLog:
PR python/26586
* gdb.python/python.exp: add test cases for the from_tty
argument to gdb.execute.
2020-09-26 11:01:45 -07:00
|
|
|
|
2021-10-13 11:06:36 +02:00
|
|
|
# Check if starti command is supported.
|
|
|
|
|
if { [use_gdb_stub] == 0 } {
|
|
|
|
|
# Test that the from_tty argument to gdb.execute is effective. If
|
|
|
|
|
# False, the user is not prompted for decisions such as restarting the
|
|
|
|
|
# program, and "yes" is assumed. If True, the user is prompted.
|
|
|
|
|
# Case 1, from_tty=False.
|
|
|
|
|
gdb_test "python gdb.execute('starti', from_tty=False)" \
|
|
|
|
|
"Program stopped.*" \
|
|
|
|
|
"starti via gdb.execute, not from tty"
|
|
|
|
|
|
|
|
|
|
# Case 2, from_tty=True.
|
|
|
|
|
set test "starti via gdb.execute, from tty"
|
|
|
|
|
set question \
|
|
|
|
|
[multi_line \
|
|
|
|
|
{The program being debugged has been started already\.} \
|
|
|
|
|
{Start it from the beginning\? \(y or n\) $}]
|
|
|
|
|
gdb_test_multiple "python gdb.execute('starti', from_tty=True)" $test {
|
|
|
|
|
-re $question {
|
|
|
|
|
gdb_test "y" "Starting program:.*" $gdb_test_name
|
|
|
|
|
}
|
gdb: Fix from_tty argument to gdb.execute in Python.
Prior to commit 56bcdbea2b, the from_tty keyword argument to the
Python function gdb.execute controlled whether the command took input
from the terminal. When from_tty=True, "starti" and similar commands
prompted the user:
(gdb) python gdb.execute("starti", from_tty=True)
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /bin/true
Program stopped.
When from_tty=False, these commands did not prompt the user, and "yes"
was assumed:
(gdb) python gdb.execute("starti", from_tty=False)
Program stopped.
However, after commit 56bcdbea2b, the from_tty keyword argument no
longer had this effect. For example, as of commit 7ade7fba75:
(gdb) python gdb.execute("starti", from_tty=True)
The program being debugged has been started already.
Start it from the beginning? (y or n) [answered Y; input not from terminal]
Starting program: /bin/true
Program stopped.
Note the "[answered Y; input not from terminal]" in the output even
though from_tty=True was requested.
Looking at commit 56bcdbea2b, it seems that the behaviour of the
from_tty argument was changed accidentally. The commit message said:
Let gdb.execute handle multi-line commands
This changes the Python API so that gdb.execute can now handle
multi-line commands, like "commands" or "define".
and there was no mention of changing the effect of the from_tty
argument. It looks as though the code for setting the instream to
nullptr was accidentally moved from execute_user_command() to
execute_control_commands() along with the other scoped restores.
Accordingly, the simplest way to fix this is to partially reverse
commit 56bcdbea2b by moving the code for setting the instream to
nullptr back to execute_user_command() where it was to begin with.
Additionally, add a test case to reduce the risk of similar breakage
in future.
gdb/ChangeLog:
PR python/26586
* cli/cli-script.c (execute_control_commands): don't set
instream to nullptr here as this breaks the from_tty argument
to gdb.execute in Python.
(execute_user_command): set instream to nullptr here instead.
gdb/testsuite/ChangeLog:
PR python/26586
* gdb.python/python.exp: add test cases for the from_tty
argument to gdb.execute.
2020-09-26 11:01:45 -07:00
|
|
|
}
|
|
|
|
|
}
|
2024-09-11 10:35:20 -06:00
|
|
|
|
|
|
|
|
# Regression test for PR python/32163: several types were not
|
|
|
|
|
# previously registered with the module, so could not be inspected
|
|
|
|
|
# directly.
|
|
|
|
|
foreach type {Instruction LazyString Membuf Record RecordFunctionSegment \
|
|
|
|
|
RecordGap RecordInstruction TuiWindow} {
|
2024-12-03 16:53:14 +01:00
|
|
|
if { $type == "TuiWindow" && ![allow_tui_tests] } {
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
|
2024-09-11 10:35:20 -06:00
|
|
|
gdb_test "python print(type(gdb.$type))" "<class 'type'>" \
|
|
|
|
|
"gdb.$type is registered"
|
|
|
|
|
}
|
Rewrite output redirection and logging
This patch changes how gdb output redirection is done.
Currently, output is done via the UI. gdb_stdout, for example, is a
define the expands to an lvalue referencing a field in the current UI.
When redirecting, this field may temporarily be reset; and when
logging is enabled or disabled, this is also done.
This has lead to bugs where the combination of redirection and logging
results in use-after-free. Crashes are readily observable; see the
new test cases.
This patch upends this. Now, gdb_stdout is simply an rvalue, and
refers to the current interpreter. The interpreter provides ui_files
that do whatever rewriting is needed (mostly for MI); then output is
forward to the current UI via an indirection (see the new
ui::passthrough_file).
The ui provides paging, logging, timestamps, and the final stream that
writes to an actual file descriptor.
Redirection is handled at the ui layer. Rather than changing the
output pipeline, new ui_files are simply swapped in by rewriting
pointers, hopefully with a scoped_restore.
Redirecting at the ui layer means that interpreter rewriting is still
applied when capturing output. This fixes one of the reported bugs.
Not changing the pipeline means that the problems with the combination
of redirect and logging simply vanish. Logging just changes a flag
and doesn't involve object destruction.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17697
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28620
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28798
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28948
Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-12-06 15:12:37 -06:00
|
|
|
|
|
|
|
|
set logfile [host_standard_output_file gdb.txt]
|
|
|
|
|
gdb_test_no_output "set logging file $logfile" \
|
|
|
|
|
"set logging file [file tail $logfile]"
|
|
|
|
|
gdb_test_no_output "set logging redirect on" \
|
|
|
|
|
"enable logging redirect via python"
|
|
|
|
|
gdb_test_no_output "python gdb.execute('set logging enabled on')" \
|
|
|
|
|
"enable logging via python"
|
|
|
|
|
|
|
|
|
|
# Even with logging redirect on, this should capture the output.
|
|
|
|
|
gdb_test_no_output "python x = gdb.execute('print 23', to_string=True)" \
|
|
|
|
|
"print from python with logging redirect"
|
|
|
|
|
|
|
|
|
|
gdb_test "set logging enabled off" \
|
|
|
|
|
"Done logging to .*gdb.txt." \
|
|
|
|
|
"disable logging"
|
|
|
|
|
|
|
|
|
|
gdb_test "python print(x)" " = 23.*" \
|
|
|
|
|
"python still captured output"
|