This adjusts gdb.python/py-nested-maps.c to make it buildable as C++ program.
key_t is renamed because of:
src/gdb/testsuite/gdb.python/py-nested-maps.c:23:8: error: definition of type 'key_t' conflicts with typedef of the same name
struct key_t
^
/usr/include/x86_64-linux-gnu/sys/types.h:121:17: note: 'key_t' declared here
typedef __key_t key_t;
^
gdb/testsuite/ChangeLog:
* gdb.python/py-nested-maps.c (struct key_t): Rename to...
(struct my_key_t): ... this. Adjust all references.
(struct value_t): Rename to ...
(struct my_value_t): ... this. Adjust all references.
(create_map, add_map_element, create_map_map)
(add_map_map_element): Add casts.
This adjusts:
gdb.python/{py-framefilter-mi,py-framefilter}.c
to make them buildable as C++ programs.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter-mi.c (funca): Add casts.
* gdb.python/py-framefilter.c.c (funca, func2): Add casts.
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
Adds a new method 'find' to the gdb.RegisterDescriptorIterator class,
this allows gdb.RegisterDescriptor objects to be looked up directly by
register name rather than having to iterate over all registers.
This will be of use for a later commit.
I've documented the new function in the manual, but I don't think a
NEWS entry is required here, as, since the last release, the whole
register descriptor mechanism is new, and is already mentioned in the
NEWS file.
gdb/ChangeLog:
* python/py-registers.c: Add 'user-regs.h' include.
(register_descriptor_iter_find): New function.
(register_descriptor_iterator_object_methods): New static global
methods array.
(register_descriptor_iterator_object_type): Add pointer to methods
array.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: Add additional tests.
gdb/doc/ChangeLog:
* python.texi (Registers In Python): Document new find function.
Only create one gdb.RegisterGroup Python object for each of GDB's
reggroup objects.
I could have added a field into the reggroup object to hold the Python
object pointer for each reggroup, however, as reggroups are never
deleted within GDB, and are global (not per-architecture) a simpler
solution seemed to be just to hold a single global map from reggroup
pointer to a Python object representing the reggroup. Then we can
reuse the objects out of this map.
After this commit it is possible for a user to tell that two
gdb.RegisterGroup objects are now identical when previously they were
unique, however, as both these objects are read-only I don't think
this should be a problem.
There should be no other user visible changes after this commit.
gdb/ChangeLog:
* python/py-registers.c : Add 'unordered_map' include.
(gdbpy_new_reggroup): Renamed to...
(gdbpy_get_reggroup): ...this. Update to only create register
group descriptors when needed.
(gdbpy_reggroup_iter_next): Update.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-groups.exp: Additional tests.
Instead of having the gdb.RegisterDescriptorIterator creating new
gdb.RegisterDescriptor objects for each regnum, instead cache
gdb.RegisterDescriptor objects on the gdbarch object and reuse these.
This means that for every gdbarch/regnum pair there is a single unique
gdb.RegisterDescriptor, this feels like a neater implementation than
the existing one.
It is possible for a user to see (in Python code) that the descriptors
are now identical, but as the descriptors are read-only this should
make no real difference.
There should be no other user visible changes.
gdb/ChangeLog:
* python/py-registers.c (gdbpy_register_object_data): New static
global.
(gdbpy_register_object_data_init): New function.
(gdbpy_new_register_descriptor): Renamed to...
(gdbpy_get_register_descriptor): ...this, and update to reuse
existing register descriptors where possible.
(gdbpy_register_descriptor_iter_next): Update.
(gdbpy_initialize_registers): Register new gdbarch data.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: Additional tests.
This started with me running into the bug described in python/22748,
in summary, if the frame sniffing code accessed any registers within
an inline frame then GDB would crash with this error:
gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed.
The problem is that, when in the Python unwinder I write this:
pending_frame.read_register ("register-name")
This is translated internally into a call to `value_of_register',
which in turn becomes a call to `value_of_register_lazy'.
Usually this isn't a problem, `value_of_register_lazy' requires the
next frame (more inner) to have a valid frame_id, which will be the
case (if we're sniffing frame #1, then frame #0 will have had its
frame-id figured out).
Unfortunately if frame #0 is inline within frame #1, then the frame-id
for frame #0 can't be computed until we have the frame-id for #1. As
a result we can't create a lazy register for frame #1 when frame #0 is
inline.
Initially I proposed a solution inline with that proposed in bugzilla,
changing value_of_register to avoid creating a lazy register value.
However, when this was discussed on the mailing list I got this reply:
https://sourceware.org/pipermail/gdb-patches/2020-June/169633.html
Which led me to look at these two patches:
[1] https://sourceware.org/pipermail/gdb-patches/2020-April/167612.html
[2] https://sourceware.org/pipermail/gdb-patches/2020-April/167930.html
When I considered patches [1] and [2] I saw that all of the issues
being addressed here were related, and that there was a single
solution that could address all of these issues.
First I wrote the new test gdb.opt/inline-frame-tailcall.exp, which
shows that [1] and [2] regress the inline tail-call unwinder, the
reason for this is that these two patches replace a call to
gdbarch_unwind_pc with a call to get_frame_register, however, this is
not correct. The previous call to gdbarch_unwind_pc takes THIS_FRAME
and returns the $pc value in the previous frame. In contrast
get_frame_register takes THIS_FRAME and returns the value of the $pc
in THIS_FRAME; these calls are not equivalent.
The reason these patches appear (or do) fix the regressions listed in
[1] is that the tail call sniffer depends on identifying the address
of a caller and a callee, GDB then looks for a tail-call sequence that
takes us from the caller address to the callee, if such a series is
found then tail-call frames are added.
The bug that was being hit, and which was address in patch [1] is that
in order to find the address of the caller, GDB ended up creating a
lazy register value for an inline frame with to frame-id. The
solution in patch [1] is to instead take the address of the callee and
treat this as the address of the caller. Getting the address of the
callee works, but we then end up looking for a tail-call series from
the callee to the callee, which obviously doesn't return any sane
results, so we don't insert any tail call frames.
The original patch [1] did cause some breakage, so patch [2] undid
patch [1] in all cases except those where we had an inline frame with
no frame-id. It just so happens that there were no tests that fitted
this description _and_ which required tail-call frames to be
successfully spotted, as a result patch [2] appeared to work.
The new test inline-frame-tailcall.exp, exposes the flaw in patch [2].
This commit undoes patch [1] and [2], and replaces them with a new
solution, which is also different to the solution proposed in the
python/22748 bug report.
In this solution I propose that we introduce some special case logic
to value_of_register_lazy. To understand what this logic is we must
first look at how inline frames unwind registers, this is very simple,
they do this:
static struct value *
inline_frame_prev_register (struct frame_info *this_frame,
void **this_cache, int regnum)
{
return get_frame_register_value (this_frame, regnum);
}
And remember:
struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
return frame_unwind_register_value (frame->next, regnum);
}
So in all cases, unwinding a register in an inline frame just asks the
next frame to unwind the register, this makes sense, as an inline
frame doesn't really exist, when we unwind a register in an inline
frame, we're really just asking the next frame for the value of the
register in the previous, non-inline frame.
So, if we assume that we only get into the missing frame-id situation
when we try to unwind a register from an inline frame during the frame
sniffing process, then we can change value_of_register_lazy to not
create lazy register values for an inline frame.
Imagine this stack setup, where #1 is inline within #2.
#3 -> #2 -> #1 -> #0
\______/
inline
Now when trying to figure out the frame-id for #1, we need to compute
the frame-id for #2. If the frame sniffer for #2 causes a lazy
register read in #2, either due to a Python Unwinder, or for the
tail-call sniffer, then we call value_of_register_lazy passing in
frame #2.
In value_of_register_lazy, we grab the next frame, which is #1, and we
used to then ask for the frame-id of #1, which was not computed, and
this was our bug.
Now, I propose we spot that #1 is an inline frame, and so lookup the
next frame of #1, which is #0. As #0 is not inline it will have a
valid frame-id, and so we create a lazy register value using #0 as the
next-frame-id. This will give us the exact same result we had
previously (thanks to the code we inspected above).
Encoding into value_of_register_lazy the knowledge that reading an
inline frame register will always just forward to the next frame
feels.... not ideal, but this seems like the cleanest solution to this
recursive frame-id computation/sniffing issue that appears to crop
up.
The following two commits are fully reverted with this commit, these
correspond to patches [1] and [2] respectively:
commit 5939967b35
Date: Tue Apr 14 17:26:22 2020 -0300
Fix inline frame unwinding breakage
commit 991a3e2e99
Date: Sat Apr 25 00:32:44 2020 -0300
Fix remaining inline/tailcall unwinding breakage for x86_64
gdb/ChangeLog:
PR python/22748
* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Remove
special handling for inline frames.
* findvar.c (value_of_register_lazy): Skip inline frames when
creating lazy register values.
* frame.c (frame_id_computed_p): Delete definition.
* frame.h (frame_id_computed_p): Delete declaration.
gdb/testsuite/ChangeLog:
PR python/22748
* gdb.opt/inline-frame-tailcall.c: New file.
* gdb.opt/inline-frame-tailcall.exp: New file.
* gdb.python/py-unwind-inline.c: New file.
* gdb.python/py-unwind-inline.exp: New file.
* gdb.python/py-unwind-inline.py: New file.
Add a new method gdb.Architecture.register_groups which returns a new
object of type gdb.RegisterGroupsIterator. This new iterator then
returns objects of type gdb.RegisterGroup.
Each gdb.RegisterGroup object just wraps a single reggroup pointer,
and (currently) has just one read-only property 'name' that is a
string, the name of the register group.
As with the previous commit (adding gdb.RegisterDescriptor) I made
gdb.RegisterGroup an object rather than just a string in case we want
to add additional properties in the future.
gdb/ChangeLog:
* NEWS: Mention additions to Python API.
* python/py-arch.c (archpy_register_groups): New function.
(arch_object_methods): Add 'register_groups' method.
* python/py-registers.c (reggroup_iterator_object): New struct.
(reggroup_object): New struct.
(gdbpy_new_reggroup): New function.
(gdbpy_reggroup_to_string): New function.
(gdbpy_reggroup_name): New function.
(gdbpy_reggroup_iter): New function.
(gdbpy_reggroup_iter_next): New function.
(gdbpy_new_reggroup_iterator): New function
(gdbpy_initialize_registers): Register new types.
(reggroup_iterator_object_type): Define new Python type.
(gdbpy_reggroup_getset): New static global.
(reggroup_object_type): Define new Python type.
* python/python-internal.h
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-groups.exp: New file.
gdb/doc/ChangeLog:
* gdb.texi (Registers): Add @anchor for 'info registers
<reggroup>' command.
* python.texi (Architectures In Python): Document new
register_groups method.
(Registers In Python): Document two new object types related to
register groups.
This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator. This
iterator returns objects of the new type gdb.RegisterDescriptor.
A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.
I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information. By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.
Right now the only property of a register that a user can access is
the name of the register.
In future we might want to be able to ask the register about is
register groups, or its type.
gdb/ChangeLog:
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
* python/py-arch.c (archpy_registers): New function.
(arch_object_methods): Add 'registers' method.
* python/py-registers.c: New file.
* python/python-internal.h
(gdbpy_new_register_descriptor_iterator): Declare.
(gdbpy_initialize_registers): Declare.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_registers.
* NEWS: Mention additions to the Python API.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: New file.
gdb/doc/ChangeLog:
* python.texi (Python API): Add new section the menu.
(Frames In Python): Add new @anchor.
(Architectures In Python): Document new registers method.
(Registers In Python): New section.
It could be useful to determine the architecture of a frame being
unwound during the frame unwind process, that is, before we have a
gdb.Frame, but when we only have a gdb.PendingFrame.
The PendingFrame already has a pointer to the gdbarch internally, this
commit just exposes an 'architecture' method to Python, and has this
return a gdb.Architecture object (list gdb.Frame.architecture does).
gdb/ChangeLog:
* NEWS: Mention new Python API method.
* python/py-unwind.c (pending_framepy_architecture): New function.
(pending_frame_object_methods): Add architecture method.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py (TestUnwinder::__call__): Add test for
gdb.PendingFrame.architecture method.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Document
PendingFrame.architecture method.
Tom de Vries detected that some python tests were broken as
they were still using gdb_py_test_multiple that was replaced
by gdb_test_multiline. Repair these tests by using the new function.
gdb/testsuite/ChangeLog
2020-06-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.python/py-breakpoint.exp: use gdb_test_multiline instead
of gdb_py_test_multiple.
* gdb.python/py-cmd.exp: Likewise.
* gdb.python/py-events.exp: Likewise.
* gdb.python/py-function.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.python/py-infthread.exp: Likewise.
* gdb.python/py-linetable.exp: Likewise.
* gdb.python/py-parameter.exp: Likewise.
* gdb.python/py-value.exp: Likewise.
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
This commit improves upon my previous -Wunused-value fix by
replacing the various dummy variables with casts to void, as
suggested by Pedro.
gdb/testsuite/ChangeLog:
* gdb.cp/namespace.cc: Improve -Wunused-value fix.
* gdb.cp/nsimport.cc: Likewise.
* gdb.cp/nsnested.cc: Likewise.
* gdb.cp/nsnoimports.cc: Likewise.
* gdb.cp/nsusing.cc: Likewise.
* gdb.cp/smartp.cc: Likewise.
* gdb.python/py-pp-integral.c: Likewise.
* gdb.python/py-pp-re-notag.c: Likewise.
Test the new default-args behaviour and completion for the alias command.
Note that gdb.base/default-args.exp is somewhat copied from
with.exp (the test of the with command), while default-exp.c
is a plain copy of with.c.
gdb/testsuite/ChangeLog
2020-06-22 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/default-args.exp: New test.
* gdb.base/default-args.c: New file.
* gdb.base/alias.exp: Update expected error msg for alias foo=bar.
* gdb.base/default.exp: Update to new help text.
* gdb.base/help.exp: Likewise.
* gdb.base/page.exp: Likewise.
* gdb.base/style.exp: Likewise.
* gdb.guile/guile.exp: Likewise.
* gdb.python/python.exp: Likewise.
2020-06-17 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.python/py-format-string.exp: Move test for python support
earlier, out of function body.
If a TUI window is written in Python, and if the window construction
function fails, then gdb will crash. This patch fixes the crash.
gdb/ChangeLog
2020-06-16 Tom Tromey <tom@tromey.com>
* python/py-tui.c (tui_py_window::~tui_py_window): Handle case
where m_window==nullptr.
gdb/testsuite/ChangeLog
2020-06-16 Tom Tromey <tom@tromey.com>
* gdb.python/tui-window.py (failwin): New function. Register it
as a TUI window type.
* gdb.python/tui-window.exp: Create new "fail" layout. Test it.
Two functions in gdb.python/py-nested-maps.c are missing return
values. This causes clang to fail to compile the file with the
following error:
warning: control reaches end of non-void function [-Wreturn-type]
This commit fixes, by causing the two functions to return pointers
to the objects they've just allocated and initialized. I didn't
investigate how this test had been passing with other compilers;
I'm assuming serendipity, that in each function the value to be
returned was already in the register it would need to be in to be
the function's return value.
gdb/testsuite/ChangeLog:
* gdb.python/py-nested-maps.c (create_map): Add missing return
value.
(create_map_map): Likewise.
In lib/tuiterm.exp the builtin spawn is overridden by a tui-specific version.
After running the first test-case that imports tuiterm.exp, the override
remains active, so it can cause trouble in subsequent test-cases, even if they
do not import tuiterm.exp. See f.i. commit c8d4f6dfd9 "[gdb/testsuite] Fix
spawn in tuiterm.exp".
Fix this by:
- adding a variable gdb_finish_hooks which is a list of procs to run during
gdb_finish
- adding a proc tuiterm_env that is used in test-cases instead of
"load_lib tuiterm.exp".
- letting tuiterm_env:
- install the tui-specific spawn version, and
- use the gdb_finish_hooks to schedule restoring the builtin spawn
version.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-12 Tom de Vries <tdevries@suse.de>
* lib/tuiterm.exp (spawn): Rename to ...
(tui_spawn): ... this.
(toplevel): Move rename of spawn ...
(gdb_init_tuiterm): ... here. New proc.
(gdb_finish_tuiterm): New proc.
* lib/gdb.exp (gdb_finish_hooks): New global var.
(gdb_finish): Handle gdb_finish_hooks.
(tuiterm_env): New proc.
* gdb.python/tui-window.exp: Replace load_lib tuiterm.exp with
tuiterm_env.
* gdb.tui/basic.exp: Same.
* gdb.tui/corefile-run.exp: Same.
* gdb.tui/empty.exp: Same.
* gdb.tui/list-before.exp: Same.
* gdb.tui/list.exp: Same.
* gdb.tui/main.exp: Same.
* gdb.tui/new-layout.exp: Same.
* gdb.tui/regs.exp: Same.
* gdb.tui/resize.exp: Same.
* gdb.tui/tui-layout-asm-short-prog.exp: Same.
* gdb.tui/tui-layout-asm.exp: Same.
* gdb.tui/tui-missing-src.exp: Same.
* gdb.tui/winheight.exp: Same.
When running the testsuite with clang, a number of testcases fail to
build with the following errors:
warning: control reaches end of non-void function [-Wreturn-type]
warning: control may reach end of non-void function [-Wreturn-type]
This prevents a number of testcases from executing. This commit fixes.
gdb/testsuite/ChangeLog:
* gdb.base/info-os.c (main): Add return statement.
* gdb.base/info_minsym.c (minsym_fun): Likewise.
* gdb.base/large-frame-2.c (func): Likewise.
* gdb.base/pr10179-a.c (foo1, bar1): Likewise.
* gdb.base/pr10179-b.c (foo2): Likewise.
* gdb.base/valgrind-disp-step.c (foo): Likewise.
* gdb.base/watch-cond.c (func): Likewise.
* gdb.multi/goodbye.c (verylongfun): Likewise.
* gdb.multi/hello.c (commonfun): Likewise.
* gdb.python/py-finish-breakpoint.c (call_longjmp): Likewise.
* gdb.threads/fork-plus-threads.c (thread_func): Likewise.
* gdb.threads/forking-threads-plus-breakpoint.c (thread_forks):
Likewise.
* gdb.threads/hand-call-new-thread.c (foo): Likewise.
* gdb.threads/interrupt-while-step-over.c (child_function):
Likewise.
* gdb.trace/actions-changed.c (end): Likewise.
gdb/testsuite/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
* gdb.python/py-format-string.exp: Adjust pretty_arrays expected
output to the new format.
With target board debug-types, we have these FAILs:
...
FAIL: gdb.guile/scm-symtab.exp: test simple_struct in static symbols
FAIL: gdb.python/py-symtab.exp: test simple_struct in static symbols
...
due to PR gcc/90232, as explained in commit 15cd93d05e "[gdb/symtab] Handle
struct decl with DW_AT_signature".
Marks these as XFAILs.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-29 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (debug_types): New proc.
* gdb.guile/scm-symtab.exp: Add xfail for PR gcc/90232.
* gdb.python/py-symtab.exp: Same.
The DWARF reader has had some odd code since the "physname" patches landed.
In particular, these patches caused PR symtab/12707; namely, they made
it so "set print demangle off" no longer works.
This patch attempts to fix the problem. It arranges to store the
linkage name on the symbol if it exists, and it changes the DWARF
reader so that the demangled name is no longer (usually) stored in the
symbol's "linkage name" field.
c-linkage-name.exp needed a tweak, because it started working
correctly. This conforms to what I think ought to happen, so this
seems like an improvement here.
compile-object-load.c needed a small change to use
symbol_matches_search_name rather than directly examining the linkage
name. Looking directly at the name does the wrong thing for C++.
There is still some name-related confusion in the DWARF reader:
* "physname" often refers to the logical name and not what I would
consider to be the "physical" name;
* dwarf2_full_name, dwarf2_name, and dwarf2_physname all exist and
return different strings -- but this seems like at least one name
too many. For example, Fortran requires dwarf2_full_name, but other
languages do not.
* To my surprise, dwarf2_physname prefers the form emitted by the
demangler over the one that it computes. This seems backward to me,
given that the partial symbol reader prefers the opposite, and it
seems to me that this choice may perform better as well.
I didn't attempt to clean up these things. It would be good to do,
but whenever I contemplate it I get caught up in dreams of truly
rewriting the DWARF reader instead.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
PR symtab/12707:
* dwarf2/read.c (add_partial_symbol): Use the linkage name if it
exists.
(new_symbol): Likewise.
* compile/compile-object-load.c (get_out_value_type): Use
symbol_matches_search_name.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
PR symtab/12707:
* gdb.python/py-symbol.exp: Update expected results for
linkage_name test.
* gdb.cp/print-demangle.exp: New file.
* gdb.base/c-linkage-name.exp: Fix test.
* gdb.guile/scm-symbol.exp: Update expected results for
linkage_name test.
This patch adds support for writing new TUI windows in Python.
2020-02-22 Tom Tromey <tom@tromey.com>
* NEWS: Add entry for gdb.register_window_type.
* tui/tui-layout.h (window_factory): New typedef.
(tui_register_window): Declare.
* tui/tui-layout.c (saved_tui_windows): New global.
(tui_apply_current_layout): Use it.
(tui_register_window): New function.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_tui.
(python_GdbMethods): Add "register_window_type" function.
* python/python-internal.h (gdbpy_register_tui_window)
(gdbpy_initialize_tui): Declare.
* python/py-tui.c: New file.
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-tui.c.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* python.texi (Python API): Add menu item.
(TUI Windows In Python): New node.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.python/tui-window.exp: New file.
* gdb.python/tui-window.py: New file.
Change-Id: I85fbfb923a1840450a00a7dce113a05d7f048baa
When running gdb.python/lib-types.exp, we have an xpass:
...
(gdb) python print (str (typedef_const_typedef_class1_ref_obj.type))^M
typedef_const_typedef_class1_ref^M
(gdb) XPASS: gdb.python/lib-types.exp: \
python print (str (typedef_const_typedef_class1_ref_obj.type)) \
(PRMS gcc/55641)
...
When running the same with gcc 4.8, we have an xfail instead:
...
(gdb) python print (str (typedef_const_typedef_class1_ref_obj.type))^M
const typedef_const_typedef_class1_ref^M
(gdb) XFAIL: gdb.python/lib-types.exp: \
python print (str (typedef_const_typedef_class1_ref_obj.type)) \
(PRMS gcc/55641)
...
Fix the xpass by xfailing only for the gcc 4.8 pattern.
Tested on x86_64-linux, with:
- gcc 7.5.0
- gcc 4.8.5
- clang 5.0.2
gdb/testsuite/ChangeLog:
2020-02-19 Tom de Vries <tdevries@suse.de>
* gdb.python/lib-types.exp: Make xfail more strict.
PR symtab/12535 points out that gdb.decode_line("") will cause a
valgrind report.
I think the empty linespec does not really make sense. So, this patch
changes gdb.decode_line to treat a whitespace-only linespec the same
as a non-existing argument.
gdb/ChangeLog
2020-01-14 Tom Tromey <tom@tromey.com>
PR symtab/12535:
* python/python.c (gdbpy_decode_line): Treat empty string the same
as no argument.
gdb/testsuite/ChangeLog
2020-01-14 Tom Tromey <tom@tromey.com>
PR symtab/12535:
* gdb.python/python.exp: Test decode_line with empty string
argument.
Change-Id: I1d95812b4b7a21d69a3e9afd05b9e3141a931897
This commit extends the CLI a bit for multi-target, in three ways.
#1 - New "info connections" command.
This is a new command that lists the open connections (process_stratum
targets). For example, if you're debugging two remote connections, a
couple local/native processes, and a core dump, all at the same time,
you might see something like this:
(gdb) info connections
Num What Description
1 remote 192.168.0.1:9999 Remote serial target in gdb-specific protocol
2 remote 192.168.0.2:9998 Remote serial target in gdb-specific protocol
* 3 native Native process
4 core Local core dump file
#2 - New "info inferiors" "Connection" column
You'll also see a new matching "Connection" column in "info
inferiors", showing you which connection an inferior is bound to:
(gdb) info inferiors
Num Description Connection Executable
1 process 18526 1 (remote 192.168.0.1:9999) target:/tmp/a.out
2 process 18531 2 (remote 192.168.0.2:9998) target:/tmp/a.out
3 process 19115 3 (native) /tmp/prog1
4 process 6286 4 (core) myprogram
* 5 process 19122 3 (native) /bin/hello
#3 - Makes "add-inferior" show the inferior's target connection
"add-inferior" now shows you the connection you've just bound the
inferior to, which is the current process_stratum target:
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote localhost:2346)
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* Makefile.in (COMMON_SFILES): Add target-connection.c.
* inferior.c (uiout_field_connection): New function.
(print_inferior): Add new "connection-id" column.
(add_inferior_command): Show connection number/string of added
inferior.
* process-stratum-target.h
(process_stratum_target::connection_string): New virtual method.
(process_stratum_target::connection_number): New field.
* remote.c (remote_target::connection_string): New override.
* target-connection.c: New file.
* target-connection.h: New file.
* target.c (decref_target): Remove process_stratum targets from
the connection list.
(target_stack::push): Add process_stratum targets to the
connection list.
gdb/testsuite/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdb.base/kill-detach-inferiors-cmd.exp: Adjust expected output
of "add-inferior".
* gdb.base/quit-live.exp: Likewise.
* gdb.base/remote-exec-file.exp: Likewise.
* gdb.guile/scm-progspace.exp: Likewise.
* gdb.linespec/linespec.exp: Likewise.
* gdb.mi/new-ui-mi-sync.exp: Likewise.
* gdb.mi/user-selected-context-sync.exp: Likewise.
* gdb.multi/multi-target.exp (setup): Add "info connection" and
"info inferiors" tests.
* gdb.multi/remove-inferiors.exp: Adjust expected output of
"add-inferior".
* gdb.multi/watchpoint-multi.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.server/extended-remote-restart.exp: Likewise.
* gdb.threads/fork-plus-threads.exp: Adjust expected output of
"info inferiors".
* gdb.threads/forking-threads-plus-breakpoint.exp: Likewise.
* gdb.trace/report.exp: Likewise.
The option framework documentation was speaking about a 'print -raw'
option, but this option does not exist.
This patch implements -raw-values option that tells to ignore the
active pretty printers when printing a value.
As we already have -raw-frame-arguments, I thought -raw-values
was more clear, in particular to differentiate
set print raw-values and set print raw-frame-arguments.
gdb/doc/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Command Options): Use -p and -pretty in the example,
as -r is ambiguous. Update the print - TAB TAB completion result.
(Data): Document new option -raw-values. Use -p and -pretty in the
example, as -r is ambiguous.
(Print Settings): Document set print raw values.
(Pretty-Printer Commands): Document interaction between enabled
pretty printers and -raw-values/-raw-frame-arguments.
gdb/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Document -raw-values option and the related setting commands.
* printcmd.c (print_command_parse_format): Do not set opts->raw off,
only set it on when /r is given.
* valprint.c (value_print_option_defs): New element raw-values.
* Makefile.in: Add the new file.
gdb/testsuite/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/options.exp: Add -raw-values in the print completion list.
* gdb.python/py-prettyprint.exp: Add tests for -raw-values.
The documentation for make-breakpoint from the Guile API and the `spec'
variant of the gdb.Breakpoint constructor from the Python API state that
the format acceptable for location strings is the same as that accepted
by the break command. However, using the -probe qualifier at the
beginning of the location string causes a GDB internal error as it
attempts to decode a probe location in the wrong code path. Without this
functionality, there doesn't appear to be another way to set breakpoints
on probe points from Python or Guile scripts.
This patch introduces a new helper function that returns a
breakpoint_ops instance appropriate for a parsed location and updates
the Guile and Python bindings to use said function, rather than the
current hard-coded use of bkpt_breakpoint_ops. Since this logic is
duplicated in the handling of the `break' and `trace' commands, those
are also updated to call into the new helper function.
gdb/ChangeLog:
2019-12-10 George Barrett <bob@bob131.so>
Fix scripted probe breakpoints.
* breakpoint.c (tracepoint_probe_breakpoint_ops): Move
declaration forward.
(breakpoint_ops_for_event_location_type)
(breakpoint_ops_for_event_location): Add function definitions.
(break_command_1, trace_command): Use
breakpoint_ops_for_event_location.
* breakpoint.h (breakpoint_ops_for_event_location): Add function
declarations.
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use
breakpoint_ops_for_event_location.
* python/py-breakpoint.c (bppy_init): Use
breakpoint_ops_for_event_location.
gdb/testsuite/ChangeLog:
2019-12-10 George Barrett <bob@bob131.so>
Test scripted probe breakpoints.
* gdb.guile/scm-breakpoint.c (main): Add probe point.
* gdb.python/py-breakpoint.c (main): Likewise.
* gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe
specifier test.
* gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise.
Commit 33d569b709 ("gdb/python: Return
None from Progspace.block_for_pc on error") added a few tests on
gdb.python/py-progspace.exp which use 'print', but forgot to use
parentheses when passing the arguments to be printed. This fails on
Python 3.
This commit adds these missing parentheses. Pushed as obvious.
gdb/testsuite/ChangeLog:
2019-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.python/py-progspace.exp: Add missing parentheses on some
'print' commands.
Change-Id: Iac0a7578855d128bbee3b98e7ea5888dae55fc00
If gdb.lookup_static_symbol is going to return a single symbol then it
makes sense (I think) for it to return a context sensitive choice of
symbol, that is the global static symbol that would be visible to the
program at that point.
However, if the user of the python API wants to instead get a
consistent set of global static symbols, no matter where they stop,
then they have to instead consider all global static symbols with a
given name - there could be many. That is what this new API function
offers, it returns a list (possibly empty) of all global static
symbols matching a given name (and optionally a given symbol domain).
gdb/ChangeLog:
* python/py-symbol.c (gdbpy_lookup_static_symbols): New
function.
* python/python-internal.h (gdbpy_lookup_static_symbols):
Declare new function.
* python/python.c (python_GdbMethods): Add
gdb.lookup_static_symbols method.
* NEWS: Mention gdb.lookup_static_symbols.
gdb/testsuite/ChangeLog:
* gdb.python/py-symbol.exp: Add test for
gdb.lookup_static_symbols.
gdb/doc/ChangeLog:
* python.texi (Symbols In Python): Add documentation for
gdb.lookup_static_symbols.
Change-Id: I1153b0ae5bcbc43b3dcf139043c7a48bf791e1a3
When using gdb.lookup_static_symbol I think that GDB should find
static symbols (global symbol with static linkage) from the current
object file ahead of static symbols from other object files.
This means that if we have two source files f1.c and f2.c, and both
files contains 'static int foo;', then when we are stopped in f1.c a
call to 'gdb.lookup_static_symbol ("foo")' will find f1.c::foo, and if
we are stopped in f2.c we would find 'f2.c::foo'.
Given that gdb.lookup_static_symbol always returns a single symbol,
but there can be multiple static symbols with the same name GDB is
always making a choice about which symbols to return. I think that it
makes sense for the choice GDB makes in this case to match what a user
would get on the command line if they asked to 'print foo'.
gdb/testsuite/ChangeLog:
* gdb.python/py-symbol.c: Declare and call function from new
py-symbol-2.c file.
* gdb.python/py-symbol.exp: Compile both source files, and add new
tests for gdb.lookup_static_symbol.
* gdb.python/py-symbol-2.c: New file.
gdb/doc/ChangeLog:
* python.texi (Symbols In Python): Extend documentation for
gdb.lookup_static_symbol.
gdb/ChangeLog:
* python/py-symbol.c (gdbpy_lookup_static_symbol): Lookup in
static block of current object file first. Also fix typo in
header comment.
Change-Id: Ie55dbeb8806f35577b46015deecde27a0ca2ab64
The documentation for Progspace.block_for_pc says:
Return the innermost gdb.Block containing the given pc value. If the
block cannot be found for the pc value specified, the function will
return None.
However, the implementation actually throws an error for invalid
addresses, like this:
(gdb) python print gdb.current_progspace ().block_for_pc (1)
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Cannot locate object file for block.
Error while executing Python code.
(gdb)
This has been the behaviour since the command was first added (when
the documentation was still as above) in this commit:
commit f3e9a8177c
Date: Wed Feb 24 21:18:28 2010 +0000
Since that commit the code in question has moved around, but the
important parts are largely unchanged. The function in question is
now in py-progspace.c:pspy_block_for_pc.
Examining the code shows that the real state is more complex than just
the function throws an error instead of returning None, instead the
real situation is:
1. If we can't find a compilation unit for the $pc value then we
throw an error, but
2. If we can find a compilation unit, but can't find a block within
the compilation unit for the $pc then return None.
I suspect for most users of the Python API this distinction is
irrelevant, and I propose that we standardise on one single failure
mechanism.
Given the function can currently return None in some cases, and is
documented to return None on error, I propose we make that the case
for all error paths, which is what this patch does.
As the Progspace.block_for_pc method is currently untested, I've added
some basic tests including for a call with an invalid $pc.
This is potentially an API breaking change, though an undocumented
part of the API. Also, users should have been checking and handling a
None return value anyway, so my hope is that this shouldn't be too
disruptive.
gdb/ChangeLog:
* python/py-progspace.c (pspy_block_for_pc): Return None for all
error paths.
gdb/testsuite/ChangeLog:
* gdb.python/py-progspace.exp: Add tests for the
Progspace.block_for_pc method.
Change-Id: I9cea8d2132902bcad0013d1fd39080dd5423cc57
This commit removes some, but not all, of the test name duplication
within the gdb.python tests. On my local machine this takes the
number of duplicate test names in this set of tests from 174 to 85.
It is possible that different setups might encounter more duplicate
tests.
gdb/testsuite/ChangeLog:
* gdb.python/py-parameter.exp: Make test names unique.
* gdb.python/py-template.exp: Likewise.
* gdb.python/py-value.exp: Likewise.
GDB's py-format-string test case depends on endianness. In particular it
relies on the first byte of the machine representation of 42 (as an int)
to be 42 as well. While this is indeed the case for little-endian
machines, big-endian machines store a zero in the first byte instead. The
wrong assumption leads to lots of FAILs on such architectures.
Fix this by filling the affected union with bytes of the same value, such
that endianness does not matter. Use the value 42, to keep the character
in the first byte unchanged.
gdb/testsuite/ChangeLog:
* gdb.python/py-format-string.c (string.h): New include.
(main): Fill a_struct_with_union.the_union.an_int with bytes of
the same value, for endianness-independence.
* gdb.python/py-format-string.exp (default_regexp_dict)
(test_pretty_structs, test_format): Adjust expected output to the
changed initialization.
The way unrecognized escape sequences are handled has changed in
Python 3.8: users now see a SyntaxWarning message, which will
eventually become a SyntaxError in future versions of Python:
(gdb) source /blabla/gdb.python/py-xmethods/py-xmethods.py
/blabla/gdb.python/py-xmethods/py-xmethods.py:204: SyntaxWarning: invalid escape seque
nce \+
'operator\+',
/blabla/gdb.python/py-xmethods/py-xmethods.py:211: SyntaxWarning: invalid escape seque
nce \+
'operator\+\+',
One of our testcases, gdb.python/py-xmethods.exp, contains strings in
the form of "operator\+". This is not recognized by Python, but is
still needed by the testsuite to work properly. The solution is
simple: we just have to make sure these strings are marked as
raw (i.e, r""). This is what this patch does. I took the opportunity
to also convert other strings to raw, which, in two cases, allowed the
removal of an extra backslash.
I tested this using Python 3.7 and Python 3.8, and everything works
fine.
I think I could push this as obvious, but decided to send it to
gdb-patches just in case.
gdb/testsuite/ChangeLog:
2019-08-26 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.python/py-xmethods.exp: Use raw strings when passing
arguments to SimpleXMethodMatcher.
I could not tell if GdbSetPythonDirectory is internal or not because
I could not find any references to it, so I left it as-is.
Tested by running the testsuite on gdb.python/*.exp; everything still
passes.
2019-08-15 Christian Biesinger <cbiesinger@google.com>
* python/lib/gdb/__init__.py (GdbOutputFile): Rename to have a
leading underscore.
(GdbOutputErrorFile): Likewise.
(global scope): Adjust constructor calls to GdbOutput{,Error}File
accordingly.
(execute_unwinders): Rename to have a leading underscore.
(auto_load_packages): Likewise.
(global scope): Adjust call to auto_load_packages accordingly.
(GdbSetPythonDirectory): Likewise.
* python/py-unwind.c (pyuw_sniffer): Call _execute_unwinders
instead of execute_unwinders.
gdb/testsuite/ChangeLog:
2019-08-15 Christian Biesinger <cbiesinger@google.com>
* gdb.python/python.exp: Expect a leading underscore on
GdbOutput{,Error}File.
This patch fixes several test ERRORs and FAILs seen from running
gdb.python tests on a remote Windows host. The problems fixed
generally fall into these categories:
- Failure to copy the .py script to the host.
- Confusion between build and host pathnames.
- Assuming pathnames printed on the host include "/" as a directory
separator.
- Tests that need to be conditionally disabled due to missing features
on the host, etc.
2019-08-13 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.python/py-completion.exp: Download the .py file to the host
and use its host pathname. Conditionalize tests that use
tab completion and manipulate files on the build machine.
* gdb.python/py-events.exp: Download the .py file to the host
and use its host pathname.
* gdb.python/py-evsignal.exp: Likewise.
* gdb.python/py-evthreads.exp: Likewise.
* gdb.python/py-framefilter-invalidarg.exp: Match Windows
pathname syntax.
* gdb.python/py-framefilter.exp: Download the .py file to the right
place on the host. Match Windows pathname syntax.
* gdb.python/py-mi-var-info-path-expression.exp: Download the
.py file to the host and use its host pathname.
* gdb.python/py-objfile-script.exp: Match Windows pathname syntax.
* gdb.python/py-objfile.exp: Expect a host pathname, not a
build pathname. Skip symlink test on Windows host. Add missing
newline at end of file.
* gdb.python/py-pp-maint.exp: Download the .py file to the host
and use its host pathname.
* gdb.python/py-pp-registration.exp: Match Windows pathname syntax.
* gdb.python/py-section-script.exp: Use host location of binfile
on safe-path. Use correct path separator on Windows host.
Reorder alternatives in gdb_test_multiple to prevent matching
the wrong alternative on success.
* gdb.python/py-symtab.exp: Match Windows pathname syntax.
Currently we support iteration on blocks; this patch extends that to make
subscript access work as well.
gdb/ChangeLog:
2019-08-05 Christian Biesinger <cbiesinger@google.com>
* NEWS: Mention dictionary access on blocks.
* python/py-block.c (blpy_getitem): New function.
(block_object_as_mapping): New struct.
(block_object_type): Use new struct for tp_as_mapping field.
gdb/doc/ChangeLog:
2019-08-05 Christian Biesinger <cbiesinger@google.com>
* python.texi (Blocks In Python): Document dictionary access on blocks.
gdb/testsuite/ChangeLog:
2019-08-05 Christian Biesinger <cbiesinger@google.com>
* gdb.python/py-block.exp: Test dictionary access on blocks.
Similar to lookup_global_symbol, except that it checks the
STATIC_SCOPE.
gdb/ChangeLog:
2019-07-30 Christian Biesinger <cbiesinger@google.com>
PR/24474: Add a function to lookup static variables.
* NEWS: Mention this new function.
* python/py-symbol.c (gdbpy_lookup_static_symbol): New function.
* python/python-internal.h (gdbpy_lookup_static_symbol): New function.
* python/python.c (python_GdbMethods): Add new function.
gdb/doc/ChangeLog:
2019-07-30 Christian Biesinger <cbiesinger@google.com>
* python.texi (Symbols In Python): Document new function
gdb.lookup_static_symbol.
gdb/testsuite/ChangeLog:
2019-07-30 Christian Biesinger <cbiesinger@google.com>
* gdb.python/py-symbol.c: Add a static variable and one in an anonymous
namespace.
* gdb.python/py-symbol.exp: Test gdb.lookup_static_symbol.
This is essentially the inverse of Symbol.objfile. This allows
handling different symbols with the same name (but from different
objfiles) and can also be faster if the objfile is known.
gdb/ChangeLog:
2019-07-29 Christian Biesinger <cbiesinger@google.com>
* NEWS: Mention new functions Objfile.lookup_{global,static}_symbol.
* python/py-objfile.c (objfpy_lookup_global_symbol): New function.
(objfpy_lookup_static_symbol): New function.
(objfile_object_methods): Add new functions.
gdb/doc/ChangeLog:
2019-07-29 Christian Biesinger <cbiesinger@google.com>
* python.texi (Objfiles In Python): Document new functions
Objfile.lookup_{global,static}_symbol.
gdb/testsuite/ChangeLog:
2019-07-29 Christian Biesinger <cbiesinger@google.com>
* gdb.python/py-objfile.c: Add global and static vars.
* gdb.python/py-objfile.exp: Test new functions Objfile.
lookup_global_symbol and lookup_static_symbol.
Updated tests to test the new options and new values.
Test the default for print_what in python frame filtering.
Updated the tests impacted by the default in python frame filtering
which is now consistent with the backtrace command.
gdb/testsuite/ChangeLog
2019-07-29 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/options.exp: Update backtrace - completion to
new option -frame-info.
* gdb.base/frame-args.exp: Test new 'frame-arguments presence'.
Test new 'set print frame-info'. Test backtrace -frame-info
overriding 'set print frame-info'.
* gdb.python/py-framefilter.exp: Test new 'frame-arguments presence'.
Test new 'set print frame-info'.
Verify consistency of backtrace with and without filters, with and
without -no-filters.
* gdb.python/py-framefilter-invalidarg.exp: Update to new print_what
default.
when running python/python.exp with check-read1, we get:
...
(gdb) PASS: gdb.python/python.exp: prompt substitution readline - end
python gdb.prompt_hook = error_prompt^M
Python Exception <type 'exceptions.RuntimeError'> Python exception calledPASS: gdb.python/python.exp: set hook
: ^M
(gdb) PASS: gdb.python/python.exp: set the hook to default
python gdb.prompt_hook = None^M
(gdb) PASS: gdb.python/python.exp: set print-stack full for prompt error test
set python print-stack full^M
(gdb) FAIL: gdb.python/python.exp: set the hook
python gdb.prompt_hook = error_prompt^M
Traceback (most recent call last):^M
File "<string>", line 3, in error_prompt^M
RuntimeError: Python exception called^M
(gdb) FAIL: gdb.python/python.exp: set the hook to default
...
The problem is that gdb_test_multiple here:
...
gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook" {
-re "Python Exception (exceptions.RuntimeError|<(type 'exceptions.|class ')RuntimeError'>) Python excepti
on called.*" {
pass "set hook"
}
}
...
specifies a regexp that ends with ".*" but doesn't specify the expected
$gdb_prompt.
Consequently, due to check-read1, the ".*" is matched to "" and the remaining
$gdb_prompt is read by the the following gdb_py_test_silent_cmd, which has
its own $gdb_prompt read by the following gdb_py_test_silent_cmd, which has
its own $gdb_prompt causing a mismatch for the following gdb_test_multiple:
...
gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook" {
-re "Traceback.*File.*line.*RuntimeError.*Python exception called.*" {
pass "set hook"
}
}
...
which causes both FAILs.
The second gdb_test_multiple has the same problem as the first, but it happens
not to cause a FAIL because it's followed by a gdb_py_test_silent_cmd and a
clean_restart.
Fix the regexps in both gdb_test_multiple calls.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
* gdb.python/python.exp: Don't terminate gdb_test_multiple regexp
with ".*".
Currently, with:
(gdb) catch catch
Catchpoint 1 (catch)
(gdb) catch throw
Catchpoint 2 (throw)
(gdb) catch rethrow
Catchpoint 3 (rethrow)
You get:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000b122af exception catch
2 breakpoint keep y 0x0000000000b1288d exception throw
3 breakpoint keep y 0x0000000000b12931 exception rethrow
I think it doesn't make much sense usability-wise, to show a
catchpoint as a breakpoint. The fact that GDB sets a breakpoint at
some magic address in the C++ run time is an implementation detail,
IMO. And as seen in the previous patch, such a catchpoint can end up
with more than one location/address even, so showing a single address
isn't entirely accurate.
This commit hides the addresses from view, and makes GDB show
"catchpoint" for type as well:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 catchpoint keep y exception catch
2 catchpoint keep y exception throw
3 catchpoint keep y exception rethrow
This comment in the code seems telling:
/* We need to reset 'type' in order for code in breakpoint.c to do
the right thing. */
cp->type = bp_breakpoint;
It kind of suggests that the reason catchpoints end up shown as
breakpoints was that it was easier to implement them that way, rather
than a desired property.
This commit fixes things up to make it possible to have bp_catch
breakpoints have software/hardware breakpoint locations, thus
eliminating the need for that hack:
- redo breakpoint_address_is_meaningful in terms of the location's
type rather than breakpoint type.
- teach bpstat_what about stepping over the catchpoint locations.
- install a allocate_location method for "catch catch/throw/rethrow",
one that forces the location type.
Note that this also reverts the gdb hunk from:
commit 2a8be20359
Commit: Tom Tromey <tom@tromey.com>
CommitDate: Sat Oct 6 22:17:45 2018 -0600
Fix Python gdb.Breakpoint.location crash
because now "catch throw" catchpoints hit the
if (obj->bp->type != bp_breakpoint)
Py_RETURN_NONE;
check above, and, adjusts the testcase to no longer expect to see the
catchpoint in the gdb.breakpoints() list.
(Note: might make sense to do the same to Ada exception catchpoints.)
gdb/ChangeLog:
2019-07-09 Pedro Alves <palves@redhat.com>
* break-catch-throw.c (print_one_exception_catchpoint): Skip the
"addr" field.
(allocate_location_exception_catchpoint): New.
(handle_gnu_v3_exceptions): Don't reset 'type' to bp_breakpoint.
(initialize_throw_catchpoint_ops): Install
allocate_location_exception_catchpoint as allocate_location
method.
* breakpoint.c (bpstat_what) <bp_catch>: Set action to
BPSTAT_WHAT_SINGLE if not stopping and the location's type is not
bp_loc_other.
(breakpoint_address_is_meaningful): Delete.
(bl_address_is_meaningful): New.
(breakpoint_locations_match): Adjust comment.
(bp_location_from_bp_type): New, factored out of...
(bp_location::bp_location(breakpoint *)): ... this.
(bp_location::bp_location(breakpoint *, bp_loc_type)): New,
factored out of...
(bp_location::bp_location(breakpoint *)): ... this. Reimplement.
(bp_loc_is_permanent): Use bl_address_is_meaningful instead of
breakpoint_address_is_meaningful.
(bp_locations_compare): Adjust comment.
(update_global_location_list): Use bl_address_is_meaningful
instead of breakpoint_address_is_meaningful.
* breakpoint.h (bp_location::bp_location(breakpoint *)): New
explicit.
(bp_location::bp_location(breakpoint *, bp_loc_type)): Declare.
* python/py-breakpoint.c (bppy_get_location): No longer check
whether location is null.
gdb/doc/ChangeLog:
2019-07-09 Pedro Alves <palves@redhat.com>
* gdb.texinfo (C++ Exception GDB/MI Catchpoint Commands): Adjust
examples to show type=catchpoint instead of type=breakpoint and an
address.
gdb/testsuite/ChangeLog:
2019-07-09 Pedro Alves <palves@redhat.com>
* gdb.cp/catch-multi-stdlib.exp: Adjust expected "info
breakpoints" output.
* gdb.cp/exception.exp: Adjust expected "info breakpoints" output.
* gdb.python/py-breakpoint.exp: No longer expect that "catch
throw" creates breakpoint.
* gdb.mi/mi-catch-cpp-exceptions.exp (setup_catchpoint): Expect
'type="catchpoint"'.
