When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get:
...
FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1
FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2
...
The problem is that the debug info produced by clang does not contain any
references to enumerators val1 and val2, or the corresponding enumeration
types.
Instead, the variables u1 and u2 are considered to be simply of type int:
...
<1><fb>: Abbrev Number: 2 (DW_TAG_variable)
<fc> DW_AT_name : u1
<fd> DW_AT_type : <0x106>
<101> DW_AT_external : 1
<103> DW_AT_location : (DW_OP_addrx <0>)
<1><106>: Abbrev Number: 3 (DW_TAG_base_type)
<107> DW_AT_name : int
<108> DW_AT_encoding : 5 (signed)
<109> DW_AT_byte_size : 4
<1><10a>: Abbrev Number: 2 (DW_TAG_variable)
<10b> DW_AT_name : u2
<10c> DW_AT_type : <0x106>
<110> DW_AT_external : 1
<112> DW_AT_location : (DW_OP_addrx <0x1>)
...
Fix this by checking whether val1 and val2 are present in the cooked index
before checking whether they have the correct parent.
This cannot be expressed efficiently with gdb_test_lines, so factor out
gdb_get_lines and use that instead.
The test-case still calls "maint print objfiles" twice, but the first time is
for have_index. We should probably use a gdb_caching_proc for this.
Tested on aarch64-linux.
Reported-By: Guinevere Larsen <guinevere@redhat.com>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Tested-By: Guinevere Larsen <guinevere@redhat.com>
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output.
Tested on x86_64-linux.
On aarch64-linux, with make target check-read1, I run into:
...
(gdb) info reg vector^M
...
d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout)
0, u = 0, s = 0}^M
...
The problem is that while (as documented) the corresponding gdb_test_multiple
doesn't work for vector registers, it doesn't skip them either. This causes
the timeout, and it also causes the registers after a vector register not to
be found.
Fix this by using -lbl style matching.
Make which reggroups and registers are found more explicit using verbose -log,
which makes us notice that regnames with underscores are skipped, so fix that
as well.
While we're at it, this:
...
set invalid_register_re "Invalid register .*"
...
and this:
...
-re $invalid_register_re {
fail "$test (unexpected invalid register response)"
}
...
means that the prompt may or may not be consumed. Fix this by limiting the
regexp to one line, and using exp_continue.
While we're at it, improve readability of the complex regexp matching a single
register by factoring out regexps.
Tested on aarch64-linux and x86_64-linux.
This changes a few implementations of "info proc mappings" to use
ui-out tables rather than printf.
Note that NetBSD and FreeBSD also use printfs here, but since I can't
test these, I didn't update them.
Approved-By: Andrew Burgess <aburgess@redhat.com>
When running test-case gdb.base/break-interp.exp with check-read1, I run into:
...
(gdb) info files^M
...
0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout)
pieNO.d/libc.so.6^M
...
The code has two adaptations to deal with the large output:
- nested gdb_test_multiple, and
- an exp_continue in the inner gdb_test_multiple.
The former seems unnecessary, and the latter doesn't trigger often enough
because of an incomplete hex number regexp, causing the timeout.
Get rid of both of these, and use -lbl instead.
Tested on x86_64-linux.
Include the value of configuration flag --enable-targets in the output
of GDB command 'show configuration' and also in the output printed for
'gdb --configuration'. This will make it easier to see how GDB was
built.
No tests added or updated as we can't really check for a specific flag
appearing or not appearing on the configuration output. But we do
print the configuration within lib/gdb.exp to check which features are
built into GDB, so if this change broke configuration printing then
plenty of tests should stop working (they don't).
Approved-By: Tom Tromey <tom@tromey.com>
The commit:
commit 6cce025114
Date: Fri Mar 3 19:03:15 2023 +0000
gdb: only insert thread-specific breakpoints in the relevant inferior
added a couple of calls to breakpoint::clear_locations() inside
update_breakpoint_locations().
The intention of these calls was to avoid leaving redundant locations
around when a thread- or inferior-specific breakpoint was switched
from one thread or inferior to another.
Without the clear_locations() calls the tests gdb.multi/tids.exp and
gdb.multi/pending-bp.exp have some failures. A b/p is changed such
that the program space it is associated with changes. This triggers a
call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be
the new program space. As a result GDB correctly calculates the new
locations and adds these to the breakpoint, but the old locations, in
the old program space, are incorrectly retained. The call to
clear_locations() solves this by deleting the old locations.
However, while working on another patch I realised that the approach
taken here is not correct. The FILTER_PSPACE argument passed to
breakpoint_re_set_one() and then on to update_breakpoint_locations()
might not be the program space to which the breakpoint is associated.
Consider this example:
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) start
Temporary breakpoint 1 at 0x401198: file hello.c, line 18.
Starting program: /tmp/hello.x
Temporary breakpoint 1, main () at hello.c:18
18 printf ("Hello World\n");
(gdb) break main thread 1
Breakpoint 2 at 0x401198: file hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000401198 in main at hello.c:18
stop only in thread 1
(gdb) add-inferior -exec /tmp/hello.x
[New inferior 2]
Added inferior 2 on connection 1 (native)
Reading symbols from /tmp/hello.x...
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <PENDING> main
stop only in thread 1.1
Notice that after creating the second inferior and loading a file the
thread-specific breakpoint was incorrectly made pending. Loading the
exec file in the second inferior triggered a call to
breakpoint_re_set() with the new, second, program space as the
current_program_space.
This program space ends up being passed to
update_breakpoint_locations().
In update_breakpoint_locations this condition is true:
if (all_locations_are_pending (b, filter_pspace) && sals.empty ())
and so we end up discarding all of the locations for this breakpoint,
making the breakpoint pending.
What we really want to do in update_breakpoint_locations() is, for
thread- or inferior- specific breakpoints, delete any locations which
are associated with a program space that this breakpoint is NOT
associated with.
But then I realised the answer was easier than that.
The ONLY time that a b/p can have locations associated with the
"wrong" program space like this is at the moment we change the thread
or inferior the b/p is associated with by calling
breakpoint_set_thread() or breakpoint_set_inferior().
And so, I think the correct solution is to hoist the call to
clear_locations() out of update_breakpoint_locations() and place a
call in each of the breakpoint_set_{thread,inferior} functions.
I've done this, and added a couple of new tests. All of which are
now passing.
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.ada/tagged-lookup.exp with target board readnow and
make target check-read1:
...
$ ( cd build/gdb; \
make check-read1 \
RUNTESTFLAGS="--target_board=readnow gdb.ada/tagged-lookup.exp" )
...
I run into:
...
(gdb) PASS: gdb.ada/tagged-lookup.exp: set debug symtab-create 1
print *the_local_var^M
$1 = (n => 2)^M
(gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded
...
The problem is that the corresponding gdb_test_multiple uses line-by-line
matching (using -lbl) which doesn't work well with the multiline pattern
matching both the prompt and the line before it:
...
-re -wrap ".* = \\\(n => $decimal\\\)" {
...
Fix this by making it a one-line pattern:
...
-re -wrap "" {
...
While we're at it, replace an if-then-pass-else-fail with a gdb_assert.
Tested on aarch64-linux.
When running test-case gdb.dwarf2/enum-type-c++.exp with target board
cc-with-debug-types, we run into:
...
(gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
...
because val1 has no parent:
...
[31] ((cooked_index_entry *) 0x7efedc002e90)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xef
parent: ((cooked_index_entry *) 0)
...
[37] ((cooked_index_entry *) 0x38ffd280)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xef
parent: ((cooked_index_entry *) 0)
...
There are two entries, which seems to be an inefficiency, but for now let's
focus on the correctness issue.
The debug info for val1 looks like this:
...
<1><cb>: Abbrev Number: 2 (DW_TAG_namespace)
<cc> DW_AT_name : ns
<cf> DW_AT_declaration : 1
<2><d3>: Abbrev Number: 12 (DW_TAG_class_type)
<d4> DW_AT_name : A
<d6> DW_AT_declaration : 1
<3><d6>: Abbrev Number: 13 (DW_TAG_enumeration_type)
<db> DW_AT_declaration : 1
<1><dd>: Abbrev Number: 14 (DW_TAG_enumeration_type)
<e7> DW_AT_specification: <0xd6>
<2><ef>: Abbrev Number: 5 (DW_TAG_enumerator)
<f0> DW_AT_name : val1
<f4> DW_AT_const_value : 1
...
Fix this by:
- adding a cooked index entry for DIE 0xcb (and consequently for child DIE
0xd3), by marking it interesting,
- making sure that the entry for DIE 0xcb has a name, and
- using the entry for DIE 0xd3 as parent entry for DIE 0xdd.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of
DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in
test-case gdb.dwarf2/enum-type.exp, for val1 we get an entry without parent:
...
[27] ((cooked_index_entry *) 0x7fbbb4002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x124
parent: ((cooked_index_entry *) 0)
...
This happens here in cooked_indexer::index_dies:
...
info_ptr = recurse (reader, info_ptr,
is_enum_class ? this_entry : parent_entry,
fully);
...
when we're passing down a nullptr parent_entry, while the parent of this_entry
is deferred.
Fix this in cooked_indexer::index_dies by passing down a deffered parent
instead, such that we get:
...
[27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M
name: val1^M
canonical: val1^M
qualified: ns::val1^M
DWARF tag: DW_TAG_enumerator^M
flags: 0x0 []^M
DIE offset: 0x124^M
parent: ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Add two more separators in spellcheck.sh: colon and comma.
Doing so triggers the "inbetween->between" rule, which gives an incorrect
result. Override this with "inbetween->between, in between, in-between" [1],
in a new file gdb/contrib/common-misspellings.txt.
Fix the following common misspellings:
...
everytime -> every time
sucess -> success
thru -> through
transfered -> transferred
inbetween -> between, in between, in-between
...
Verified with spellcheck.sh. Tested on x86_64-linux.
[1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/
While trying to add more separators here:
...
# Separators: space, slash, tab.
grep_separator=" |/| "
sed_separator=" \|/\|\t"
...
I mistakingly used "|" instead of "\|" in sed_separator.
Factor out new variables grep_or and sed_or, and construct the grep_separator
and sed_separator variables by joining the elements of a list using grep_or
and sed_or.
Verified with shellcheck, and tested by rerunning on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
With a gdb build with -fsanitize=thread, and test-case
gdb.python/py-inferior.exp I run into:
...
(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)^M
ERROR: ThreadSanitizer: requested allocation size 0xffffffffffffffff exceeds \
maximum supported size of 0x10000000000^M
...
There's already a workaround for this using ASAN_OPTIONS, and apparently the
same is needed for TSAN_OPTIONS.
Add the allocator_may_return_null=1 workaround also in TSAN_OPTIONS.
Likewise in gdb.dap/memory.exp.
Tested on x86_64-linux.
This patch introduces ADR to the Modula-2 language interface.
It return the address of the parameter supplied.
The patch also contains a dejagnu test for ADR.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I came across a table containing common misspellings [1], and wrote a script to
detect and correct these misspellings.
The table also contains entries that have alternatives, like this:
...
addres->address, adders
...
and for those the script prints a TODO instead.
The script downloads the webpage containing the table, extracts the table and
caches it in .git/wikipedia-common-misspellings.txt to prevent downloading it
over and over again.
Example usage:
...
$ gdb/contrib/spellcheck.sh gdb*
...
ChangeLog files are silently skipped.
Checked with shellcheck.
Tested on x86_64-linux, by running it on the gdb* dirs on doing a build and
test run.
The results of running it are in the two following patches.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines
After commit 68bbe11833, ELF symbols read via bfd_canonicalize_symtab
and similar functions which have bad st_name fields will have NULL in
the name rather than "(null)". gdb.base/bfd-errors.exp deliberately
creates a faulty shared library with st_name pointing outside of
.dynsym for some symbols, and thus now results in NULL symbol names.
This triggers a segv on string_buffer.assign(name). Fix that.
when I disable a breakpoint in VS Code the breakpoint is removed
instead. I compared the behavior to lldb-dap and disabled events when
removing a breakpoint. Now it is possible to disable and enable
breakpoints in VS Code.
While looking at the recent line number styling commit I noticed a few
places where we could add more file name styling. So lets do that.
Approved-By: Tom Tromey <tom@tromey.com>
There's currently code in gdb that checks if an expression evaluates
to a type. In some spots this is done by comparing the opcode against
OP_TYPE, but other spots more correctly also compare with OP_TYPEOF
and OP_DECLTYPE.
This patch cleans up this area, replacing opcode-checking with a new
method on 'operation'.
Generally, checking the opcode should be considered deprecated,
although it's unfortunately difficult to get rid of opcodes entirely.
I also took advantage of this change to turn eval_op_type into a
method, removing a bit of indirection.
Reviewed-by: Keith Seitz <keiths@redhat.com>
This patch adds separate styling for line numbers. That is, whenever
gdb prints a source line number, it uses this style.
v2 includes a change to ensure that %ps works in query.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Keith Seitz <keiths@redhat.com>
I noticed that filename completion in the middle of a line doesn't
work as I would expect it too. For example, assuming '/tmp/filename'
exists, and is the only file in '/tmp/' then when I do the following:
(gdb) file "/tmp/filen<TAB>
GDB completes to:
(gdb) file "/tmp/filename"
But, if I type this:
(gdb) file "/tmp/filen "xxx"
Then move the cursor to the end of '/tmp/filen' and press <TAB>, GDB
will complete the line to:
(gdb) file "/tmp/filename "xxx"
But GDB will not insert the trailing double quote character.
The reason for this is found in readline/readline/complete.c in the
function append_to_match. This is the function that appends the
trailing closing quote character, however, the closing quote is only
inserted if the cursor (rl_point) is at the end (rl_end) of the line
being completed.
In this patch, what I do instead is add the closing quote in the
function gdb_completer_file_name_quote, which is called from readline
through the rl_filename_quoting_function hook. The docs for
rl_filename_quoting_function say (see 'info readline'):
"... The MATCH_TYPE is either 'SINGLE_MATCH', if there is only one
completion match, or 'MULT_MATCH'. Some functions use this to
decide whether or not to insert a closing quote character. ..."
This is exactly what I'm doing in this patch, and clearly this is not
an unusual choice. Now after completing a filename that is not at the
end of the line GDB will add the closing quote character if
appropriate.
I have managed to write some tests for this. I send a line of text to
GDB which includes a partial filename followed by a trailing string, I
then send the escape sequence to move the cursor left, and finally I
send the tab character.
Obviously, expect doesn't actually see the complete output with the
extra text "in place", instead expect sees the original line followed
by some escape sequences to reflect the cursor movement, then an
escape sequence to indicate that text is being inserted in the middle
of a line, followed by the new characters ... it's a bit messy, but I
think it holds together.
Reviewed-By: Tom Tromey <tom@tromey.com>
After the recent filename completion changes I noticed that the
following didn't work as expected:
(gdb) file "/path/to/some/file" /path/to/so<TAB>
Now, I know that the 'file' command doesn't actually take multiple
filenames, but currently (and this was true before the recent filename
completion changes too) the completion function doesn't know that the
command only expects a single filename, and should complete any number
of filenames. And indeed, this works:
(gdb) file "/path/to/some/file" "/path/to/so<TAB>
In this case I quoted the second path, and now GDB is happy to offer
completions.
It turns out that the problem in the first case is an off-by-one bug
in gdb_completer_file_name_char_is_quoted. This function tells GDB if
a character within the line being completed is escaped or not. An
escaped character cannot be a word separator.
The algorithm in gdb_completer_file_name_char_is_quoted is to scan
forward through the line keeping track of whether we are inside double
or single quotes, or if a character follows a backslash. When we find
an opening quote we skip forward to the closing quote and then check
to see if we skipped over the character we are looking for, if we did
then the character is within the quoted string.
The problem is that this "is character inside quoted string" check
used '>=' instead if '>'. As a consequence a character immediately
after a quoted string would be thought of as inside the quoted string.
In our first example this means that the single white space character
after the quoted string was thought to be quoted, and was not
considered a word breaking character. As such, GDB would not try to
complete the second path. And indeed, if we tried this:
(gdb) file "/path/to/some/file" /path/to/so<TAB>
That is, place multiple spaces after the first path, then GDB would
consider the first space as quoted, but the second space is NOT
quoted, and would be a word break. Now GDB does complete the second
path.
By changing '>=' to '>' in gdb_completer_file_name_char_is_quoted this
bug is resolved, now the original example works and GDB will correctly
complete the second path.
For testing I've factored out the core of one testing proc, and I now
run those tests multiple times, once with no initial path, once with
an initial path in double quotes, once with an initial path in
single quotes, and finally, with an unquoted initial path.
Reviewed-By: Tom Tromey <tom@tromey.com>
Some of the gdb and testsuite files double include some headers. While
all headers use include guards, it helps a bit keeping the code base
tidy.
No functional change.
Approved-by: Kevin Buettner <kevinb@redhat.com>
[ This is based on "[gdb/symtab] Add parent_map::dump" [1]. ]
When building the cooked index, gdb builds up a parent map.
This map is currently only visible at user level through the effect of using
it, but it's useful to be able to inspect it as well.
Add dumping of this parent map for "set debug dwarf-read 2".
As example, take test-case gdb.dwarf2/enum-type-c++.exp with target board
debug-types.
The parent map looks like:
...
$ gdb -q -batch \
-iex "maint set worker-threads 0" \
-iex "set debug dwarf-read 2" \
outputs/gdb.dwarf2/enum-type-c++/enum-type-c++
...
[dwarf-read] print_stats: Final m_all_parents_map:
map start:
0x0000000000000000 0x0
0x0000000000000037 0x20f27d30 (0x36: ec)
0x0000000000000051 0x0
0x000000000000008b 0x20f27dc0 (0x8a: A)
0x00000000000000a6 0x0
...
There's no parent entry at address 0xd6, which is part of what causes this:
...
(gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
...
With the series containing the proposed fix applied [2], we get instead:
...
[dwarf-read] print_stats: Final m_all_parents_map:
map start:
0x0000000000000000 0x0
0x0000000000000026 0x7e0bdc0 (0x25: ns)
0x0000000000000036 0x0
0x0000000000000037 0x7e0bdf0 (0x36: ns::ec)
0x0000000000000051 0x0
0x000000000000007f 0x7e0be80 (0x7e: ns)
0x000000000000008a 0x0
0x000000000000008b 0x7e0beb0 (0x8a: ns::A)
0x00000000000000a6 0x0
0x00000000000000cc 0x7e0bf10 (0xcb: ns)
0x00000000000000d4 0x7e0bf40 (0xd3: ns::A)
0x00000000000000dc 0x7e0bf10 (0xcb: ns)
0x00000000000000dd 0x7e0bf40 (0xd3: ns::A)
0x00000000000000f6 0x0
...
and find at 0xd6 parent ns::A.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2023-October/202883.html
[2] https://sourceware.org/pipermail/gdb-patches/2024-September/211958.html
Make the current program space references bubble up.
In collect_symtabs_from_filename, remove the calls to
set_current_program_space and just pass the relevant pspaces.
This appears safe to do, because nothing in the `collector` callback
cares about the current pspace.
Change-Id: I00a7ed484bfbe5264f01a6abf0d33b51de373cbb
Reviewed-by: Keith Seitz <keiths@redhat.com>
For a long time Fedora GDB has carried an out of tree patch which
checks for memory leaks in gdb.Inferior.read_memory(). At one point
in the distant past GDB did have a memory leak in this code, but this
was first fixed in commit:
commit 655e820cf9a039ee55325d9e1f8423796d592b4b
Date: Wed Mar 28 17:38:07 2012 +0000
* python/py-inferior.c (infpy_read_memory): Remove cleanups and
explicitly free 'buffer' on exit paths. Decref 'membuf_object'
before returning.
And the code has changed a lot since then, but the leak is still
fixed. Unfortunately, this commit didn't have any associated tests.
The original Fedora test wasn't really suitable for upstream, it was
reading /proc/PID/... to figure out if there was a leak or not.
However, we already have gdb.python/py-inferior-leak.exp in upstream
GDB, which makes use of the Python tracemalloc module to check for
memory leaks in a corner of the Python API, so I figured it wouldn't
hurt to rewrite the test in the same style.
And so here is a test for a bug which was closed 12 years ago. This
detects if the gdb.Inferior.read_memory() call leaks any memory.
I've tested this by hacking gdbpy_buffer_to_membuf, replacing the last
line which currently looks like this:
return PyMemoryView_FromObject ((PyObject *) membuf_obj.get ());
and instead doing:
return PyMemoryView_FromObject ((PyObject *) membuf_obj.release ());
The use of "release" here will mean we no longer decrement the
reference count on membuf_obj before returning from the function. As
a consequence the membuf_obj will not be garbage collected. With this
hack in place the new test will fail.
The Python script in the new test is mostly a copy&paste from
py-inferior-leak.py with the core changed to do a memory read instead
of inferior creation. I did consider rewriting both tests into a
single file, maybe, py-memory-leak.py, which would make it easier to
add additional similar tests in the future. For now I've held off
doing that, but if this gets merged then I _might_ revisit this idea.
If folk feel that this new test should only be accepted if I do this
rewrite then let me know and I can get that done.
On copyright date ranges: The .exp and .py scripts are new enough for
this commit that I've dated them 2024. The .c source script is lifted
directly from the old Fedora patch, so I've retained the original 2014
start date for that file only.
Approved-By: Tom Tromey <tom@tromey.com>
With gdb 15.1, python sys.exit no longer makes gdb exit:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
Python Exception <class 'SystemExit'>: 2
Error occurred in Python: 2
$1 = 123
0
...
This is a change in behaviour since commit a207f6b3a3 ("Rewrite "python"
command exception handling"), first available in gdb 15.1.
This patch reverts to the old behaviour by handling PyExc_SystemExit in
gdbpy_handle_exception, such what we have instead:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
2
...
Tested on x86_64-linux, with python 3.6 and 3.13.
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31946
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946
GDB deprecated the commands "show/set mpx bound" in GDB 15.1, as Intel
listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019.
MPX is also deprecated in gcc (since v9.1), the linux kernel (since v5.6)
and glibc (since v2.35). Let's now remove MPX support in GDB completely.
This includes the removal of:
- MPX functionality including register support
- deprecated mpx commands
- i386 and amd64 implementation of the hooks report_signal_info and
get_siginfo_type
- tests
- and pretty printer.
We keep MPX register numbers to not break compatibility with old gdbservers.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
Removing the pretty printer (bound_registers.py) in the next commit
leads to failures due to a missing import of 'gdb.printing':
"AttributeError: module 'gdb' has no attribute 'printing'".
Add this import to each file requiring it, as it's not imported by the
pretty-printer anymore.
Approved-By: Andrew Burgess <aburgess@redhat.com>
I noticed that two tests in gdb.ada/complete.exp are testing the same
thing: the completion of "p pck.inne". The second such test has this
comment:
# A fully qualified package name
I believe the intent here was to test "p pck.inner" (note the trailing
"r"). This patch makes this change.
One thing GDB always does when the inferior stops is finding out where
it's stopped at, by way of querying the value of the program counter
register.
To save a packet round trip, the remote target can send the PC
value (often alongside other frequently consulted registers such as the
stack pointer) in the stop reply packet as an "expedited register".
Test that this is actually done for the targets where gdbserver is
supposed to.
Extend the "maintenance print remote-registers" command output with an
"Expedited" column which says "yes" if the register was seen by GDB in
the last stop reply packet it received, and is left blank otherwise.
Tested for regressions on aarch64-linux-gnu native-extended-remote.
The testcase was tested on aarch64-linux-gnu, i686-linux-gnu and
x86_64-linux-gnu native-remote and native-extended-remote targets.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
While reviewing "catch (...)" uses I came across:
...
for (auto &item : local)
{
try
{
item ();
}
catch (...)
{
/* Ignore exceptions in the callback. */
}
}
...
This means that when an item throws a gdb_exception_forced_quit,
the exception is ignored and following items are executed.
Fix this by handling gdb_exception_forced_quit explicity, and immediately
rethrowing it.
I wondered about ^C, and couldn't decide whether current behaviour is ok, so
I left this alone, but I made the issue explicit in the source code.
As for the "catch (...)", I think that it should let a non-gdb_exception
propagate, so I've narrowed it to "catch (const gdb_exception &)".
My rationale for this is as follows.
There seem to be a few ways that "catch (...)" is allowed in gdb:
- clean-up and rethrow (basically the SCOPE_EXIT pattern)
- catch and handle an exception from a call into an external c++ library
Since we're dealing with neither of those here, we remove the "catch (...)".
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
While reviewing "catch (...)" uses I came across:
...
try
{
fileio_error remote_errno;
m_remote->remote_hostio_close (m_fd, &remote_errno);
}
catch (...)
{
/* Swallow exception before it escapes the dtor. If
something goes wrong, likely the connection is gone,
and there's nothing else that can be done. */
}
...
This also swallows gdb_exception_quit and gdb_exception_forced_quit. I don't
know whether these can actually happen here, but if not it's better to
accommodate for the possibility anyway.
Fix this by handling gdb_exception_quit and gdb_exception_forced_quit
explicitly.
It could be that "catch (...)" should be replaced by
"catch (const gdb_exception &)" but that depends on what kind of exception
remote_hostio_close is expected to throw, and I don't know that, so I'm
leaving it as is.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
This is similar to the previous events that we added, and adds support for
SMI, RSM, SIPI, INIT, VMENTRY, VMEXIT, SHUTDOWN, UINTR and UIRET.
Though since these are mainly mechanical and not really possible to test,
they are bundled in one commit.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Newer Intel CPUs support recording asynchronous events in the PT trace.
Libipt also recently added support for decoding these.
This patch adds support for interrupt events, based on the existing aux
infrastructure. GDB can now display such events during the record
instruction-history and function-call-history commands.
Subsequent patches will add the rest of the events currently supported.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Event tracing allows GDB to show information about interesting asynchronous
events when tracing with Intel PT. Subsequent patches will add support for
displaying each type of event.
Enabling event-tracing unconditionally would result in rather noisy output, as
breakpoints themselves result in interrupt events. Which is why this patch adds
a set/show command to allow the user to enable/disable event-tracing before
starting a recording. The event-tracing setting has no effect on an already
active recording. The default setting is off. As event tracing will use the
auxiliary infrastructure added by ptwrite, the user can still disable printing
events, even when event-tracing was enabled, by using the /a switch for the
record instruction-history/function-call-history commands.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
