gdb/ChangeLog:
* NEWS: Mention gdb.Objfile.username.
* python/py-objfile.c (objfpy_get_username): New function.
(objfile_getset): Add "username".
gdb/doc/ChangeLog:
* python.texi (Objfiles In Python): Document Objfile.username.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Add tests for objfile.username.
Add test for objfile.filename, objfile.username after objfile
has been unloaded.
This further improves this testcase to check the output of
our calls to gdb.lookup_type.
gdb/ChangeLog:
* gdb.python/py-lookup-type.exp (test_lookup_type): Change
the second test to print the name attribute of value
returned by the call to gdb.lookup_type, and adjust
the expected output accordingly.
gdb/Changelog:
* objfiles.c (objfile_filename): New function.
* objfiles.h (objfile_filename): Declare it.
(objfile_name): Add function comment.
* python/py-objfile.c (objfpy_lookup_objfile_by_name): Try both the
bfd file name (which may be realpath'd), and the original name.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Test gdb.lookup_objfile on symlinked
binary.
The following change...
commit 1994afbf19
Date: Tue Dec 23 07:55:39 2014 -0800
Subject: Look up primitive types as symbols.
... caused the following regression:
% gdb
(gdb) set lang ada
(gdb) python print gdb.lookup_type('character')
Traceback (most recent call last):
File "<string>", line 1, in <module>
gdb.error: No type named character.
Error while executing Python code.
This is because the language_lookup_primitive_type_as_symbol call
was moved to the la_lookup_symbol_nonlocal hook. A couple of
implementations have been upated accordingly, but the Ada version
has not. This patch fixes this omission.
gdb/ChangeLog:
* ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
in static block, then try searching for primitive types.
gdb/testsuite/ChangeLog:
* gdb.python/py-lookup-type.exp: New file.
The previous change to py-prompt.exp made it return without restoring
GDBFLAGS, resulting in breaking the following tests:
$ make check RUNTESTFLAGS="--target_board=native-gdbserver --directory=gdb.python"
...
Running src/gdb/testsuite/gdb.python/py-prompt.exp ...
Running src/gdb/testsuite/gdb.python/py-section-script.exp ...
ERROR: (timeout) GDB never initialized after 10 seconds.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print ('test') to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[0]) to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[1]) to GDB.
ERROR: no fileid for gdbuild
ERROR: no fileid for gdbuild
...
gdb/testsuite/
2015-01-12 Pedro Alves <palves@redhat.com>
* gdb.python/py-prompt.exp: When the board can't spawn for attach,
restore GDBFLAGS before returning.
for x86_64 -m32 run one gets:
+FAIL: gdb.python/py-frame.exp: test Frame.read_register(rip)
I do not have x32 OS here but the %rip test should PASS there I think.
On Sun, 11 Jan 2015 14:58:06 +0100, Yao Qi wrote:
With your patch applied, this test is skipped on 'x86_64 -m32'. I
prefer to increasing the test coverage, so how about extending the test
for 'x86_64 -m32'? I mean test Frame.read_register(eip)...
gdb/testsuite/ChangeLog
2015-01-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-frame.exp (test Frame.read_register(rip)): Use
is_amd64_regs_target and is_x86_like_target.
We already skip "attach" tests if the target board is remote, in
dejagnu's sense, as we use TCL's exec to spawn the program on the
build machine. We should also skip these tests if testing with
"target remote" or other stub-like targets where "attach" doesn't make
sense.
Add a helper procedure that centralizes the checks a test that needs
to spawn a program for testing "attach" and make all test files that
use spawn_wait_for_attach check it.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (can_spawn_for_attach): New procedure.
(spawn_wait_for_attach): Error out if can_spawn_for_attach returns
false.
* gdb.base/attach.exp: Use can_spawn_for_attach instead of
checking whether the target board is remote.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Use can_spawn_for_attach before the
tests that need to attach, instead of checking whether the target
board is remote at the top of the file.
The following python command fails:
(gdb) python print gdb.lookup_type('char').array(1, 0)
Traceback (most recent call last):
File "<string>", line 1, in <module>
ValueError: Array length must not be negative
Error while executing Python code.
The above is trying to create an empty array, which is fairly command
in Ada.
gdb/ChangeLog:
* python/py-type.c (typy_array_1): Do not raise negative-length
exception if N2 is equal to N1 - 1.
gdb/testsuite/ChangeLog:
* gdb.python/py-type.exp: Add a couple test about empty
array creation, and negative-length array creation.
The message displayed when using help() changed a bit with time, so this
adjusts the test accordingly.
gdb/testsuite/ChangeLog:
* gdb.python/python.exp: Change expected reply to help().
Python 3's print requires to use parentheses, so this patch adds them
where they were missing.
gdb/testsuite/ChangeLog:
* gdb.ada/py_range.exp: Add parentheses to calls to print.
* gdb.dwarf2/symtab-producer.exp: Same.
* gdb.gdb/python-interrupts.exp: Same.
* gdb.gdb/python-selftest.exp: Same.
* gdb.python/py-linetable.exp: Same.
* gdb.python/py-type.exp: Same.
* gdb.python/py-value-cc.exp: Same.
* gdb.python/py-value.exp: Same.
The following test is found in python/py-linetable.exp:
gdb_test "python print sorted(fset)" \
"\[20L, 21L, 22L, 24L, 25L, 28L, 29L, 30L, 32L, 33L, 37L, 39L, 40L, 42L, 44L, 45L, 46L\].*" \
"Test frozen set contains line numbers"
I noticed that it passed when using Python 3, even though it should fail
because of the missing parentheses for the call print.
There needs to be more escaping of the square brackets. Currently, it is
interpreted as "any one character from this big list of characters,
followed by .*". When adding the required amount of backslashes, the
test starts failing as it should.
Moreover, both in Python 2.7 and Python 3.3 the numbers don't have the L
suffix, so now the test fails because of that. Anybody knows why they
were there in the first place? I just tested with Python 2.4 and there
are no Ls.
gdb/testsuite/ChangeLog:
* gdb.python/py-linetable.exp: Escape properly sorted(fset)
test expected output. Add parentheses for the call to print.
Remove L suffix from integers.
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Fix some more C compiler warnings for missing function return types
and implicit function declarations in the GDB testsuite.
gdb/testsuite/ChangeLog:
* gdb.base/bp-permanent.c: Include unistd.h.
* gdb.python/py-framefilter-mi.c (main): Add return type.
* gdb.python/py-framefilter.c (main): Likewise.
* gdb.trace/actions-changed.c (main): Likewise.
The test in gdb.python/python.exp tests "extended-prompt" and expects
working directory is printed. However, working directory on remote
host doesn't have "gdb/testsuite", so the test fails on remote host
like:
set extended-prompt \w ^M
^M
/home/yao FAIL: gdb.python/python.exp: set extended prompt working directory (timeout)
This patch is to get the working directory first, and use it to match
the output of "set extended-prompt \\w ". It works for remote host
and non remote host.
gdb/testsuite:
2014-11-02 Yao Qi <yao@codesourcery.com>
* gdb.python/python.exp: Get working directory and match the
output of "set extended-prompt \\w " with it.
gdb/ChangeLog:
* NEWS: Mention ability add attributes to gdb.Objfile and
gdb.Progspace objects.
* python/py-objfile.c (objfile_object): New member dict.
(objfpy_dealloc): Py_XDECREF dict.
(objfpy_initialize): Initialize dict.
(objfile_getset): Add __dict__.
(objfile_object_type): Set tp_dictoffset member.
* python/py-progspace.c (progspace_object): New member dict.
(pspy_dealloc): Py_XDECREF dict.
(pspy_initialize): Initialize dict.
(pspace_getset): Add __dict__.
(pspace_object_type): Set tp_dictoffset member.
gdb/doc/ChangeLog:
* python.texi (Progspaces In Python): Document ability to add
random attributes to gdb.Progspace objects.
(Objfiles In Python): Document ability to add random attributes to
gdb.objfile objects.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Add tests for setting random attributes
in objfiles.
* gdb.python/py-progspace.exp: Add tests for setting random attributes
in progspaces.
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 0017922d02
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.
Patch <https://sourceware.org/ml/gdb-patches/2011-07/msg00225.html> was
to fix the problem that py-objfile-script-gdb.py is removed after an
in-tree build and test. As a result of the previous patch (we don't
remove files copied to host any more), this patch is no longer needed.
This patch is to revert it logically.
gdb/testsuite:
2014-10-20 Yao Qi <yao@codesourcery.com>
* gdb.python/py-objfile-script-gdb.py.in: Rename it to ...
* gdb.python/py-objfile-script-gdb.py: New file.
* gdb.python/py-objfile-script.exp: Update reference to
py-objfile-script-gdb.py.in. Use gdb_remote_donwload instead
of remote_download. Remove the dest file.
Nowadays, if we do in-tree build and run tests sequentially, some source
files are removed, due to the following pattern:
set pi_txt [gdb_remote_download host ${srcdir}/${subdir}/pi.txt]
remote_exec host "rm -f $pi_txt"
If testing is run sequentially, file ${srcdir}/${subdir}/pi.txt is
copied to ${objdir}/${subdir}/pi.txt. However, ${objdir} is ${srcdir}
in the in-tree build/test, so the file is coped to itself, as a nop.
As a result, the file in source is removed at the end of test.
This patch fixes this problem by not removing files copied to host in
each test. This patch also addresses the question we've had that why
don't we keep files copied to host because they are needed to reproduce
certain fails.
gdb/testsuite:
2014-10-20 Yao Qi <yao@codesourcery.com>
* gdb.base/checkpoint.exp: Don't remove file copied on host.
* gdb.base/step-line.exp: Likewise.
* gdb.dwarf2/dw2-anonymous-func.exp: Likewise.
* gdb.dwarf2/dw2-basic.exp: Likewise.
* gdb.dwarf2/dw2-compressed.exp: Likewise.
* gdb.dwarf2/dw2-filename.exp: Likewise.
* gdb.dwarf2/dw2-intercu.exp: Likewise.
* gdb.dwarf2/dw2-intermix.exp: Likewise.
* gdb.dwarf2/dw2-producer.exp: Likewise.
* gdb.dwarf2/mac-fileno.exp: Likewise.
* gdb.python/py-frame-args.exp: Likewise.
* gdb.python/py-framefilter.exp: Likewise.
* gdb.python/py-mi.exp: Likewise.
* gdb.python/py-objfile-script.exp: Likewise
* gdb.python/py-pp-integral.exp: Likewise.
* gdb.python/py-pp-re-notag.exp: Likewise.
* gdb.python/py-prettyprint.exp: Likewise.
* gdb.python/py-section-script.exp: Likewise.
* gdb.python/py-typeprint.exp: Likewise.
* gdb.python/py-xmethods.exp: Likewise.
* gdb.stabs/weird.exp: Likewise.
* gdb.xml/tdesc-regs.exp: Likewise.
I see the following two fails on arm-none-eabi target, because argv[0]
isn't available.
print argv[0]^M
$1 = 0x1f78 "/dev/null"^M
(gdb) FAIL: gdb.base/argv0-symlink.exp: kept file symbolic link name
print argv[0]^M
$1 = 0x1f78 "/dev/null"^M
(gdb) FAIL: gdb.base/argv0-symlink.exp: kept directory symbolic link name
My first thought is to check [target_info exists noargs], and skip the
test if it returns true. However, noargs is set in gdbserver board
files, so argv0-symlink.exp will be skipped on gdbserver board file.
The change is too aggressive.
When the program is running with gdbserver, argv[1] to argv[N] aren't
available, but argv[0] is. Fortunately, argv0-symlink.exp only
requires argv[0]. argv0-symlink.exp can be run with gdbserver board
file, as what we do now.
What we need to check is whether argv[0] is available, so I add a new
proc gdb_has_argv0 to do so by starting a program, and check
argc/argv[0] to see whether argv[0] is available.
Dan fixed the similar problem by checking noargs, which is too strong.
https://sourceware.org/ml/gdb-patches/2010-02/msg00398.html as a
result, the test is skipped on gdbserver. This patch fixed it too.
gdb/testsuite:
2014-10-18 Yao Qi <yao@codesourcery.com>
* gdb.base/argv0-symlink.exp: Check argv[0] value if
gdb_has_argv0 return true.
* gdb.guile/scm-value.exp (test_value_in_inferior): Don't
check [target_info exists noargs], check [gdb_has_argv0]
instead.
* gdb.python/py-value.exp (test_value_in_inferior): Likewise.
* lib/gdb.exp (gdb_has_argv0, gdb_has_argv0_1): New
procedures.
If one is watching new_objfile events in python, it helps to know
when the list of objfiles is cleared. This patch adds a new
clear_objfiles event to support this.
This patch is all just cut-n-paste-n-tweak derived from
the new_objfiles event.
gdb/ChangeLog:
* NEWS: Mention new event gdb.clear_objfiles.
* python/py-event.h (emit_clear_objfiles_event): Clear
* python/py-events.h (events_object): New member clear_objfiles.
* python/py-evts.c (gdbpy_initialize_py_events): Add clear_objfiles
event.
* python/py-inferior.c (python_new_objfile): If objfile is NULL,
emit clear_objfiles event.
* python/py-newobjfileevent.c (create_clear_objfiles_event_object): New
function.
(emit_clear_objfiles_event): New function.
(clear_objfiles): New event.
* python/python-internal.h (gdbpy_initialize_clear_objfiles_event):
Declare.
* python/python.c (_initialize_python): Call
gdbpy_initialize_clear_objfiles_event.
gdb/doc/ChangeLog:
* python.texi (Events In Python): Document clear_objfiles event.
gdb/testsuite/ChangeLog:
* gdb.python/py-events.exp: Update expected output for clear_objfiles
event.
* gdb.python/py-events.py: Add clear_objfiles event.
gdb/ChangeLog:
* NEWS: Mention new gdb.Objfile.progspace attribute.
* python/py-objfile.c (objfpy_get_progspace): New function.
(objfile_getset): New entry for "progspace".
gdb/doc/ChangeLog:
* python.texi (Objfiles In Python): Document new progspace attribute.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Test progspace attribute.
Some testcases, mostly gdb.reverse ones, assume the presence of a
'/' directory separator before the source file name. This is
incorrect for mingw32 hosts, generating false failures for those
tests.
I attempted to catch most of the occurrences of the pattern
".*/$srcfile" and replaced them with ".*$srcfile". The latter
is used elsewhere in the testsuite. The resulting patch is attached.
I also see other occurrences of the same assumption throughout the
testsuite, but usually they are arguments for function calls and i
seem to recall either the test harness or GDB deals with those
paths properly.
gdb/testsuite:
2014-10-17 Luis Machado <lgustavo@codesourcery.com>
* gdb.guile/scm-breakpoint.exp: Do not assume any
directory separators when matching source file paths.
* gdb.python/py-breakpoint.exp: Likewise.
* gdb.reverse/break-precsave.exp: Likewise.
* gdb.reverse/break-reverse.exp: Likewise.
* gdb.reverse/consecutive-precsave.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/finish-reverse-bkpt.exp: Likewise.
* gdb.reverse/finish-reverse.exp: Likewise.
* gdb.reverse/i386-precsave.exp: Likewise.
* gdb.reverse/i387-env-reverse.exp: Likewise.
* gdb.reverse/i387-stack-reverse.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/machinestate.exp: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/solib-precsave.exp: Likewise.
* gdb.reverse/step-precsave.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
* gdb.reverse/watch-reverse.exp: Likewise.
Test gdb.python/py-parameter.exp expects output "$srcdir/$subdir:\$cdir:\$cwd",
but proc gdb_reinitialize_dir doesn't set $srcdir/$subdir in search
directories on remote host because it doesn't exist on remote host.
proc gdb_reinitialize_dir { subdir } {
global gdb_prompt
if [is_remote host] {
return ""
}
It causes the fail below:
(gdb) python print (gdb.parameter ('directories'))^M
/tmp/gdb:$cdir:$cwd^M
(gdb) FAIL: gdb.python/py-parameter.exp: python print (gdb.parameter ('directories'))
This patch is to fix this fail by not matching $srcdir/$subdir on remote host.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-parameter.exp: Don't match $srcdir/$subdir on
remote host.
I see the following fails in the remote host testing we do for mingw32
hosted GDB,
python print (symtab[1][0].symtab)^M
python.c^M
(gdb) FAIL: gdb.python/python.exp: Test decode_line current locationn filename
python print (symtab[1][0].symtab)^M
python.c^M
(gdb) FAIL: gdb.python/python.exp: Test decode_line python.c:26 filename
The test cases doesn't consider remote host and assumes that directory
on build also exists on host. In this patch, we only match file base
name if host is remote, otherwise, match file with dir name.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-symbol.exp: Match file base name if host is
remote, otherwise match file name with dir name.
* gdb.python/py-symtab.exp: Likewise.
* gdb.python/python.exp: Likewise.
This patch is to clean up various gdb.python/*.exp tests, such as
removing trailing ".*" from the pattern and fix one typo I find during
reading the code.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/python.exp: Remove trailing ".*". Fix typo
locationn.
* gdb.python/py-symbol.exp: Remove trailing ".*" in the
pattern.
* gdb.python/py-symtab.exp: Likewise.
Several places in the testsuite have a copy of a snippet of code that
spawns a test program, waits a bit, and then does some PID munging for
Cygwin. This is in order to have GDB attach to the spawned program.
This refactors all that to a common procedure.
(multi-attach.exp wants to spawn multiple processes, so this makes the
new procedure's interface work with lists.)
Tested on x86_64 Fedora 20.
gdb/testsuite/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (spawn_wait_for_attach): New procedure.
* gdb.base/attach.exp (do_attach_tests, do_call_attach_tests)
(do_command_attach_tests): Use spawn_wait_for_attach.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
have empty bodies.
User-defined commands that have empty bodies weren't being shown because
the print function returned too soon. Now, it prints the command's name
before checking if it has any body at all. This also fixes the same
problem on "show user <myemptycommand>", which wasn't being printed due
to a similar reason.
gdb/Changelog:
* cli/cli-cmds.c (show_user): Use cli_user_command_p to
decide whether we display the command on "show user".
* cli/cli-script.c (show_user_1): Only verify cmdlines after
printing command name.
* cli/cli-decode.h (cli_user_command_p): Declare new function.
* cli/cli-decode.c (cli_user_command_p): Create helper function
to verify whether cmd_list_element is a user-defined command.
gdb/testsuite/Changelog:
* gdb.base/commands.exp: Add tests to verify user-defined
commands with empty bodies.
* gdb.python/py-cmd.exp: Test that we don't show user-defined
python commands in `show user command`.
* gdb.python/scm-cmd.exp: Test that we don't show user-defined
scheme commands in `show user command`.
https://bugzilla.redhat.com/show_bug.cgi?id=1126177
ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x000000992bef sp 0x7ffff9039530 bp 0x7ffff9039540
T0)
#0 0x992bee in value_type .../gdb/value.c:925
#1 0x87c951 in py_print_single_arg python/py-framefilter.c:445
#2 0x87cfae in enumerate_args python/py-framefilter.c:596
#3 0x87e0b0 in py_print_args python/py-framefilter.c:968
It crashes because frame_arg::val is documented it may contain NULL
(frame_arg::error is then non-NULL) but the code does not handle it.
Another bug is that py_print_single_arg() calls goto out of its TRY_CATCH
which messes up GDB cleanup chain crashing GDB later.
It is probably 7.7 regression (I have not verified it) due to the introduction
of Python frame filters.
gdb/ChangeLog
PR python/17355
* python/py-framefilter.c (py_print_single_arg): Handle NULL FA->VAL.
Fix goto out of TRY_CATCH.
gdb/testsuite/ChangeLog
PR python/17355
* gdb.python/amd64-py-framefilter-invalidarg.S: New file.
* gdb.python/py-framefilter-invalidarg-gdb.py.in: New file.
* gdb.python/py-framefilter-invalidarg.exp: New file.
* gdb.python/py-framefilter-invalidarg.py: New file.
The ability to read registers is needed to use Frame Filter API to
display the frames created by JIT compilers.
gdb/ChangeLog:
2014-08-29 Sasha Smundak <asmundak@google.com>
* python/py-frame.c (frapy_read_register): New function.
gdb/doc/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* python.texi (Frames in Python): Add read_register description.
gdb/testsuite/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* gdb.python/py-frame.exp: Test Frame.read_register.
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
I see the following fails on arm-none-eabi target,
print sn^M
$14 = 0x0 <_ftext>^M
(gdb) FAIL: gdb.python/py-value.exp: print sn
print sn^M
$14 = 0x0 <_ftext>^M
(gdb) FAIL: gdb.guile/scm-value.exp: print sn
as <_ftext> is unexpected. This patch is to set print symbol off to
avoid printing this.
gdb/testsuite:
2014-08-24 Yao Qi <yao@codesourcery.com>
* gdb.guile/scm-value.exp (test_lazy_strings): Set print
symbol off.
* gdb.python/py-value.exp (test_lazy_strings): Likewise.
Some gdb.python/*.exp tests fail because the .py files aren't copied
to the (remote) host. This patch is to copy needed .py files to host.
Most of gdb.python/*.exp tests do this.
As it is still controversial to delete *.py files on host, we don't do
that in this patch.
gdb/testsuite:
2014-08-22 Yao Qi <yao@codesourcery.com>
* gdb.python/py-finish-breakpoint.exp: Copy .py file to host.
* gdb.python/py-finish-breakpoint2.exp: Likewise.
* gdb.python/python.exp: Likewise. Use .py file on the host
instead of the build.
gdb/
* python/lib/gdb/command/xmethods.py (set_xm_status1): Use the
'items' methods instead of 'iteritems' method on dictionaries.
gdb/testsuite/
* gdb.python/py-xmethods.py (A_getarrayind)
(E_method_char_worker.__call__, E_method_int_worker.__call__):
Use 'print' with function call syntax.
(E_method_matcher.match): Fix tab vs space indentation mixup.
I find some gdb.python tests fail on arm-none-eabi target, because the
tests assume that memory on address 0x is inaccessible. Some tests
(in gdb.base) are aware of this, so do a "x 0" check first. However,
the code is copy-n-paste.
This patch is to move the "x 0" check to a procedure in lib/gdb.exp,
and get needed tests call it. The original code matches pattern
"0x0:\[ \t\]*Error accessing memory address 0x0\r\n$gdb_prompt $", but
I remove it from the new proc is_address_zero_readable, because GDB
doesn't emit such message any more.
gdb/testsuite:
2014-08-09 Yao Qi <yao@codesourcery.com>
* gdb.base/display.exp: Invoke is_address_zero_readable.
* gdb.guile/scm-value.exp (test_value_in_inferior): Likewise.
* gdb.python/py-value.exp (test_value_in_inferior): Likewise.
* gdb.base/hbreak-unmapped.exp: Return if
is_address_zero_readable returns true.
* gdb.base/signest.exp: Likewise.
* gdb.base/signull.exp: Likewise.
* gdb.base/sigbpt.exp: Likewise.
* gdb.guile/scm-disasm.exp: Do the test if
is_address_zero_readable returns false.
* gdb.guile/scm-pretty-print.exp (run_lang_tests): Likewise.
* gdb.python/py-arch.exp: Likewise.
* gdb.python/py-prettyprint.exp (run_lang_tests): Likewise.
* lib/gdb.exp (is_address_zero_readable): New proc.
Currently, the xmethod commands lookup xmethod matchers in the current
progspace even if the locus regular expression matches the progspace's
filename. Pretty printer commands do not match the current progspace's
filename.
gdb/
* python/lib/gdb/command/xmethods.py
(get_method_matchers_in_loci): Lookup xmethod matchers in the
current progspace only if the string "progspace" matches LOCUS_RE.
gdb/testsuite
* gdb.python/py-xmethods.exp: Use "progspace" instead of the
progspace's filename in 'info', 'enable' and 'disable' command
tests.
gdb/testsuite/
PR gdb/17017
* gdb.python/py-xmethods.cc: Add global function call counters and
increment them in their respective functions. Remove "cout"
statements.
* gdb.python/py-xmethods.exp: Make tests check the global function
call counters instead of depending on inferior IO.
* python/py-xmethods.c: New file.
* python/py-objfile.c (objfile_object): New field 'xmethods'.
(objfpy_dealloc): XDECREF on the new xmethods field.
(objfpy_new, objfile_to_objfile_object): Initialize xmethods
field.
(objfpy_get_xmethods): New function.
(objfile_getset): New entry 'xmethods'.
* python/py-progspace.c (pspace_object): New field 'xmethods'.
(pspy_dealloc): XDECREF on the new xmethods field.
(pspy_new, pspace_to_pspace_object): Initialize xmethods
field.
(pspy_get_xmethods): New function.
(pspace_getset): New entry 'xmethods'.
* python/python-internal.h: Add declarations for new functions.
* python/python.c (_initialize_python): Invoke
gdbpy_initialize_xmethods.
* python/lib/gdb/__init__.py (xmethods): New
attribute.
* python/lib/gdb/xmethod.py: New file.
* python/lib/gdb/command/xmethods.py: New file.
testuite/
* gdb.python/py-xmethods.cc: New testcase to test xmethods.
* gdb.python/py-xmethods.exp: New tests to test xmethods.
* gdb.python/py-xmethods.py: Python script supporting the
new testcase and tests.
This finally makes background execution commands possible by default.
However, in order to do that, there's one last thing we need to do --
we need to separate the MI and target notions of "async". Unlike the
CLI, where the user explicitly requests foreground vs background
execution in the execution command itself (c vs c&), MI chose to treat
"set target-async" specially -- setting it changes the default
behavior of execution commands.
So, we can't simply "set target-async" default to on, as that would
affect MI frontends. Instead we have to make the setting MI-specific,
and teach MI about sync commands on top of an async target.
Because the "target" word in "set target-async" ends up as a potential
source of confusion, the patch adds a "set mi-async" option, and makes
"set target-async" a deprecated alias.
Rather than make the targets always async, this patch introduces a new
"maint set target-async" option so that the GDB developer can control
whether the target is async. This makes it simpler to debug issues
arising only in the synchronous mode; important because sync mode
seems unlikely to go away.
Unlike in previous revisions, "set target-async" does not affect this
new maint parameter. The rationale for this is that then one can
easily run the test suite in the "maint set target-async off" mode and
have tests that enable mi-async fail just like they fail on
non-async-capable targets. This emulation is exactly the point of the
maint option.
I had asked Tom in a previous iteration to split the actual change of
the target async default to a separate patch, but it turns out that
that is quite awkward in this version of the patch, because with MI
async and target async decoupled (unlike in previous versions), if we
don't flip the default at the same time, then just "set target-async
on" alone never actually manages to do anything. It's best to not
have that transitory state in the tree.
Given "set target-async on" now only has effect for MI, the patch goes
through the testsuite removing it from non-MI tests. MI tests are
adjusted to use the new and less confusing "mi-async" spelling.
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* NEWS: Mention "maint set target-async", "set mi-async", and that
background execution commands are now always available.
* target.h (target_async_permitted): Update comment.
* target.c (target_async_permitted, target_async_permitted_1):
Default to 1.
(set_target_async_command): Rename to ...
(maint_set_target_async_command): ... this.
(show_target_async_command): Rename to ...
(maint_show_target_async_command): ... this.
(_initialize_target): Adjust.
* infcmd.c (prepare_execution_command): Make extern.
* inferior.h (prepare_execution_command): Declare.
* infrun.c (set_observer_mode): Leave target async alone.
* mi/mi-interp.c (mi_interpreter_init): Install
mi_on_sync_execution_done as sync_execution_done observer.
(mi_on_sync_execution_done): New function.
(mi_execute_command_input_handler): Don't print the prompt if we
just started a synchronous command with an async target.
(mi_on_resume): Check sync_execution before printing prompt.
* mi/mi-main.h (mi_async_p): Declare.
* mi/mi-main.c: Include gdbcmd.h.
(mi_async_p): New function.
(mi_async, mi_async_1): New globals.
(set_mi_async_command, show_mi_async_command, mi_async): New
functions.
(exec_continue): Call prepare_execution_command.
(run_one_inferior, mi_cmd_exec_run, mi_cmd_list_target_features)
(mi_execute_async_cli_command): Use mi_async_p.
(_initialize_mi_main): Install "set mi-async". Make
"target-async" a deprecated alias.
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Non-Stop Mode): Remove "set target-async 1"
from example.
(Asynchronous and non-stop modes): Document '-gdb-set mi-async'.
Mention that target-async is now deprecated.
(Maintenance Commands): Document maint set/show target-async.
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* gdb.base/async-shell.exp: Don't enable target-async.
* gdb.base/async.exp
* gdb.base/corefile.exp (corefile_test_attach): Remove 'async'
parameter. Adjust.
(top level): Don't test with "target-async".
* gdb.base/dprintf-non-stop.exp: Don't enable target-async.
* gdb.base/gdb-sigterm.exp: Don't test with "target-async".
* gdb.base/inferior-died.exp: Don't enable target-async.
* gdb.base/interrupt-noterm.exp: Likewise.
* gdb.mi/mi-async.exp: Use "mi-async" instead of "target-async".
* gdb.mi/mi-nonstop-exit.exp: Likewise.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-ns-stale-regcache.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.mi/mi-nsmoribund.exp: Likewise.
* gdb.mi/mi-nsthrexec.exp: Likewise.
* gdb.mi/mi-watch-nonstop.exp: Likewise.
* gdb.multi/watchpoint-multi.exp: Adjust comment.
* gdb.python/py-evsignal.exp: Don't enable target-async.
* gdb.python/py-evthreads.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.reverse/break-precsave.exp: Don't test with "target-async".
* gdb.server/solib-list.exp: Don't enable target-async.
* gdb.threads/thread-specific-bp.exp: Likewise.
* lib/mi-support.exp: Adjust to use mi-async.
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.
Doug Evans
Doug Evans
Joel Brobecker
Pedro Alves
Jan Kratochvil
Nick Bull
Simon Marchi
Andreas Arnez
Yao Qi
Luis Machado
Gabriel Krisman Bertazi
Sasha Smundak
Sergio Durigan Junior
Siva Chandra