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
I noticed two errors in the Type.fields documentation:
1. It is possible to call `fields` on an array type, in which case it
returns one field representing the array's range. It is not
mentioned.
2. When calling `fields` on a type that doesn't have fields (by nature,
like an int), GDB raises a TypeError. It does not return an empty
sequence, as currently documented.
Fix these, and change the text into a bullet list. I find it easier to
read than one big paragraph.
The first issue is already tested in gdb.python/py-type.exp, but the
second one doesn't seem tested. Add a test in gdb.python/py-type.exp
for it.
gdb/doc/ChangeLog:
* python.texi (Types In Python): Re-organize Type.fields doc.
Mention handling of array types. Correct doc for when calling
the method on another type.
gdb/testsuite/ChangeLog:
* gdb.python/py-type.exp (test_fields): Test calling fields on
an int type.
Change-Id: I11c688177504cb070b81a4446ac91dec50b56a22
The `Type.range ()` tests in gdb.python/flexible-array-member.exp pass
when the test is compiled with gcc 9 or later, but not with gcc 8 or
earlier:
$ make check TESTS="gdb.python/flexible-array-member.exp" RUNTESTFLAGS="CC_FOR_TARGET='gcc-8'"
python print(zs['items'].type.range())^M
(0, 0)^M
(gdb) FAIL: gdb.python/flexible-array-member.exp: python print(zs['items'].type.range())
python print(zso['items'].type.range())^M
(0, 0)^M
(gdb) FAIL: gdb.python/flexible-array-member.exp: python print(zso['items'].type.range())
The value that we get for the upper bound of a flexible array member
declared with a "0" size is 0 with gcc <= 8 and is -1 for gcc >= 9.
This is due to different debug info. For this member, gcc 8 does:
0x000000d5: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x00000034 "int")
DW_AT_sibling [DW_FORM_ref4] (0x000000e4)
0x000000de: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x0000002d "long unsigned int")
For the same type, gcc 9 does:
0x000000d5: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x00000034 "int")
DW_AT_sibling [DW_FORM_ref4] (0x000000e5)
0x000000de: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x0000002d "long unsigned int")
DW_AT_count [DW_FORM_data1] (0x00)
Ideally, GDB would present a consistent and documented value for an
array member declared with size 0, regardless of how the debug info
looks like. But for now, just change the test to accept the two
values, to get rid of the failure and make the test in sync
I also realized (by looking at the py-type.exp test) that calling the
fields method on an array type yields one field representing the "index"
of the array. The type of that field is of type range
(gdb.TYPE_CODE_RANGE). When calling `.range()` on that range type, it
yields the same range tuple as when calling `.range()` on the array type
itself. For completeness, add some tests to access the range tuple
through that range type as well.
gdb/testsuite/ChangeLog:
* gdb.python/flexible-array-member.exp: Adjust expected range
value for member declared with 0 size. Test accessing range
tuple through range type.
Change-Id: Ie4e06d99fe9315527f04577888f48284d649ca4c
The test gdb.python/py-startup-opt.exp checks the behaviour of GDB's:
set python dont-write-bytecode on
This flag (when on) stops Python creating .pyc files. The test first
checks that .pyc files will be created, then turns this option on and
checks .pyc files will not be created.
However, if the user has PYTHONDONTWRITEBYTECODE set in their
environment then this will prevent Python from creating .pyc files, as
such the first test, that .pyc files are being created, currently
fails.
We could unset PYTHONDONTWRITEBYTECODE, however, until Python 3.8
there is no way to control where Python writes the .pyc files. As the
GDB developer clearly doesn't want .pyc files created in their
file-system it feels wrong to silently unset this environment
variable.
My proposal then, is that we just spot when this environment variable
is set and adjust the expected results. My hope is that across all
GDB developers some will be running with PYTHONDONTWRITEBYTECODE
unset, so this feature will be fully tested at least some of the time.
gdb/testsuite/ChangeLog:
PR testsuite/27788
* gdb.python/py-startup-opt.exp (test_python_settings): Change the
expected results when environment variable PYTHONDONTWRITEBYTECODE
is set.
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.
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
We don't want to execute this test if Python support is not compiled in
GDB, add the necessary check.
gdb/testsuite/ChangeLog:
* gdb.python/flexible-array-member.exp: Add check for Python
support.
Change-Id: I853b937d2a193a0bb216566bef1a35354264b1c5
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
Give a test a proper name in order to avoid including a path in the
test name.
gdb/testsuite/ChangeLog:
* gdb.python/py-parameter.exp: Give a test a proper name to avoid
including a path in the test name.
It was reported on IRC that using gdb.parameter('data-directory')
doesn't work correctly.
The problem is that the data directory is stored in 'gdb_datadir',
however the set/show command is associated with a temporary
'staged_gdb_datadir'.
When the user does 'set data-directory VALUE', the VALUE is stored in
'staged_gdb_datadir' by GDB, then set_gdb_datadir is called. This in
turn calls set_gdb_data_directory to copy the value from
staged_gdb_datadir into gdb_datadir.
However, set_gdb_data_directory will resolve relative paths, so the
value stored in gdb_datadir might not match the value in
staged_gdb_datadir.
The Python gdb.parameter API fetches the parameter values by accessing
the variable associated with the show command, so in this case
staged_gdb_datadir. This causes two problems:
1. Initially staged_gdb_datadir is NULL, and remains as such until the
user does 'set data-directory VALUE' (which might never happen), but
gdb_datadir starts with GDB's default data-directory value. So
initially from Python gdb.parameter('data-directory') will return the
empty string, even though at GDB's CLI 'show data-directory' prints a
real path.
2. If the user does 'set data-directory ./some/relative/path', GDB
will resolve the relative path, thus, 'show data-directory' at the CLI
will print an absolute path. However, the value is staged_gdb_datadir
will still be the relative path, and gdb.parameter('data-directory')
from Python will return the relative path.
In this commit I fix both of these issues by:
1. Initialising the value in staged_gdb_datadir based on the initial
value in gdb_datadir, and
2. In set_gdb_datadir, after calling set_gdb_data_directory, I copy
the value in gdb_datadir back into staged_gdb_datadir.
With these two changes in place the value in staged_gdb_datadir should
always match the value in gdb_datadir, and accessing data-directory
from Python should now work correctly.
gdb/ChangeLog:
* top.c (staged_gdb_datadir): Update comment.
(set_gdb_datadir): Copy the value of gdb_datadir back into
staged_datadir.
(init_main): Initialise staged_gdb_datadir.
gdb/testsuite/ChangeLog:
* gdb.python/py-parameter.exp: Add test for reading data-directory
using gdb.parameter API.
This commit adds a couple of tests to the python pretty printer
testing.
I've added a test for the 'array' display hint. This display hint is
tested by gdb.python/py-mi.exp, however, the MI testing is done via
the varobj interface, and this code makes its own direct calls to the
Python pretty printers from gdb/varobj.c. What this means is that the
interface to the pretty printers in gdb/python/py-prettyprint.c is not
tested for the 'array' display hint path.
I also added a test for what happens when the display_hint method
raises an exception. There wasn't a bug that inspired this test, just
while adding the previous test I thought, I wonder what happens if...
The current behaviour of GDB seems reasonable, GDB displays the Python
exception, and then continues printing the value as if display_hint
had returned None. I added a test to lock in this behaviour.
gdb/testsuite/ChangeLog:
* gdb.python/py-prettyprint.c (struct container): Add 'is_array_p'
member.
(make_container): Initialise is_array_p.
* gdb.python/py-prettyprint.exp: Add new tests.
* gdb.python/py-prettyprint.py (ContainerPrinter.display_hint):
Check is_array_p and possibly return 'array'.
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.
This commit resolves the remaining duplicate test names in the
gdb.python/ directory, there's 1 duplicate per test script. In each
case I have just extended some test names to make them more
descriptive.
gdb/testsuite/ChangeLog:
* gdb.python/py-bad-printers.exp: Extend test names to make them
unique.
* gdb.python/py-events.exp: Likewise.
* gdb.python/py-finish-breakpoint2.exp: Likewise.
* gdb.python/py-frame-inline.exp: Likewise.
* gdb.python/py-frame.exp: Likewise.
* gdb.python/py-infthread.exp: Likewise.
While squashing duplicate test names I spotted an actual duplicate
test, I suspect a copy & paste error in an earlier patch. I can see
no reason why we should need to duplicate this test, so I'm removing
one copy of it.
gdb/testsuite/ChangeLog:
* gdb.python/py-value-cc.exp: Remove a duplicate test.
While squashing duplicate test names I spotted what looked like a copy
& paste error. During this test a Python variable is created, and
then we call the type method on that variable. In one case we create
a variable and then call the type method on a variable created for a
previous test. I can see no reason why this should be what we want,
it doesn't line up with the comments in the test script, so I've
updated the test. Note, the expected result doesn't change, just the
command issued (the test relates to stripping typedefs).
gdb/testsuite/ChangeLog:
* gdb.python/lib-types.exp: Update the test to check the correct
python variable.
Add additional text to some test names to make them unique. In one
case, correct the test name (copy & paste error) to make it correctly
reflect what the test is doing.
gdb/testsuite/ChangeLog:
* gdb.python/py-explore-cc.exp: Extend test names to make them
unique.
I spotted a duplicate test name in this test script. Turns out it's
an actual duplicate test. Delete one copy of this test.
gdb/testsuite/ChangeLog:
* gdb.python/py-lookup-type.exp: Remove duplicate test.
Extend the test names with additional text to make them unique.
gdb/testsuite/ChangeLog:
* gdb.python/py-pp-maint.exp: Extend test names to make them
unique.
Add a with_test_prefix to make test names unique.
gdb/testsuite/ChangeLog:
* gdb.python/py-explore.exp: Add with_test_prefix to make test
names unique.
Make test names unique by just adding additional text to the test
names. As this is a Python test that repeatedly imports the Python
script I've just numbered the test names in this case rather than
trying to come up with anything better, hence we have:
import python scripts, 1
import python scripts, 2
...
import python scripts, 6
Not great, but hopefully good enough. Everything else has a slightly
more descriptive test name.
gdb/testsuite/ChangeLog:
* gdb.python/py-finish-breakpoint.exp: Make test names unique.
Wrap some code in `with_test_prefix` to make test names unique.
gdb/testsuite/ChangeLog:
* gdb.python/py-strfns.exp: Use with_test_prefix to make test
names unique.
Make use of `proc_with_prefix` for every test_* proc in order to make
the test names unique within this test file.
gdb/testsuite/ChangeLog:
* gdb.python/py-format-string.exp: Use proc_with_prefix to make
test names unique.
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.
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.
When running test-case gdb.python/py-format-string.exp with target board
unix/-m32, we run into:
...
(gdb) python print \
(gdb.parse_and_eval ('a_base_ref').format_string (deref_refs=True))^M
@0xffffc468: {_vptr.Base = 0x80487e0 <vtable for Deriv+8>, a = 42, \
static a_static_member = 2019}^M
(gdb) FAIL: gdb.python/py-format-string.exp: format_string: \
lang_cpp: a_base_ref with option deref_refs: deref_refs=true
...
while with -m64, we have instead:
...
@0x7fffffffd170: {_vptr.Base = 0x400910 <vtable for Deriv+16>, a = 42, \
static a_static_member = 2019}^M
(gdb) PASS: gdb.python/py-format-string.exp: format_string: \
lang_cpp: a_base_ref with option deref_refs: deref_refs=true
...
The vtable contains pointer entries which are 4-byte for -m32 and 8-byte for
-m64, so it's not surprising the offsets (Deriv+8 vs. Deriv+16) differ.
Fix this by allow Deriv+$decimal.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-20 Tom de Vries <tdevries@suse.de>
* gdb.python/py-format-string.exp: Allow Deriv+$decimal as vtable
offset.
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.
Use with_test_prefix to de-duplicate test names.
gdb/testsuite/ChangeLog:
* gdb.python/py-frame-args.exp: De-duplicate test names.
Change-Id: I5cc8bee692a0d071cb78258aca80ea642e00e7a8
gdb/testsuite/ChangeLog:
2020-12-14 Markus Metzger <markus.t.metzger@intel.com>
* gdb.python/py-record-btrace.exp: Make test names unique.
* gdb.python/py-record-full.exp: Likewise.
When trying to use one of the record commands without having enabled
recording first, GDB gives the error message:
(gdb) record function-call-history
No record target is currently active.
Use one of the "target record-<TAB><TAB>" commands first.
In the record help, however, we say:
(gdb) help record
record, rec
Start recording.
List of record subcommands:
record btrace, record b -- Start branch trace recording.
record delete, record del, record d -- Delete the rest of execution log and start recording it anew.
record full -- Start full execution recording.
record function-call-history -- Prints the execution history at function granularity.
record goto -- Restore the program to its state at instruction number N.
record instruction-history -- Print disassembled instructions stored in the execution log.
record save -- Save the execution log to a file.
record stop, record s -- Stop the record/replay target.
Change the above error message to
(gdb) record function-call-history
No recording is currently active.
Use the "record full" or "record btrace" command first.
to align with the help text.
gdb/ChangeLog:
2020-12-03 Markus Metzger <markus.t.metzger@intel.com>
* record.c (require_record_target): Rephrase error message.
(info_record_command): Likewise.
gdb/testsuite/ChangeLog:
2020-12-03 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/enable.exp: Update error message.
* gdb.btrace/multi-inferior.exp: Likewise.
* gdb.btrace/reconnect.exp: Likewise.
* gdb.python/py-record-btrace.exp: Likewise.
* gdb.python/py-record-full.exp: Likewise.
Comparing types of enum fields results in a crash, because they don't
have a type.
It can be reproduced by comparing the types of 2 instances of the same
enum type in different objects:
enum.h:
enum e
{
zero,
one,
};
enum-1.c:
#include <enum.h>
int func();
enum e e1;
int main()
{
return e1 + func();
}
enum-2.c:
#include <enum.h>
enum e e2;
int func()
{
return e2;
}
$ gcc -g -oenum enum-1.c enum-2.c
$ gdb -q enum.exe
Reading symbols from enum.exe...
(gdb) py print(gdb.parse_and_eval("e1").type==gdb.parse_and_eval("e2").type)
Thread 1 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6184.0x1cc4]
check_typedef (type=0x0) at C:/src/repos/binutils-gdb.git/gdb/gdbtypes.c:2745
2745 while (type->code () == TYPE_CODE_TYPEDEF)
gdb/ChangeLog:
2020-12-19 Hannes Domani <ssbssa@yahoo.de>
PR exp/27070
* gdbtypes.c (check_types_equal): Don't compare types of enum fields.
gdb/testsuite/ChangeLog:
2020-12-19 Hannes Domani <ssbssa@yahoo.de>
PR exp/27070
* gdb.python/compare-enum-type-a.c: New test.
* gdb.python/compare-enum-type-b.c: New test.
* gdb.python/compare-enum-type.exp: New file.
* gdb.python/compare-enum-type.h: New test.
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.
We currently have two flushing commands 'flushregs' and 'maint
flush-symbol-cache'. I'm planning to add at least one more so I
thought it might be nice if we bundled these together into one place.
And so I created the 'maint flush ' command prefix. Currently there
are two commands:
(gdb) maint flush symbol-cache
(gdb) maint flush register-cache
Unfortunately, even though both of the existing flush commands are
maintenance commands, I don't know how keen we about deleting existing
commands for fear of breaking things in the wild. So, both of the
existing flush commands 'maint flush-symbol-cache' and 'flushregs' are
still around as deprecated aliases to the new commands.
I've updated the testsuite to use the new command syntax, and updated
the documentation too.
gdb/ChangeLog:
* NEWS: Mention new commands, and that the old commands are now
deprecated.
* cli/cli-cmds.c (maintenanceflushlist): Define.
* cli/cli-cmds.h (maintenanceflushlist): Declare.
* maint.c (_initialize_maint_cmds): Initialise
maintenanceflushlist.
* regcache.c: Add 'cli/cli-cmds.h' include.
(reg_flush_command): Add header comment.
(_initialize_regcache): Create new 'maint flush register-cache'
command, make 'flushregs' an alias.
* symtab.c: Add 'cli/cli-cmds.h' include.
(_initialize_symtab): Create new 'maint flush symbol-cache'
command, make old command an alias.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document 'maint flush symbol-cache'.
(Maintenance Commands): Document 'maint flush register-cache'.
gdb/testsuite/ChangeLog:
* gdb.base/c-linkage-name.exp: Update to use new 'maint flush ...'
commands.
* gdb.base/killed-outside.exp: Likewise.
* gdb.opt/inline-bt.exp: Likewise.
* gdb.perf/gmonster-null-lookup.py: Likewise.
* gdb.perf/gmonster-print-cerr.py: Likewise.
* gdb.perf/gmonster-ptype-string.py: Likewise.
* gdb.python/py-unwind.exp: Likewise.
When running test-case gdb.python/py-symbol.exp with target board readnow, we
get:
...
FAIL: gdb.python/py-symbol.exp: print line number of rr
FAIL: gdb.python/py-symbol.exp: print value of rr
...
These are FAILs due to PR25857.
Mark these FAILs as KFAILs.
gdb/testsuite/ChangeLog:
2020-10-28 Tom de Vries <tdevries@suse.de>
* gdb.python/py-symbol.exp: Add KFAILs for -readnow.
GDB includes the virtual table pointer when formatting polymorphic
C++ objects for printing, but GCC and Clang name these differently:
GCC emits a DW_AT_name of "_vptr.Base" when describing the virtual
table pointer of a type derived from type "Base", whereas Clang
will emit "_vptr$Base" in this situation. This commit fixes a
testcase which failed because of this.
gdb/testsuite/ChangeLog:
* gdb.python/py-format-string.exp (test_deref_refs): Treat
"_vptr$Base" as correct, in addition to "_vptr.Base".
(test_mixed): Likewise.
Since we now have mi_runto_main which is like runto_main, eliminate
mi_run_to_main, in favor of a new MI clean_restart counterpart --
mi_clean_restart -- and mi_runto_main.
This makes MI testcases look a bit more like CLI testcases.
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_clean_restart): New.
(mi_run_to_main): Delete.
All callers adjust to use mi_clean_restart / mi_runto_main.
Change-Id: I34920bab4fea1f23fb752928c2969c1f6ad714b6
Similar to the previous patch, but this time add "-q" to tests that do
"break main", "list main", etc. explicitly.
gdb/testsuite/ChangeLog:
* config/monitor.exp: Use "list -q".
* gdb.arch/gdb1558.exp: Use "break -q".
* gdb.arch/i386-permbkpt.exp: Use "break -q".
* gdb.arch/i386-prologue-skip-cf-protection.exp: Use "break -q".
* gdb.base/break.exp: Use "break -q", "list -q" and "tbreak -q".
* gdb.base/commands.exp: Use "break -q".
* gdb.base/condbreak.exp: Use "break -q".
* gdb.base/ctf-ptype.exp: Use "list -q".
* gdb.base/define.exp: Use "break -q".
* gdb.base/del.exp: Use "break -q".
* gdb.base/fullname.exp: Use "break -q".
* gdb.base/hbreak-in-shr-unsupported.exp: Use "hbreak -q".
* gdb.base/hbreak-unmapped.exp: Use "hbreak -q".
* gdb.base/hbreak2.exp: Use "hbreak -q" and "list -q".
* gdb.base/hw-sw-break-same-address.exp: Use "break -q" and
"hbreak -q".
* gdb.base/included.exp: Use "list -q".
* gdb.base/label.exp: Use "break -q".
* gdb.base/lineinc.exp: Use "break -q".
* gdb.base/list.exp: Use "list -q".
* gdb.base/macscp.exp: Use "list -q".
* gdb.base/pending.exp: Use "break -q".
* gdb.base/prologue-include.exp: Use "break -q".
* gdb.base/ptype.exp: Use "list -q".
* gdb.base/sepdebug.exp: Use "break -q", "list -q" and "tbreak -q".
* gdb.base/server-del-break.exp: Use "break -q".
* gdb.base/style.exp: Use "break -q".
* gdb.base/symbol-without-target_section.exp: Use "list -q".
* gdb.base/watchpoint-reuse-slot.exp: Use "hbreak -q".
* gdb.cp/exception.exp: Use "tbreak -q".
* gdb.dwarf2/dw2-error.exp: Use "break -q".
* gdb.dwarf2/fission-mix.exp: Use "break -q".
* gdb.dwarf2/fission-reread.exp: Use "break -q".
* gdb.dwarf2/pr13961.exp: Use "break -q".
* gdb.linespec/explicit.exp: Use "list -q".
* gdb.linespec/linespec.exp: Use "break -q".
* gdb.mi/mi-simplerun.exp: Use "--qualified".
* gdb.python/py-mi-objfile-gdb.py: Use "list -q".
* gdb.server/bkpt-other-inferior.exp: Use "break -q".
* gdb.server/connect-without-multi-process.exp: Use "break -q".
* gdb.trace/change-loc.exp: Use "break -q".
* gdb.trace/pending.exp: Use "break -q".
* gdb.tui/basic.exp: Use "list -q".
* gdb.tui/list-before.exp: Use "list -q".
* gdb.tui/list.exp: Use "list -q".
* lib/gdb.exp (gdb_has_argv0): Use "break -q".
Change-Id: Iab9408e90ed71cbb111cd737d2d81b5ba8adb108
This adds an mi_runto_main routine, very much like the runto_main CLI
counterpart.
Note there's already a mi_run_to_main (extra underscore in "run_to"),
but unlike its intro comment says, that does more than the CLI's
runto_main -- it also starts GDB. I would like to eliminate that
other one by introducing a mi_clean_restart function instead. That is
done later in the series.
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_runto_main): New proc.
(mi_run_to_main): Use it.
* gdb.mi/mi-catch-cpp-exceptions.exp: Likewise.
* gdb.mi/mi-var-cmd.exp: Likewise.
* gdb.mi/mi-var-invalidate.exp: Likewise.
* mi-var-list-children-invalid-grandchild.exp: Likewise.
* gdb.mi/mi2-amd64-entry-value.exp: Likewise.
* gdb.mi/new-ui-mi-sync.exp: Likewise.
* gdb.mi/user-selected-context-sync.exp: Likewise.
* gdb.opt/inline-cmds.exp: Likewise.
* gdb.python/py-framefilter-mi.exp: Likewise.
* gdb.python/py-mi.exp: Likewise.
Change-Id: I2e49ca7b0b61cea57c1202e5dfa32417e6a4403d
A number of testcases define variables and/or functions which are
referenced by GDB during the test, but which are not referenced from
within the test executable. Clang correctly recognizes that these
variables and functions are unused, and optimizes them out, causing
the testcases in question to fail. This commit adds __attribute__
((used)) in various places to prevent this.
gdb/testsuite/ChangeLog:
* gdb.base/msym-bp.c (foo): Add __attribute__ ((used)).
* gdb.base/msym-bp-2.c (foo): Likewise.
* gdb.base/msym-lang.c (foo): Likewise.
* gdb.base/msym-lang-main.c (foo): Likewise.
* gdb.base/symtab-search-order-1.c (static_global): Likewise.
* gdb.guile/scm-pretty-print.c (eval_func): Likewise.
* gdb.mi/mi-sym-info-1.c (global_f1): Likewise.
* gdb.mi/mi-sym-info-2.c (global_f1, var1, var2): Likewise.
* gdb.multi/watchpoint-multi-exit.c (globalvar): Likewise.
* gdb.python/py-as-string.c (enum_valid, enum_invalid): Likewise.
* gdb.python/py-objfile.c (static_var): Likewise.
* gdb.python/py-symbol.c (rr): Likewise.
* gdb.python/py-symbol-2.c (anon, rr): Likewise.
* gdb.mi/mi-sym-info.exp (lineno1, lineno2): Updated.
Prior to commit 56bcdbea2b, the from_tty keyword argument to the
Python function gdb.execute controlled whether the command took input
from the terminal. When from_tty=True, "starti" and similar commands
prompted the user:
(gdb) python gdb.execute("starti", from_tty=True)
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /bin/true
Program stopped.
When from_tty=False, these commands did not prompt the user, and "yes"
was assumed:
(gdb) python gdb.execute("starti", from_tty=False)
Program stopped.
However, after commit 56bcdbea2b, the from_tty keyword argument no
longer had this effect. For example, as of commit 7ade7fba75:
(gdb) python gdb.execute("starti", from_tty=True)
The program being debugged has been started already.
Start it from the beginning? (y or n) [answered Y; input not from terminal]
Starting program: /bin/true
Program stopped.
Note the "[answered Y; input not from terminal]" in the output even
though from_tty=True was requested.
Looking at commit 56bcdbea2b, it seems that the behaviour of the
from_tty argument was changed accidentally. The commit message said:
Let gdb.execute handle multi-line commands
This changes the Python API so that gdb.execute can now handle
multi-line commands, like "commands" or "define".
and there was no mention of changing the effect of the from_tty
argument. It looks as though the code for setting the instream to
nullptr was accidentally moved from execute_user_command() to
execute_control_commands() along with the other scoped restores.
Accordingly, the simplest way to fix this is to partially reverse
commit 56bcdbea2b by moving the code for setting the instream to
nullptr back to execute_user_command() where it was to begin with.
Additionally, add a test case to reduce the risk of similar breakage
in future.
gdb/ChangeLog:
PR python/26586
* cli/cli-script.c (execute_control_commands): don't set
instream to nullptr here as this breaks the from_tty argument
to gdb.execute in Python.
(execute_user_command): set instream to nullptr here instead.
gdb/testsuite/ChangeLog:
PR python/26586
* gdb.python/python.exp: add test cases for the from_tty
argument to gdb.execute.
Make the testcase work when built with a C++ compiler.
gdb/testsuite/ChangeLog:
* gdb.python/py-frame-inline.exp: Adjust to optionally expect a
full prototype.
