In add_setshow_generic, we create set/show commands using add_setshow_*
functions, then look up the commands by name to set the context pointer.
It would be simpler and more efficient to use the return values of the
add_setshow_* functions, do that.
gdb/ChangeLog:
* python/py-param.c (add_setshow_generic): Use return values of
add_setshow functions.
Change-Id: I04d50736e1001ddb732d81e088468876df9c88ff
Remove a few instances where we look up a command by name, but could
just use the return value of a previous "add command" function call
instead.
gdb/ChangeLog:
* mi/mi-main.c (_initialize_mi_main):
* python/py-auto-load.c (gdbpy_initialize_auto_load):
* remote.c (_initialize_remote):
Change-Id: I6d06f9ca636e340c88c1064ae870483ad392607d
tui_win_info::refresh_window first redraws the background window, then
tui_wrefresh draws the python text on top of it, which flickers.
By using wnoutrefresh for the background window, the actual drawing on
the screen is only done once, without flickering.
gdb/ChangeLog:
2021-05-24 Hannes Domani <ssbssa@yahoo.de>
* python/py-tui.c (tui_py_window::refresh_window):
Avoid flickering.
Same idea as the previous patch, but for prefix instead of alias.
gdb/ChangeLog:
* cli/cli-decode.h (cmd_list_element) <is_prefix>: New, use it.
Change-Id: I76a9d2e82fc8d7429904424674d99ce6f9880e2b
While browsing this code, I found the name "prefixlist" really
confusing. I kept reading it as "list of prefixes". Which it isn't:
it's a list of sub-commands, for a prefix command. I think that
renaming it to "subcommands" would make things clearer.
gdb/ChangeLog:
* Rename "prefixlist" parameters to "subcommands" throughout.
* cli/cli-decode.h (cmd_list_element) <prefixlist>: Rename to...
<subcommands>: ... this.
* cli/cli-decode.c (lookup_cmd_for_prefixlist): Rename to...
(lookup_cmd_with_subcommands): ... this.
Change-Id: I150da10d03052c2420aa5b0dee41f422e2a97928
Define a 'connection_num' attribute for Inferior objects. The
read-only attribute is the ID of the connection of an inferior, as
printed by "info inferiors". In GDB's internal terminology, that's
the process stratum target of the inferior. If the inferior has no
target connection, the attribute is None.
gdb/ChangeLog:
2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* python/py-inferior.c (infpy_get_connection_num): New function.
(inferior_object_getset): Add a new element for 'connection_num'.
* NEWS: Mention the 'connection_num' attribute of Inferior objects.
gdb/doc/ChangeLog:
2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* python.texi (Inferiors In Python): Mention the 'connection_num'
attribute.
gdb/testsuite/ChangeLog:
2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.python/py-inferior.exp: Add test cases for 'connection_num'.
The 'print max-depth' feature incorrectly causes GDB to skip printing
the string representation of pretty printed variables if the variable
is stored at a nested depth corresponding to the set max-depth value.
This change ensures that it is always printed before checking whether
the maximum print depth has been reached.
Regression tested with GCC 7.3.0 on x86_64, ppc64le, aarch64.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value): Replaced duplicate code.
* guile/scm-pretty-print.c (ppscm_print_children): Check max_depth
just before printing child values.
(gdbscm_apply_val_pretty_printer): Don't check max_depth before
printing string representation.
* python/py-prettyprint.c (print_children): Check max_depth just
before printing child values.
(gdbpy_apply_val_pretty_printer): Don't check max_depth before
printing string representation.
gdb/testsuite/ChangeLog:
* gdb.python/py-format-string.c: Added a variable to test.
* gdb.python/py-format-string.exp: Check string representation is
printed at appropriate max_depth settings.
* gdb.python/py-nested-maps.exp: Likewise.
* gdb.guile/scm-pretty-print.exp: Add additional tests.
This avoids some manual memory management.
cmdpy_init correctly transfers ownership of the name to the
cmd_list_element, as it sets the name_allocated flag. However,
cmdpy_init (and add_setshow_generic) doesn't, it looks like the name is
just leaked. This is a bit tricky, because it actually creates two
commands (one set and one show), it would take a bit of refactoring of
the command code to give each their own allocated copy. For now, just
keep doing what the current code does but in a more explicit fashion,
with an explicit release.
gdb/ChangeLog:
* python/python-internal.h (gdbpy_parse_command_name): Return
gdb::unique_xmalloc_ptr.
* python/py-cmd.c (gdbpy_parse_command_name): Likewise.
(cmdpy_init): Adjust.
* python/py-param.c (parmpy_init): Adjust.
(add_setshow_generic): Take gdb::unique_xmalloc_ptr, release it
when done.
Change-Id: Iae5bc21fe2b22f12d5f954057b0aca7ca4cd3f0d
Previously, the prefixname field of struct cmd_list_element was manually
set for prefix commands. This seems verbose and error prone as it
required every single call to functions adding prefix commands to
specify the prefix name while the same information can be easily
generated.
Historically, this was not possible as the prefix field was null for
many commands, but this was fixed in commit
3f4d92ebdf by Philippe Waroquiers, so
we can rely on the prefix field being set when generating the prefix
name.
This commit also fixes a use after free in this scenario:
* A command gets created via Python (using the gdb.Command class).
The prefix name member is dynamically allocated.
* An alias to the new command is created. The alias's prefixname is set
to point to the prefixname for the original command with a direct
assignment.
* A new command with the same name as the Python command is created.
* The object for the original Python command gets freed and its
prefixname gets freed as well.
* The alias is updated to point to the new command, but its prefixname
is not updated so it keeps pointing to the freed one.
gdb/ChangeLog:
* command.h (add_prefix_cmd): Remove the prefixname argument as
it can now be generated automatically. Update all callers.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.c (add_prefix_cmd): Ditto.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.h (struct cmd_list_element): Replace the
prefixname member variable with a method which generates the
prefix name at runtime. Update all code reading the prefix
name to use the method, and remove all code setting it.
* python/py-cmd.c (cmdpy_destroyer): Remove code to free the
prefixname member as it's now a method.
(cmdpy_function): Determine if the command is a prefix by
looking at prefixlist, not prefixname.
Converts the debug print out in python/py-unwind.c to use the new
debug printing scheme. I have also modified what is printed in a few
places, for example, rather than printing frame pointers, I now print
the frame level, this matches what we do in the general 'set debug
frame' tracing, and is usually more helpful (I think).
I also added a couple of ENTER/EXIT scope printers.
gdb/ChangeLog:
* python/py-unwind.c (pyuw_debug): Convert to bool.
(show_pyuw_debug): New function.
(pyuw_debug_printf): Define.
(PYUW_SCOPED_DEBUG_ENTER_EXIT): Define.
(pyuw_this_id): Convert to new debug print macros.
(pyuw_prev_register): Likewise.
(pyuw_sniffer): Likewise.
(pyuw_dealloc_cache): Likewise.
(_initialize_py_unwind): Update now pyuw_debug is a bool, and add
show function when registering.
Replace fprint_frame_id with a member function frame_id::to_string
that returns a std::string. Convert all of the previous users of
fprint_frame_id to use the new member function. This means that
instead of writing things like this:
fprintf_unfiltered (file, " id=");
fprint_frame_id (file, s->id.id);
We can write this:
fprintf_unfiltered (file, " id=%s", s->id.id.to_string ().c_str ());
There should be no user visible changes after this commit.
gdb/ChangeLog:
* dummy-frame.c (fprint_dummy_frames): Convert use of
fprint_frame_id to use frame_id::to_string.
* frame.c (fprint_field): Delete.
(fprint_frame_id): Moved to...
(frame_id::to_string): ...this, rewritten to return a string.
(fprint_frame): Convert use of fprint_frame_id to use
frame_id::to_string.
(compute_frame_id): Likewise.
(frame_id_p): Likewise.
(frame_id_eq): Likewise.
(frame_id_inner): Likewise.
* frame.h (struct frame_id) <to_string>: New member function.
(fprint_frame_id): Delete declaration.
* guile/scm-frame.c (frscm_print_frame_smob): Convert use of
fprint_frame_id to use frame_id::to_string.
* python/py-frame.c (frame_object_to_frame_info): Likewise.
* python/py-unwind.c (unwind_infopy_str): Likewise.
(pyuw_this_id): Likewise.
Re-format all Python files using black [1] version 21.4b0. The goal is
that from now on, we keep all Python files formatted using black. And
that we never have to discuss formatting during review (for these files
at least) ever again.
One change is needed in gdb.python/py-prettyprint.exp, because it
matches the string representation of an exception, which shows source
code. So the change in formatting must be replicated in the expected
regexp.
To document our usage of black I plan on adding this to the "GDB Python
Coding Standards" wiki page [2]:
--8<--
All Python source files under the `gdb/` directory must be formatted
using black version 21.4b0.
This specific version can be installed using:
$ pip3 install 'black == 21.4b0'
All you need to do to re-format files is run `black <file/directory>`,
and black will re-format any Python file it finds in there. It runs
quite fast, so the simplest is to do:
$ black gdb/
from the top-level.
If you notice that black produces changes unrelated to your patch, it's
probably because someone forgot to run it before you. In this case,
don't include unrelated hunks in your patch. Push an obvious patch
fixing the formatting and rebase your work on top of that.
-->8--
Once this is merged, I plan on setting a up an `ignoreRevsFile`
config so that git-blame ignores this commit, as described here:
https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame
I also plan on working on a git commit hook (checked in the repo) to
automatically check the formatting of the Python files on commit.
[1] https://pypi.org/project/black/
[2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards
gdb/ChangeLog:
* Re-format all Python files using black.
gdb/testsuite/ChangeLog:
* Re-format all Python files using black.
* gdb.python/py-prettyprint.exp (run_lang_tests): Adjust.
Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
Add two new commands to GDB that can be placed into the early
initialization to control how Python starts up. The new options are:
set python ignore-environment on|off
set python dont-write-bytecode auto|on|off
show python ignore-environment
show python dont-write-bytecode
These can be used from GDB's startup file to control how the Python
extension language behaves. These options are equivalent to the -E
and -B flags to python respectively, their descriptions from the
Python man page:
-E Ignore environment variables like PYTHONPATH and PYTHONHOME
that modify the behavior of the interpreter.
-B Don't write .pyc files on import.
gdb/ChangeLog:
* NEWS: Mention new commands.
* python/python.c (python_ignore_environment): New static global.
(show_python_ignore_environment): New function.
(set_python_ignore_environment): New function.
(python_dont_write_bytecode): New static global.
(show_python_dont_write_bytecode): New function.
(set_python_dont_write_bytecode): New function.
(_initialize_python): Register new commands.
gdb/doc/ChangeLog:
* python.texinfo (Python Commands): Mention new commands.
gdb/testsuite/ChangeLog:
* gdb.python/py-startup-opt.exp: New file.
Now that both Python and Guile are fully initialized from their
respective finish_initialization methods, the "finish" in the method
name doesn't really make sense; initialization starts _and_ finishes
with that method.
As such, this commit renames finish_initialization to just initialize.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* extension-priv.h (struct extension_language_ops): Rename
'finish_initialization' to 'initialize'.
* extension.c (finish_ext_lang_initialization): Renamed to...
(ext_lang_initialization): ...this, update comment, and updated
the calls to reflect the change in struct extension_language_ops.
* extension.h (finish_ext_lang_initialization): Renamed to...
(ext_lang_initialization): ...this.
* guile/guile.c (gdbscm_finish_initialization): Renamed to...
(gdbscm_initialize): ...this, update comment at definition.
(guile_extension_ops): Update.
* main.c (captured_main_1): Update call to
finish_ext_lang_initialization.
* python/python.c (gdbpy_finish_initialization): Rename to...
(gdbpy_initialize): ...this, update comment at definition, and
update call to do_finish_initialization.
(python_extension_ops): Update.
(do_finish_initialization): Rename to...
(do_initialize): ...this, and update comment.
Delay Python initialisation until gdbpy_finish_initialization.
This is mostly about splitting the existing gdbpy_initialize_*
functions in two, all the calls to register_objfile_data_with_cleanup,
gdbarch_data_register_post_init, etc are moved into new _initialize_*
functions, but everything else is left in the gdbpy_initialize_*
functions.
Then the call to do_start_initialization (in python/python.c) is moved
from the _initialize_python function into gdbpy_finish_initialization.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* python/py-arch.c (_initialize_py_arch): New function.
(gdbpy_initialize_arch): Move code to _initialize_py_arch.
* python/py-block.c (_initialize_py_block): New function.
(gdbpy_initialize_blocks): Move code to _initialize_py_block.
* python/py-inferior.c (_initialize_py_inferior): New function.
(gdbpy_initialize_inferior): Move code to _initialize_py_inferior.
* python/py-objfile.c (_initialize_py_objfile): New function.
(gdbpy_initialize_objfile): Move code to _initialize_py_objfile.
* python/py-progspace.c (_initialize_py_progspace): New function.
(gdbpy_initialize_pspace): Move code to _initialize_py_progspace.
* python/py-registers.c (_initialize_py_registers): New function.
(gdbpy_initialize_registers): Move code to
_initialize_py_registers.
* python/py-symbol.c (_initialize_py_symbol): New function.
(gdbpy_initialize_symbols): Move code to _initialize_py_symbol.
* python/py-symtab.c (_initialize_py_symtab): New function.
(gdbpy_initialize_symtabs): Move code to _initialize_py_symtab.
* python/py-type.c (_initialize_py_type): New function.
(gdbpy_initialize_types): Move code to _initialize_py_type.
* python/py-unwind.c (_initialize_py_unwind): New function.
(gdbpy_initialize_unwind): Move code to _initialize_py_unwind.
* python/python.c (_initialize_python): Move call to
do_start_initialization to gdbpy_finish_initialization.
(gdbpy_finish_initialization): Add call to
do_start_initialization.
Without any explicit dependencies specified, the observers attached
to the 'gdb::observers::new_objfile' observable are always notified
in the order in which they have been attached.
The new_objfile observer callback to auto-load scripts is attached in
'_initialize_auto_load'.
The new_objfile observer callback that propagates the new_objfile event
to the Python side is attached in 'gdbpy_initialize_inferior', which is
called via '_initialize_python'.
With '_initialize_python' happening before '_initialize_auto_load',
the consequence was that the new_objfile event was emitted on the Python
side before autoloaded scripts had been executed when a new objfile was
loaded.
As a result, trying to access the objfile's pretty printers (defined in
the autoloaded script) from a handler for the Python-side
'new_objfile' event would fail. Those would only be initialized later on
(when the 'auto_load_new_objfile' callback was called).
To make sure that the objfile passed to the Python event handler
is properly initialized (including its 'pretty_printers' member),
make sure that the 'auto_load_new_objfile' observer is notified
before the 'python_new_objfile' one that propagates the event
to the Python side.
To do this, make use of the mechanism to explicitly specify
dependencies between observers (introduced in a preparatory commit).
Add a corresponding testcase that involves a test library with an autoloaded
Python script and a handler for the Python 'new_objfile' event.
(The real world use case where I came across this issue was in an attempt
to extend handling for GDB pretty printers for dynamically loaded
objfiles in the Qt Creator IDE, s. [1] and [2] for more background.)
[1] https://bugreports.qt.io/browse/QTCREATORBUG-25339
[2] https://codereview.qt-project.org/c/qt-creator/qt-creator/+/333857/1
Tested on x86_64-linux (Debian testing).
gdb/ChangeLog:
* gdb/auto-load.c (_initialize_auto_load): 'Specify token
when attaching the 'auto_load_new_objfile' observer, so
other observers can specify it as a dependency.
* gdb/auto-load.h (struct token): Declare
'auto_load_new_objfile_observer_token' as token to be used
for the 'auto_load_new_objfile' observer.
* gdb/python/py-inferior.c (gdbpy_initialize_inferior): Make
'python_new_objfile' observer depend on 'auto_load_new_objfile'
observer, so it gets notified after the latter.
gdb/testsuite/ChangeLog:
* gdb.python/libpy-autoloaded-pretty-printers-in-newobjfile-event.so-gdb.py: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-lib.cc: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-lib.h: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-main.cc: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.py: New test.
Change-Id: I8275b3f4c3bec32e56dd7892f9a59d89544edf89
Give a name to each observer, this will help produce more meaningful
debug message.
gdbsupport/ChangeLog:
* observable.h (class observable) <struct observer> <observer>:
Add name parameter.
<name>: New field.
<attach>: Add name parameter, update all callers.
Change-Id: Ie0cc4664925215b8d2b09e026011b7803549fba0
As reported in bug 27757, we get an internal error when doing:
$ cat test.c
struct foo {
int len;
int items[];
};
struct foo *p;
int main() {
return 0;
}
$ gcc test.c -g -O0 -o test
$ ./gdb -q -nx --data-directory=data-directory ./test -ex 'python gdb.parse_and_eval("p").type.target()["items"].type.range()'
Reading symbols from ./test...
/home/simark/src/binutils-gdb/gdb/gdbtypes.h:435: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This is because the Python code (typy_range) blindly reads the high
bound of the type of `items` as a constant value. Since it is a
flexible array member, it has no high bound, the property is undefined.
Since commit 8c2e4e0689 ("gdb: add accessors to struct dynamic_prop"),
the getters check that you are not getting a property value of the wrong
kind, so this causes a failed assertion.
Fix it by checking if the property is indeed a constant value before
accessing it as such. Otherwise, use 0. This restores the previous GDB
behavior: because the structure was zero-initialized, this is what was
returned before. But now this behavior is explicit and not accidental.
Add a test, gdb.python/flexible-array-member.exp, that is derived from
gdb.base/flexible-array-member.exp. It tests the same things, but
through the Python API. It also specifically tests getting the range
from the various kinds of flexible array member types (AFAIK it wasn't
possible to do the equivalent through the CLI).
gdb/ChangeLog:
PR gdb/27757
* python/py-type.c (typy_range): Check that bounds are constant
before accessing them as such.
* guile/scm-type.c (gdbscm_type_range): Likewise.
gdb/testsuite/ChangeLog:
PR gdb/27757
* gdb.python/flexible-array-member.c: New test.
* gdb.python/flexible-array-member.exp: New test.
* gdb.guile/scm-type.exp (test_range): Add test for flexible
array member.
* gdb.guile/scm-type.c (struct flex_member): New.
(main): Use it.
Change-Id: Ibef92ee5fd871ecb7c791db2a788f203dff2b841
The 'create_breakpoint' function takes a 'parse_extra' argument that
determines whether the condition, thread, and force-condition
specifiers should be parsed from the extra string or be used from the
function arguments. However, for the case when 'parse_extra' is
false, there is no way to pass the force-condition specifier. This
patch adds it as a new argument.
Also, in the case when parse_extra is false, the current behavior is
as if the condition is being forced. This is a bug. The default
behavior should reject the breakpoint. See below for a demo of this
incorrect behavior. (The MI command '-break-insert' uses the
'create_breakpoint' function with parse_extra=0.)
$ gdb -q --interpreter=mi3 /tmp/simple
=thread-group-added,id="i1"
=cmd-param-changed,param="history save",value="on"
=cmd-param-changed,param="auto-load safe-path",value="/"
~"Reading symbols from /tmp/simple...\n"
(gdb)
-break-insert -c junk -f main
&"warning: failed to validate condition at location 1, disabling:\n "
&"No symbol \"junk\" in current context.\n"
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="1.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
(gdb)
break main if junk
&"break main if junk\n"
&"No symbol \"junk\" in current context.\n"
^error,msg="No symbol \"junk\" in current context."
(gdb)
break main -force-condition if junk
&"break main -force-condition if junk\n"
~"Note: breakpoint 1 also set at pc 0x114e.\n"
&"warning: failed to validate condition at location 1, disabling:\n "
&"No symbol \"junk\" in current context.\n"
~"Breakpoint 2 at 0x114e: file /tmp/simple.c, line 2.\n"
=breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="2.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
^done
(gdb)
After applying this patch, we get the behavior below:
(gdb)
-break-insert -c junk -f main
^error,msg="No symbol \"junk\" in current context."
This restores the behavior that is present in the existing releases.
gdb/ChangeLog:
2021-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (create_breakpoint): Add a new parameter,
'force_condition'.
* breakpoint.c (create_breakpoint): Use the 'force_condition'
argument when 'parse_extra' is false to check if the condition
is invalid at all of the breakpoint locations.
Update the users below.
(break_command_1)
(dprintf_command)
(trace_command)
(ftrace_command)
(strace_command)
(create_tracepoint_from_upload): Update.
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update.
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Update.
* python/py-breakpoint.c (bppy_init): Update.
* python/py-finishbreakpoint.c (bpfinishpy_init): Update.
gdb/testsuite/ChangeLog:
2021-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp: Extend with checks for invalid breakpoint
conditions.
Python 3.4 has deprecated the imp module in favour of importlib. This
patch avoids the DeprecationWarning. This warning is visible to users
whose libpython.so has been compiled with --with-pydebug.
Considering that even python 3.5 has reached end of life, would it be
better to just use importlib and drop support for python 3.0 to 3.3?
2021-02-28 Boris Staletic <boris.staletic@gmail.com>
* gdb/python/lib/gdb/__init__.py: Use importlib on python 3.4+
to avoid deprecation warnings.
The small example for gdb.Parameter.get_set_string does not return a
string. The documentation is very clear that this method must return
a string, and indeed, inspecting the code in gdb/python/py-param.c
shows that a string return value is required (if an exception is not
thrown).
While inspecting the code in gdb/python/py-param.c I noticed that the
comment for the C++ code that invokes the Python get_set_string method
is wrong, so I updated that too.
gdb/ChangeLog:
* python/py-param.c (get_set_value): Update header comment.
gdb/doc/ChangeLog:
* python.texinfo (Parameters In Python): Return empty string in
small example code.
This commit:
commit d1cab9876d
Date: Tue Sep 15 11:08:56 2020 -0600
Don't use gdb_py_long_from_ulongest
Introduced a regression when GDB is compiled with Python 2. The frame
filter API expects the gdb.FrameDecorator.function () method to return
either a string (the name of a function) or an address, which GDB then
uses to lookup a msymbol.
If the address returned from gdb.FrameDecorator.function () comes from
gdb.Frame.pc () then before the above commit we would always expect to
see a PyLong object.
After the above commit we might (on Python 2) get a PyInt object.
The GDB code does not expect to see a PyInt, and only checks for a
PyLong, we then see an error message like:
RuntimeError: FrameDecorator.function: expecting a String, integer or None.
This commit just adds an additional call to PyInt_Check which handle
the missing case.
I had already written a test case to cover this issue before spotting
that the gdb.python/py-framefilter.exp test also triggers this
failure. As the new test case is slightly different I have kept it
in.
The new test forces the behaviour of gdb.FrameDecorator.function
returning an address. The reason the existing test case hits this is
due to the behaviour of the builtin gdb.FrameDecorator base class. If
the base class behaviour ever changed then the return an address case
would only be tested by the new test case.
gdb/ChangeLog:
* python/py-framefilter.c (py_print_frame): Use PyInt_Check as
well as PyLong_Check for Python 2.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter-addr.c: New file.
* gdb.python/py-framefilter-addr.exp: New file.
* gdb.python/py-framefilter-addr.py: New file.
The current mechanism by which the Python gdb.current_objfile is
maintained does not allow for nested auto-load events. It is assumed
that once an auto-load script has finished loading then the current
objfile should be set back to NULL. In a nested situation, we should
be restoring the previous value.
We already have an RAII class to handle save/restore type behaviour,
so lets just switch to use that.
The test is a little contrived, but is simple enough, and triggers the
bug. The real use case might involve the auto-load script calling
functions (either in the just-loaded object file, or in the main
executable), which in turn trigger further auto-loads to occur.
gdb/ChangeLog:
* python/python.c (gdbpy_source_objfile_script): Use
make_scoped_restore to restore gdbpy_current_objfile.
(gdbpy_execute_objfile_script): Likewise.
gdb/testsuite/ChangeLog:
* gdb.python/py-auto-load-chaining-f1.c: New file.
* gdb.python/py-auto-load-chaining-f1.o-gdb.py: New file.
* gdb.python/py-auto-load-chaining-f2.c: New file.
* gdb.python/py-auto-load-chaining-f2.o-gdb.py: New file.
* gdb.python/py-auto-load-chaining.c: New file.
* gdb.python/py-auto-load-chaining.exp: New file.
If the user implements a TUI window in Python, and this window
responds to GDB events and then redraws its window contents then there
is currently an edge case which can lead to problems.
The Python API documentation suggests that calling methods like erase
or write on a TUI window (from Python code) will raise an exception if
the window is not valid.
And the description for is_valid says:
This method returns True when this window is valid. When the user
changes the TUI layout, windows no longer visible in the new layout
will be destroyed. At this point, the gdb.TuiWindow will no longer
be valid, and methods (and attributes) other than is_valid will
throw an exception.
From this I, as a user, would expect that if I did 'tui disable' to
switch back to CLI mode, then the window would no longer be valid.
However, this is not the case.
When the TUI is disabled the windows in the TUI are not deleted, they
are simply hidden. As such, currently, the is_valid method continues
to return true.
This means that if the users Python code does something like:
def event_handler (e):
global tui_window_object
if tui_window_object->is_valid ():
tui_window_object->erase ()
tui_window_object->write ("Hello World")
gdb.events.stop.connect (event_handler)
Then when a stop event arrives GDB will try to draw the TUI window,
even when the TUI is disabled.
This exposes two bugs. First, is_valid should be returning false in
this case, second, if the user forgot to add the is_valid call, then I
believe the erase and write calls should be throwing an
exception (when the TUI is disabled).
The solution to both of these issues is I think bound together, as it
depends on having a working 'is_valid' check.
There's a rogue assert added into tui-layout.c as part of this
commit. While working on this commit I managed to break GDB such that
TUI_CMD_WIN was nullptr, this was causing GDB to abort. I'm leaving
the assert in as it might help people catch issues in the future.
This patch is inspired by the work done here:
https://sourceware.org/pipermail/gdb-patches/2020-December/174338.html
gdb/ChangeLog:
* python/py-tui.c (gdbpy_tui_window) <is_valid>: New member
function.
(REQUIRE_WINDOW): Call is_valid member function.
(REQUIRE_WINDOW_FOR_SETTER): New define.
(gdbpy_tui_is_valid): Call is_valid member function.
(gdbpy_tui_set_title): Call REQUIRE_WINDOW_FOR_SETTER instead.
* tui/tui-data.h (struct tui_win_info) <is_visible>: Check
tui_active too.
* tui/tui-layout.c (tui_apply_current_layout): Add an assert.
* tui/tui.c (tui_enable): Move setting of tui_active earlier in
the function.
gdb/doc/ChangeLog:
* python.texinfo (TUI Windows In Python): Extend description of
TuiWindow.is_valid.
gdb/testsuite/ChangeLog:
* gdb.python/tui-window-disabled.c: New file.
* gdb.python/tui-window-disabled.exp: New file.
* gdb.python/tui-window-disabled.py: New file.
There's a bug in the python tui API. If the user tries to delete the
window title attribute then this will trigger undefined behaviour in
GDB due to a missing nullptr check.
gdb/ChangeLog:
* python/py-tui.c (gdbpy_tui_set_title): Check that the new value
for the title is not nullptr.
gdb/testsuite/ChangeLog:
* gdb.python/tui-window.exp: Add new tests.
* gdb.python/tui-window.py (TestWindow) <__init__>: Store
TestWindow object into global the_window.
<remote_title>: New method.
(delete_window_title): New function.
While working on another patch I noticed an oddly formatted error
message in the Python code.
When 'set python print-stack message' is in effect then consider this
Python script:
class TestCommand (gdb.Command):
def __init__ (self):
gdb.Command.__init__ (self, "test-cmd", gdb.COMMAND_DATA)
def invoke(self, args, from_tty):
raise RuntimeError ("bad")
TestCommand ()
And this GDB session:
(gdb) source path/to/python/script.py
(gdb) test-cmd
Python Exception <class 'RuntimeError'> bad:
Error occurred in Python: bad
The line 'Python Exception <class 'RuntimeError'> bad:' doesn't look
terrible in this situation, the colon at the end of the first line
makes sense given the second line.
However, there are places in GDB where there is no second line
printed, for example consider this python script:
def stop_listener (e):
raise RuntimeError ("bad")
gdb.events.stop.connect (stop_listener)
Then this GDB session:
(gdb) file helloworld.exe
(gdb) start
Temporary breakpoint 1 at 0x40112a: file hello.c, line 6.
Starting program: helloworld.exe
Temporary breakpoint 1, main () at hello.c:6
6 printf ("Hello World\n");
Python Exception <class 'RuntimeError'> bad:
(gdb) si
0x000000000040112f 6 printf ("Hello World\n");
Python Exception <class 'RuntimeError'> bad:
In this case there is no auxiliary information displayed after the
warning, and the line ending in the colon looks weird to me.
A quick survey of the code seems to indicate that it is not uncommon
for there to be no auxiliary information line printed, its not just
the one case I found above.
I propose that the line that currently looks like this:
Python Exception <class 'RuntimeError'> bad:
Be reformatted like this:
Python Exception <class 'RuntimeError'>: bad
I think this looks fine then in either situation. The first now looks
like this:
(gdb) test-cmd
Python Exception <class 'RuntimeError'>: bad
Error occurred in Python: bad
And the second like this:
(gdb) si
0x000000000040112f 6 printf ("Hello World\n");
Python Exception <class 'RuntimeError'>: bad
There's just two tests that needed updating. Errors are checked for
in many more tests, but most of the time the pattern doesn't care
about the colon.
gdb/ChangeLog:
* python/python.c (gdbpy_print_stack): Reformat an error message.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter.exp: Update expected results.
* gdb.python/python.exp: Update expected results.
The last frame in a corrupt stack stores the frame_id of the next frame,
so these two frames currently compare as equal.
So if you have a backtrace where the oldest frame is corrupt, this happens:
(gdb) py
>f = gdb.selected_frame()
>while f.older():
> f = f.older()
>print(f == f.newer())
>end
True
With this change, that same example returns False.
gdb/ChangeLog:
2021-02-07 Hannes Domani <ssbssa@yahoo.de>
* python/py-frame.c (frapy_richcompare): Compare frame_id_is_next.
I think this makes the names of the methods clearer, especially for the
arch. The type::arch method (which gets the arch owner, or NULL if the
type is not arch owned) is easily confused with the get_type_arch method
(which returns an arch no matter what). The name "arch_owner" will make
it intuitive that the method returns NULL if the type is not arch-owned.
Also, this frees the type::arch name, so we will be able to morph the
get_type_arch function into the type::arch method.
gdb/ChangeLog:
* gdbtypes.h (struct type) <arch>: Rename to...
<arch_owner>: ... this, update all users.
<objfile>: Rename to...
<objfile_owner>: ... this, update all users.
Change-Id: Ie7c28684c7b565adec05a7619c418c69429bd8c0
Change all users to use the type::objfile method instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_OBJFILE): Remove, change all users to use the
type::objfile method instead.
Change-Id: I6b3f580913fb1fb0cf986b176dba8db68e1fabf9
This allows the creation of hardware breakpoints in Python with
gdb.Breakpoint(type=gdb.BP_HARDWARE_BREAKPOINT)
And they are included in the sequence returned by gdb.breakpoints().
gdb/ChangeLog:
2021-01-21 Hannes Domani <ssbssa@yahoo.de>
PR python/19151
* python/py-breakpoint.c (bppy_get_location): Handle
bp_hardware_breakpoint.
(bppy_init): Likewise.
(gdbpy_breakpoint_created): Likewise.
gdb/doc/ChangeLog:
2021-01-21 Hannes Domani <ssbssa@yahoo.de>
PR python/19151
* python.texi (Breakpoints In Python): Document
gdb.BP_HARDWARE_BREAKPOINT.
gdb/testsuite/ChangeLog:
2021-01-21 Hannes Domani <ssbssa@yahoo.de>
PR python/19151
* gdb.python/py-breakpoint.exp: Add tests for hardware breakpoints.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
This commit removes some, but not all, uses of LA_PRINT_STRING. In
this commit I've removed those uses where there is an obvious language
object on which I can instead call the printstr method.
In the remaining 3 uses it is harder to know if the correct thing is
to call printstr on the current language, or on a specific language.
Currently obviously, we always call on the current language (as that's
what LA_PRINT_STRING does), and clearly this behaviour is good enough
right now, but is it "right"? I've left them for now and will give
them more thought in the future.
gdb/ChangeLog:
* expprint.c (print_subexp_standard): Replace uses of
LA_PRINT_STRING.
* f-valprint.c (f_language::value_print_inner): Likewise.
* guile/scm-pretty-print.c (ppscm_print_string_repr): Likewise.
* p-valprint.c (pascal_language::value_print_inner): Likewise.
* python/py-prettyprint.c (print_string_repr): Likewise.
This makes it possible to disable the address in the result string:
const char *str = "alpha";
(gdb) py print(gdb.parse_and_eval("str").format_string())
0x404000 "alpha"
(gdb) py print(gdb.parse_and_eval("str").format_string(address=False))
"alpha"
gdb/ChangeLog:
2020-12-18 Hannes Domani <ssbssa@yahoo.de>
* python/py-value.c (valpy_format_string): Implement address keyword.
gdb/doc/ChangeLog:
2020-12-18 Hannes Domani <ssbssa@yahoo.de>
* python.texi (Values From Inferior): Document the address keyword.
gdb/testsuite/ChangeLog:
2020-12-18 Hannes Domani <ssbssa@yahoo.de>
* gdb.python/py-format-string.exp: Add tests for address keyword.
Considering this example:
struct C
{
int func() { return 1; }
} c;
int main()
{
return c.func();
}
Accessing the fields of C::func, when requesting the function by its
type, works:
(gdb) py print(gdb.parse_and_eval('C::func').type.fields()[0].type)
C * const
But when trying to do the same via a class instance, it fails:
(gdb) py print(gdb.parse_and_eval('c')['func'].type.fields()[0].type)
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Type is not a structure, union, enum, or function type.
Error while executing Python code.
The difference is that in the former the function type is TYPE_CODE_FUNC:
(gdb) py print(gdb.parse_and_eval('C::func').type.code == gdb.TYPE_CODE_FUNC)
True
And in the latter the function type is TYPE_CODE_METHOD:
(gdb) py print(gdb.parse_and_eval('c')['func'].type.code == gdb.TYPE_CODE_METHOD)
True
So this adds the functionality for TYPE_CODE_METHOD as well.
gdb/ChangeLog:
2020-12-18 Hannes Domani <ssbssa@yahoo.de>
* python/py-type.c (typy_get_composite): Add TYPE_CODE_METHOD.
gdb/testsuite/ChangeLog:
2020-12-18 Hannes Domani <ssbssa@yahoo.de>
* gdb.python/py-type.exp: Add tests for TYPE_CODE_METHOD.
This changes varobj_item::value to be a value_ref_ptr, removing some
manual management.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (install_dynamic_child, varobj_clear_saved_item)
(update_dynamic_varobj_children, create_child)
(create_child_with_value): Update.
* varobj-iter.h (struct varobj_item) <value>: Now a
value_ref_ptr.
* python/py-varobj.c (py_varobj_iter::next): Call release_value.
This changes varobj_iter::next to return a unique_ptr. This fits in
with the ongoing theme of trying to express these ownership transfers
via the type system.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (update_dynamic_varobj_children): Update.
* varobj-iter.h (struct varobj_iter) <next>: Change return type.
* python/py-varobj.c (struct py_varobj_iter) <next>: Change return
type.
(py_varobj_iter::next): Likewise.
This changes the varobj iteration code to use a C++ class rather than
a C struct with a separate "ops" structure. The only implementation
is updated to use inheritance. This simplifies the code quite nicely.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (update_dynamic_varobj_children, install_visualizer)
(varobj::~varobj): Update.
* varobj-iter.h (struct varobj_iter): Change to interface class.
(struct varobj_iter_ops): Remove.
(varobj_iter_next, varobj_iter_delete): Remove.
* python/py-varobj.c (struct py_varobj_iter): Derive from
varobj_iter. Add constructor, destructor. Rename members.
(py_varobj_iter::~py_varobj_iter): Rename from
py_varobj_iter_dtor.
(py_varobj_iter::next): Rename from py_varobj_iter_next.
(py_varobj_iter_ops): Remove.
(py_varobj_iter): Rename from py_varobj_iter_ctor.
(py_varobj_iter_new): Remove.
(py_varobj_get_iterator): Update.
I noticed that a few "#if"s could be removed from the Python code.
This patch is the result.
gdb/ChangeLog
2020-11-02 Tom Tromey <tromey@adacore.com>
* python/python.c: Consolidate two HAVE_PYTHON blocks.
(python_GdbModuleDef): Move earlier. Now static.
(do_start_initialization): Consolidate some IS_PY3K blocks.
The previous patch made it possible to define a condition if it's
valid at some locations. If the condition is invalid at all of the
locations, it's rejected. However, there may be cases where the user
knows the condition *will* be valid at a location in the future,
e.g. due to a shared library load.
To make it possible that such condition can be defined, this patch
adds an optional '-force' flag to the 'condition' command, and,
respectively, a '-force-condition' flag to the 'break'command. When
the force flag is passed, the condition is not rejected even when it
is invalid for all the current locations (note that all the locations
would be internally disabled in this case).
For instance:
(gdb) break test.c:5
Breakpoint 1 at 0x1155: file test.c, line 5.
(gdb) cond 1 foo == 42
No symbol "foo" in current context.
Defining the condition was not possible because 'foo' is not
available. The user can override this behavior with the '-force'
flag:
(gdb) cond -force 1 foo == 42
warning: failed to validate condition at location 1.1, disabling:
No symbol "foo" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if foo == 42
1.1 N 0x0000000000001155 in main at test.c:5
Now the condition is accepted, but the location is automatically
disabled. If a future location has a context in which 'foo' is
available, that location would be enabled.
For the 'break' command, -force-condition has the same result:
(gdb) break test.c:5 -force-condition if foo == 42
warning: failed to validate condition at location 0x1169, disabling:
No symbol "foo" in current context.
Breakpoint 1 at 0x1169: file test.c, line 5.
gdb/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (set_breakpoint_condition): Add a new bool parameter.
* breakpoint.c: Update the help text of the 'condition' and 'break'
commands.
(set_breakpoint_condition): Take a new bool parameter
to control whether condition definition should be forced even when
the condition expression is invalid in all of the current locations.
(condition_command): Update the call to 'set_breakpoint_condition'.
(find_condition_and_thread): Take the "-force-condition" flag into
account.
* linespec.c (linespec_keywords): Add "-force-condition" as an
element.
(FORCE_KEYWORD_INDEX): New #define.
(linespec_lexer_lex_keyword): Update to consider "-force-condition"
as a keyword.
* ada-lang.c (create_ada_exception_catchpoint): Ditto.
* guile/scm-breakpoint.c (gdbscm_set_breakpoint_condition_x): Ditto.
* python/py-breakpoint.c (bppy_set_condition): Ditto.
* NEWS: Mention the changes to the 'break' and 'condition' commands.
gdb/testsuite/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.exp: Expand to test forcing
the condition.
* gdb.linespec/cpcompletion.exp: Update to consider the
'-force-condition' keyword.
* gdb.linespec/explicit.exp: Ditto.
* lib/completion-support.exp: Ditto.
gdb/doc/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (Set Breaks): Document the '-force-condition' flag
of the 'break'command.
* gdb.texinfo (Conditions): Document the '-force' flag of the
'condition' command.
This changes tui_py_window to create an inner curses window. This
greatly simplifies tui_py_window::output, beacuse it no longer needs
to be careful to avoid overwriting the window's border. This patch
also makes it a bit easier for a later patch to rewrite
tui_copy_source_line.
gdb/ChangeLog
2020-09-27 Tom Tromey <tom@tromey.com>
* python/py-tui.c (class tui_py_window) <refresh_window>: New
method.
<erase>: Update.
<cursor_x, cursor_y>: Remove.
<m_inner_window>: New member.
(tui_py_window::rerender): Create inner window.
(tui_py_window::output): Write to inner window.
