| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Convert dwarf2_per_objfile::die_type_hash, which maps debug info
offsets to `type *`, to gdb::unordered_map.
Change-Id: I5c174af64ee46d38a465008090e812acf03704ec
|
|
Convert one use of htab_t, mapping (unrelocated) pc to call_site
objects, to `gdb::unordered_map<unrelocated_addr, call_site *>`.
Change-Id: I40a0903253a8589dbdcb75d52ad4d233931f6641
|
|
Convert one use of htab_t, mapping offsets to die_info object, to
`gdb::unordered_map<sect_offset, die_info *>`.
Change-Id: Ic80df22bda551e2d4c2511d167e057f4d6cd2b3e
|
|
This converts the BFD cache in gdb_bfd.c to use the new hash table.
Change-Id: Ib6257fe9d4f7f8ef793a2c82d53935a8d2c245a3
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts more code in the DWARF reader to use the new hash table.
Change-Id: I86f8c0072f0a09642de3d6f033fefd0c8acbc4a3
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts gdb_bfd.c to use the new hash table for all_bfds.
This patch slightly changes the htab_t pretty-printer test, which was
relying on all_bfds. Note that with the new hash table, gdb-specific
printers aren't needed; the libstdc++ printers suffice -- in fact,
they are better, because the true types of the contents are available.
Change-Id: I48b7bd142085287b34bdef8b6db5587581f94280
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts the typedef hash to use the new hash table.
This patch found a latent bug in the typedef code. Previously, the
hash function looked at the type name, but the hash equality function
used types_equal -- but that strips typedefs, meaning that equality of
types did not imply equality of hashes. This patch fixes the problem
and updates the relevant test.
Change-Id: I0d10236b01e74bac79621244a1c0c56f90d65594
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts the DWARF abbrevs themselves to use the new hash table.
Change-Id: I0320a733ecefe2cffeb25c068f17322dd3ab23e2
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts the DWARF abbrev cache to use the new hash table.
Change-Id: I5e88cd4030715954db2c43f873b77b6b8e73f5aa
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts gnu-v3-abi.c to use the new hash table.
This change shows how a std::vector can easily be made directly from
the hash table, simplifying the earlier approach of constructing a
vector and a hash table at the same time.
Change-Id: Ia0c387a035a52300db6b6f5a3a2e5c69efa01155
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts the objfile static link table to the new hash map.
Change-Id: If978e895679899ca2af4ef01c12842b4184d88e6
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts the type copying code to use the new hash map.
Change-Id: I35f0a4946dcc5c5eb84820126cf716b600f3302f
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts compile/compile.c to use the new hash table.
Change-Id: I7df3b8d791ece731ae0d1d64cdc91a2e372f5d4f
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts disasm.c to use the new hash table.
Change-Id: I2efbe7ecc2964ec49e0b726ad4674e8eafc929f7
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts py-framefilter.c to use the new hash table.
Change-Id: I38f4eaa8ebbcd4fd6e5e8ddc462502a92bf62f5e
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts breakpoint.c to use the new hash table.
Change-Id: I6d997a6242969586a7f8f9eb22cc8dd8d3ac97ff
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts dwarf2/macro.c to use the new hash table.
Change-Id: I6af0d1178e2db330fe3a89d57763974145ed17c4
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts target-descriptions.c to use the new hash table.
Change-Id: I03dfc6053c9856c5578548afcfdf58abf8b7ec2c
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts linespec.c to use the new hash table.
Note that more simplification could perhaps be done. Currently, the
collectors in this code insert an element into a set and then, if the
element has not been seen before, append it to a vector. If we know
the order does not matter, or if the results can be sorted later, we
could dispense with the vector. This would simplify the code some
more. (This technique is used in the vtable patch, later in this
series.)
Change-Id: Ie6828b1520d918d189ab5140dc8094a609152cf2
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts filename-seen-cache.h to use the new hash table.
filename-seen-cache.c is removed.
Change-Id: Iffac1d5e49d1610049b7deeef6e98d49e644366a
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
This converts compile-c-symbols.c to use the new hash table.
I made it use a set of string_view instead of a set of `symbol *`, to
avoid calling `symbol::natural_name` over and over. This appears safe
to do, since I don't expect the storage behing the natural names to
change during the lifetime of the map.
Change-Id: Ie9f9334d4f03b9a8ae6886287f82cd435eee217c
Co-Authored-By: Tom Tromey <tom@tromey.com>
|
|
cooked_indexer::ensure_cu_exists
With the test-case included in this patch, we run into:
...
$ gdb -q -batch $exec
Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \
[in module $exec]
...
The debug info consists of two CUs:
...
Compilation Unit @ offset 0xb2:
Length: 0x25 (32-bit)
Version: 4
Abbrev Offset: 0x6c
Pointer Size: 8
<0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
<be> DW_AT_language : 2 (non-ANSI C)
<1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
<c0> DW_AT_low_pc : 0x4004a7
<c8> DW_AT_high_pc : 0x4004b2
<d0> DW_AT_specification: <0xe8>
<1><d4>: Abbrev Number: 3 (DW_TAG_subprogram)
<d5> DW_AT_name : main
<1><da>: Abbrev Number: 0
Compilation Unit @ offset 0xdb:
Length: 0xf (32-bit)
Version: 4
Abbrev Offset: 0x86
Pointer Size: 8
<0><e6>: Abbrev Number: 1 (DW_TAG_compile_unit)
<e7> DW_AT_language : 2 (non-ANSI C)
<1><e8>: Abbrev Number: 2 (DW_TAG_subprogram)
<e9> DW_AT_specification: <0xd4>
<1><ed>: Abbrev Number: 0
...
where:
- DIE 0xbf in CU@0xb2 contains an inter-CU reference to
- DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to
- DIE 0xd4 back in CU@0xb2.
The dwarf error is caused by this bit of code in
cooked_indexer::ensure_cu_exists:
...
if (per_cu == m_per_cu)
return reader;
...
The dwarf error happens as follows:
- a cutu_reader A is created for CU@0xb2
- using cutu_reader A, the cooked index reader starts indexing dies, with
m_per_cu set to CU@0xb2
- while indexing it scans the attributes of DIE 0xbf and encounters the
inter-CU reference to DIE 0xe8
- it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for
CU@0xdb and returns it
- using cutu_reader B, it continues scanning attributes of DIE 0xe8 and
encounters the inter-CU reference to DIE 0xd4
- it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered
and cutu_reader B is returned
- using cutu_reader B, it continues scanning attributes of DIE 0xd4
- this goes wrong because:
- the attributes of the DIE are encoded using the abbreviation table at
offset 0x6c, while
- the decoding is done using cutu_reader B which uses the abbreviation table
at offset 0x86.
Fix this by removing the problematic if clause.
Since cutu_reader A is not preserved in m_index_storage,
cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate
cutu_reader C for CU@0xb2. Fix this in process_psymtab_comp_unit by preserving
the cutu_reader A as well in m_index_storage.
Tested on x86_64-linux and aarch64-linux.
PR symtab/32081
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32081
Approved-By: Tom Tromey <tom@tromey.com>
Reported-By: Andreas Schwab <schwab@linux-m68k.org>
|
|
I did a review of lines containing "catch (gdb_exception" and found a few
where we can add const.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In type_to_type_object we have:
...
try
{
if (type->is_stub ())
type = check_typedef (type);
}
catch (...)
{
/* Just ignore failures in check_typedef. */
}
...
The catch is supposed to ignore gdb_exception_error, but it ignores any
exception.
Fix that by only ignoring gdb_exception_error, and handling
gdb_exception_quit / gdb_exception_forced_quit using GDB_PY_HANDLE_EXCEPTION.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In svr4_handle_solib_event I noticed:
...
catch (const gdb_exception_error)
...
This seems to be the only place were we do this, elsewhere we have:
...
catch (const gdb_exception_error &)
...
I suppose the intent of adding '&' is to avoid a copy. I'm not sure if it's
necessary given that it's an unnamed const parameter, but I suppose it can't
hurt either.
Add the '&' here as well.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In get_test_insn in gdb/disasm-selftests.c, we find this code:
...
try
{
kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc);
insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen);
}
catch (...)
{
continue;
}
...
The catch is there to catch memory errors, but it swallows all exceptions, including
gdb_exception_quit and gdb_exception_forced_quit.
Fix this by limiting the catch to gdb_exception_error.
Tested on x86_64-linux, by rebuilding and running gdb.gdb/unittest.exp.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Some refactors around struct global_block, all in one patch because they
all tie in together and are relatively trivial.
- Make block::global_block() and blockvector::global_block() return
`global_block *`, instead of `block *`. There is no cost in doing
so, and it's a bit more precise. Callers of these methods that need
a `global_block *` won't need to cast themselves.
- Add some block::as_global_block methods, as a way to get a
`global_block *` from a `block *` when you know it's a global block.
This is basically a static cast with an assert.
- Move set_compunit_symtab to global_block, since it requires the
block to be a global block anyway. Rename to just `set_compunit` (I
think that compunit_symtab should just be renamed compunit...).
- Move the get_block_compunit_symtab free function to be a method of
global_block.
- Make global_block::compunit_symtab private and rename.
- Simplify initialize_block_iterator.
Change-Id: I1667a86b5c1a02d0d460cfad55b5d3d48867583d
Approved-By: Tom Tromey <tom@tromey.com>
|
|
dwarf2/read.c has this code:
else if (elf_section_data (sectp)->this_hdr.sh_size
> bfd_get_file_size (abfd))
This assumes that the BFD is an ELF, which is an invalid assumption.
A user noticed that this can sometimes cause a crash.
This patch fixes the problem by changing this code to use
bfd_section_size_insane.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32104
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
It was pointed out in this email:
https://inbox.sourceware.org/gdb-patches/97973506-79f4-4216-9c0b-57401b3933f5@arm.com
that this commit:
commit 0726729d344fecf98f8d138e688e77201cc3cece
Date: Mon Jun 3 13:56:54 2024 +0100
gdb/testsuite: track if a caching proc calls gdb_exit or not
had broken some AArch64 tests.
What is going on is that there are two caching procs:
allow_aarch64_sme_tests
aarch64_initialize_sme_information
the allow_aarch64_sme_tests proc makes a call to
aarch64_initialize_sme_information, but
aarch64_initialize_sme_information is also called from other
non-caching procs, like aarch64_supports_sme_svl.
Both of the caching procs mentioned above compile and run a helper
program, and both of them call gdb_exit.
After the above commit, the first call to any caching proc, the body
of which calls gdb_exit, will result in a gdb_exit call even if the
body is not executed and the result is fetched from the cache.
What was observed is that in the first test script
allow_aarch64_sme_tests is called, the body of this caching proc is
run which calls gdb_exit. Then allow_aarch64_sme_tests calls
aarch64_initialize_sme_information, the body of which is run and
gdb_exit is called again. The results from both procs are added to
the cache.
In the next test script allow_aarch64_sme_tests is called. This
results in a cache hit, but gdb_exit is also called as this is the
first call in this second test script.
Later in the test script aarch64_supports_sme_svl is called which
calls aarch64_initialize_sme_information. As this is the first call
to aarch64_initialize_sme_information in this second test
script (remember the body of allow_aarch64_sme_tests was never run)
then gdb_exit is called. This call to gdb_exit is new after the above
commit and is unexpected.
I think the idea behind the above commit is still sound. If the call
to allow_aarch64_sme_tests was removed from the second test script
then we would want the extra gdb_exit call as this would expose a real
bug in the test. The problem is that after the above commit the
nested nature of the caching proc calls becomes important: a call to
allow_aarch64_sme_tests should mean that we've also called
aarch64_initialize_sme_information, and that relationship isn't
currently captured.
So in this commit I'm adding another field to the global
gdb_data_cache (in lib/cache.exp). This new field is 'also_called'.
For every caching proc we populate this field with a list of names,
these are the names of any nested caching procs that are called when
the body of a caching proc is executed.
Now when we get a cache hit in gdb_data_cache we mark every proc in
the 'also_called' list as having been called. This means that further
calls to these procs will no longer trigger a gdb_exit call.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
commit cb9f919f ("gdb: add program_space parameter to
lookup_minimal_symbol_text") caused a crash on Windows. In this
function, section can be nullptr, but it is unconditionally
dereferenced by the change introduced by the patch.
I tested this using the AdaCore internal test suite.
v2: always use current_program_space, reverting to be behavior before
cb9f919f.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
While working on another bug, I noticed that the Ada code to find
exception symbols uses SEARCH_VFT. This will find variables and types
-- but only functions are needed here. This patch changes the code to
use SEARCH_FUNCTION_DOMAIN.
Tested on x86-64 Fedora 38, using a version of GNAT with the debuginfo
installed, to ensure the exception-related tests work.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
When running test-case gdb.python/py-mi-cmd.exp with python 3.13, I run into:
...
Expecting: ^(-pycmd exp[^M
]+)?(.*&"Traceback \(most recent call last\):.."^M
&"[^^M
]+py-mi-cmd.py[^^M
]+"^M
&"[^^M
]+raise gdb.GdbError\(\).."^M
&"gdb.GdbError.."^M
\^error,msg="Error occurred in Python\."[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd exp^M
&"Traceback (most recent call last):\n"^M
&" File \"py-mi-cmd.py\", line 76, in invoke\n raise gdb.GdbError()\n"^M
&"gdb.GdbError\n"^M
^error,msg="Error occurred in Python."^M
(gdb) ^M
FAIL: gdb.python/py-mi-cmd.exp: -pycmd exp (unexpected output)
...
In contrast, with python 3.12 I have:
...
Expecting: ^(-pycmd exp[^M
]+)?(.*&"Traceback \(most recent call last\):.."^M
&"[^^M
]+py-mi-cmd.py[^^M
]+"^M
&"[^^M
]+raise gdb.GdbError\(\).."^M
&"gdb.GdbError.."^M
\^error,msg="Error occurred in Python\."[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd exp^M
&"Traceback (most recent call last):\n"^M
&" File \"py-mi-cmd.py\", line 76, in invoke\n"^M
&" raise gdb.GdbError()\n"^M
&"gdb.GdbError\n"^M
^error,msg="Error occurred in Python."^M
(gdb) ^M
PASS: gdb.python/py-mi-cmd.exp: -pycmd exp
...
To make it easier to understand what we're looking at, let's take this out of
the mi interpreter context and use the cli interpreter:
...
$ gdb -q -batch -ex "set trace-commands on" -x gdb.in
+set python print-stack full
+source py-mi-cmd.py
+python pycmd1('-pycmd')
+python pycmd1.invoke (pycmd1, ["exp"])
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "py-mi-cmd.py", line 76, in invoke
raise gdb.GdbError()
gdb.GdbError
gdb.in:4: Error in sourced command file:
Error occurred in Python.
...
Interestingly, this is what we're seeing with both python 3.12 and 3.13.
The difference between the python versions is that:
- with python 3.12 each line is printed by itself, and
- with python 3.13 two particular lines are printed toghether.
With the cli interpreter, that makes no difference, because the '\n' is
interpreted.
But with the mi interpreter, that causes a difference in output because the
'\n' is not interpreted, but rather printed literally.
Fix this by accepting the new output in addition to the old one.
Tested on aarch64-linux.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
PR testsuite/31913
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31913
|
|
Do not override the generic OS ABI sniffer.
Fixes: 3eba3a011a8 ("Various m68k fixes for gdb")
|
|
gdb.ada/multiarray.exp has a loop that looks like it should run the
test in both 'all' and 'minimal' encodings mode. However, the body of
the loop doesn't actually use the 'flags' variable. This was an
oversight in the original commit.
|
|
Following on from the previous commit, this commit fixes the two KFAIL
in gdb.base/sysroot-debug-lookup.exp when not using the
native-extended-gdbserver board.
The failures in this test, when using the 'unix' board, are logged as
bug PR gdb/31804. The problem appears to be caused by the use of the
child_path function in find_separate_debug_file.
What happens on the 'unix' board is that the file is specified to GDB
with a target: prefix, however GDB spots that the target filesystem is
local to GDB and so opens the file without a target: prefix. When we
call into find_separate_debug_file the DIR and CANON_DIR arguments,
which are computed from the objfile_name() no longer have a target:
prefix.
However, in this test if the file was opened with a target: prefix,
then the sysroot also has a target: prefix. When child_path is called
it looks for a common prefix between CANON_DIR (from the objfile_name)
and the sysroot. However, the sysroot still has the target: prefix,
which means the child_path() call fails and returns nullptr.
What I think we need to do is this: if the sysroot has a target:
prefix, and the target filesystem is local to GDB, then we should
strip the target: prefix from the sysroot, just as we do when opening
a file (see gdb_bfd_open in gdb_bfd.c).
Now, when we make the child_path() call neither the sysroot nor
CANON_DIR will have a target: prefix, the child_path() call will
succeed, and GDB will correctly find the debug information.
There is just one remaining issue, the last path we look in when
searching for debug information is built by starting with the sysroot,
then adding the debug directory, see this line:
debugfile = path_join (target_prefix_str, root.c_str (),
debugdir.get (), base_path, debuglink);
The target_prefix_str is set to target: if DIR has a target: prefix,
and DIR should have a target: prefix if the file we're looking for was
opened with a target: prefix. However, in our case the file was in a
local filesystem so GDB stripped the prefix off.
The sysroot however, does have the target: prefix, and the test is
expecting to see GDB look within a file with the target: prefix.
Given that the above line is about looking within a sub-directory of
the sysroot, I think we should not be stripping the target: prefix off
the sysroot path (as we do when building ROOT), instead, we should, in
this case, not use TARGET_PREFIX_STR, and instead just use GDB's
sysroot as it is (in this case with the target: prefix).
With these fixes in place I now see no failures when using the 'unix',
'native-gdbserver', or 'native-extended-gdbserver' boards with this
test, and the KFAILs can be removed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
|
|
I spotted that the gdb.base/sysroot-debug-lookup.exp test that I added
recently actually had a KPASS when run with the
native-extended-gdbserver board. This was an oversight when adding
the test.
The failures in this test, when using the 'unix' board, are logged as
bug PR gdb/31804. The problem appears to be caused by the use of the
child_path function in find_separate_debug_file.
What happens on the 'unix' board is that the file is specified to GDB
with a target: prefix, however GDB spots that the target filesystem is
local to GDB and so opens the file without a target: prefix. When we
call into find_separate_debug_file the DIR and CANON_DIR arguments,
which are computed from the objfile_name() no longer have a target:
prefix.
However, in this test if the file was opened with a target: prefix,
then the sysroot also has a target: prefix. When child_path is called
it looks for a common prefix between CANON_DIR (from the objfile_name)
and the sysroot. However, the sysroot still has the target: prefix,
which means the child_path() call fails and returns nullptr.
What happens in the native-extended-gdbserver case is that GDB doesn't
see the target filesystem as local. Now the filename retains the
target: prefix, which means that in the child_path() call both the
sysroot and the CANON_DIR have a target: prefix, and so the
child_path() call succeeds. This allows GDB to progress, try some
additional paths, and then find the debug information.
So, this commit changes gdb.base/sysroot-debug-lookup.exp to expect
the test to succeed when using the native-extended-gdbserver protocol.
This leaves one KFAIL when using the native-extended-gdbserver board,
we find the debug information but (apparently) find it in the wrong
file. What's happening is that when GDB builds the filename for the
debug information we end up with a '//' string as a directory
separator, the test regexp only expects a single separator.
Instead of just fixing the test regexp, I've updated the path_join
function in gdbsupport/pathstuff.{cc,h} to allow for absolute paths to
appear in the argument list after the first argument. This means it's
now possible to do this:
auto result = path_join ("/a/b/c", "/d/e/f");
gdb_assert (result == "/a/b/c/d/e/f");
Additionally I've changed path_join so that it avoids adding
unnecessary directory separators. In the above case when the two
paths were joined GDB only added a single separator between 'c' and
'd'. But additionally, if we did this:
auto result = path_join ("/a/b/c/", "/d/e/f");
gdb_assert (result == "/a/b/c/d/e/f");
We'd still only get a single separator.
With these changes to path_join I can now make use of this function in
find_separate_debug_file. With this done I now have no KFAIL when
using the native-extended-gdbserver board.
After this commit we still have 2 KFAIL when not using the
native-gdbserver and unix boards, these will be addressed in the next
commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
Commit bf2813aff8f2988ad3d53e819a0415abf295c91f introduced some logic to
not refresh the step frame id if it detects that the inferior is reverse
stepping out of a recursive call, so that we would still print frame
information once the inferior stops.
However, that logic was overly specific, and wouldn't be hit for
inferiors compiled with clang because clang adds line table entries that
aren't statements, making process_event_stop_test go through a different
branch on the relevant if statement.
Fix this by not making the code that detects "reversing out of a
recursion" an else clause to the previous if, but a standalone if block.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Usually with test-case gdb.python/py-progspace-events.exp I get:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 4116] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M
28 { /* Nothing. */ }^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
step^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabf4f850>^M
do_parent_stuff () at py-progspace-events.c:41^M
41 ++global_var;^M
(gdb) PASS: gdb.python/py-progspace-events.exp: step
...
But occasionally I run into the following FAIL:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
(gdb) FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout)
...
This is caused by a race between the handling of an event, and the
"inferior 1" command.
In the passing case, the event is handled first. During which prune_inferiors
is called, but it can't remove inferior 2, because it's still the current one.
In the failing case, the "inferior 1" command is handled first. Then during
handling of the event, prune_inferiors is called, and it can remove inferior 2
because it's no longer the current one.
This looks like a test-case issue to me, but ISTM that we can do better: by
calling prune_inferiors asap, at the end of the "inferior 1" command, we
stabilize the moment when the inferior is removed:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
...
This also allows us to simplify the test-case by removing the step command,
which is no longer required to trigger the pruning of the inferior.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR gdb/31440
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440
|
|
The relatively new "globals" scope code in DAP has a fairly obvious
bug -- the fetch_one_child method should return a tuple with two
elements, but instead just returns the variable's value.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into:
...
(gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada
print pck.fp1_var^M
$1 = 0.3125^M
(gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var
...
The problem is that the thumb prologue analyzer overshoot, setting the
breakpoint for main after line 49:
...
46 int
47 main (void)
48 {
49 pck__fp1_var++;
...
and consequently we see the value of pck.fp1_var after line 49 instead of
before line 49. This is PR tdep/31981.
Work around this by removing line 49 and all similar subsequent lines, which
turn out to be dead code.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested on arm-linux.
|
|
On arm-linux I run into:
...
(gdb) p *kernel_user_helper_version^M
Cannot access memory at address 0xffff0ffc^M
(gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version
...
What the test-case is trying to do, is to access a special address in the arm
linux kernel [1] using ptrace, which doesn't seem to work.
This is with kernel version 6.1.55. Perhaps this used to work, but the kernel
was modified to be more strict with respect to access to this special address.
Fix this by making the inferior access that special address instead.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/32070
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070
[1] https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
|
|
My previous patch
commit 8958aefd34200c8d2cd6e81bba32198468789c62 (HEAD)
Author: Felix Willgerodt <felix.willgerodt@intel.com>
Date: Mon Feb 25 15:30:29 2019 +0100
python: Add clear() to gdb.Record.
exposed a clear function for btrace data in python and added some tests
for it. That caused a regression (PR 32086) when recording with bts.
This is reproducible even without my patch, when adding
"maintenance btrace clear" to the test.
When comparing the instructions that get recorded in both cases, the traces
are almost identical, just that the first 3 instructions are missing.
Before clear:
(gdb) record instruction-history 1,100
1 0x0000555555555163 <main+12>: movl $0x0,-0x4(%rbp)
2 0x000055555555516a <main+19>: movl $0x0,-0x8(%rbp)
3 0x0000555555555171 <main+26>: jmp 0x555555555184 <main+45>
4 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
5 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
6 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
7 0x0000555555555176 <main+31>: mov %eax,%edi
...
After clear:
(gdb) record instruction-history 1,100
1 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
2 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
3 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
4 0x0000555555555176 <main+31>: mov %eax,%edi
...
The GDB manual describes this behaviour already:
maint btrace clear
Discard the branch trace data. The data will be fetched anew and
the branch trace will be recomputed when needed.
This implicitly truncates the branch trace to a single branch trace
buffer. When updating branch trace incrementally, the branch trace
available to GDB may be bigger than a single branch trace buffer.
The test with BTS is updating the recorded trace incrementally. After the
clear, the buffer of raw trace data available is not enough to recompute the
whole trace as it was before the clear(), and the first 3 instructions are
missing.
As increasing the buffer size for BTS didn't help, I propose to fix the test
by moving the testing of clear to the end of the test.
Approved-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086
|
|
While working on something else, I noticed that this is relatively
common:
scoped_restore_current_language save;
set_language (something);
This patch adds a second constructor to
scoped_restore_current_language to simplify this idiom.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
I think it would be useful for gdb's DAP logs to come with the version
and configuration information. This might make debugging some bug
reports a little simpler.
|
|
A DAP user noticed that breakpoints set by address were never updated
to show their location after the DAP launch request. It turns out
that gdb does not emit the breakpoint-modified event when this sort of
breakpoint is updated.
This patch changes gdb to notify the breakpoint-modified observer when
a breakpoint location's symbol changes. This in turn causes the DAP
event to be emitted.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
While working on earlier patches, I noticed that the DAP C++ exception
test had some strange results in the log. Digging into this, I found
that while the Ada catchpoints emit a "bkptno" field in the MI result,
the C++ ones do not -- but the DAP code was relying on this.
This patch fixes the problem by changing which field is examined, and
then updates the tests to verify this.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
Currently, when a DAP client uses setInstructionBreakpoints, the
resulting breakpoints are created as "verified", even though there is
no symbol file and thus the breakpoint can't possibly have a source
location.
This patch changes the DAP code to assume that all breakpoints are
unverified before launch.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This adds a new exec_mi_and_log function that wraps gdb.execute_mi and
logs the command. This can be handy when debugging DAP.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
I noticed that initialize_block_iterator has a default value for one
of its arguments, but this is not needed as this function has a single
caller that always passes all arguments. This patch removes the
default. Tested by rebuilding.
|
|
Call the ptwrite filter function whenever a ptwrite event is decoded.
The returned string is written to the aux_data string table and a
corresponding auxiliary instruction is appended to the function segment.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
