| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Right now, gdbsupport/common-regcache.h contains two abstractons for a
regcache. An opaque type `regcache` (gdb and gdbserver both have their
own regcache that is the concrete version of this) and an abstract base
class `reg_buffer_common`, that is the base of regcaches on both sides.
These abstractions allow code to be written for both gdb and gdbserver,
for instance in the gdb/arch sub-directory.
However, having two
different abstractions is impractical. If some common code has a regcache,
and wants to use an operation defined on reg_buffer_common, it can't.
It would be better to have just one. Change all instances of `regcache
*` in gdbsupport/common-regcache.h to be `reg_buffer_common *`, then fix
fallouts.
Implementations in gdb and gdbserver now need to down-cast (using
gdb::checked_static_cast) from reg_buffer_common to their concrete
regcache type. Some of them could be avoided by changing free functions
(like regcache_register_size) to be virtual methods on
reg_buffer_common. I tried it, it seems to work, but I did not include
it in this series to avoid adding unnecessary changes.
Change-Id: Ia5503adb6b5509a0f4604bd2a68b4642cc5283fd
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
I think that i386 k registers are raw registers, and therefore shouldn't
be handled in the various functions handling pseudo registers.
What tipped me off is the code in i386_pseudo_register_read_into_value:
else if (i386_k_regnum_p (gdbarch, regnum))
{
regnum -= tdep->k0_regnum;
/* Extract (always little endian). */
status = regcache->raw_read (tdep->k0_regnum + regnum, raw_buf);
We take regnum (the pseudo register number we want to read), subtract
k0_regnum, add k0_regnum, and pass the result to raw_read. So we would
end up calling raw_read with the same regnum as the function received
which is supposedly a pseudo register number.
Other hints are:
- The command `maint print raw-registers` shows the k registers.
- Printing $k0 doesn't cause i386_pseudo_register_read_into_value to be
called.
- There's code in i387-tdep.c to save/restore the k registers.
Remove handling of the k registers from:
- i386_pseudo_register_read_into_value
- i386_pseudo_register_write
- i386_ax_pseudo_register_collect
Change-Id: Ic97956ed59af6099fef6d36a0b61464172694562
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
Currently, it's not possible to call a variadic C++ function:
```
(gdb) print sum_vararg_int(1, 10)
Cannot resolve function sum_vararg_int to any overloaded instance
(gdb) print sum_vararg_int(2, 20, 30)
Cannot resolve function sum_vararg_int to any overloaded instance
```
It's because all additional arguments get the TOO_FEW_PARAMS_BADNESS
rank by rank_function, which disqualifies the function.
To fix this, I've created the new VARARG_BADNESS rank, which is
used only for additional arguments of variadic functions, allowing
them to be called:
```
(gdb) print sum_vararg_int(1, 10)
$1 = 10
(gdb) print sum_vararg_int(2, 20, 30)
$2 = 50
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28589
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This changes explicit_location_spec to use unique_xmalloc_ptr,
removing some manual memory management.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
This changes linespec_location_spec to use unique_xmalloc_ptr,
removing some manual memory management.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
The bindings for the reverse execution commands are the same letters
as the forward execution command, but with the opposite case. This way
one can simply hold down the Shift modifier key or tap the Caps Lock key
to change the direction of execution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In python/py-gdb-readline.c we make use of _PyOS_ReadlineTState,
however, this variable is no longer public in Python 3.13, and so GDB
no longer builds.
We are making use of _PyOS_ReadlineTState in order to re-acquire the
Python Global Interpreter Lock (GIL). The _PyOS_ReadlineTState
variable is set in Python's outer readline code prior to calling the
user (GDB) supplied readline callback function, which for us is
gdbpy_readline_wrapper. The gdbpy_readline_wrapper function is called
without the GIL held.
Instead of using _PyOS_ReadlineTState, I propose that we switch to
calling PyGILState_Ensure() and PyGILState_Release(). These functions
will acquire the GIL based on the current thread. I think this should
be sufficient; I can't imagine why we'd be running
gdbpy_readline_wrapper on one thread on behalf of a different Python
thread.... that would be unexpected I think.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Move gdbpy_gil class into python-internal.h, the next
commit wants to make use of this class from a file other
than python.c.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While making recent changes to 'save gdb-index' command I triggered
some errors -- of the kind a user might be expected to trigger if they
do something wrong -- and I didn't find GDB's output as helpful as it
might be.
For example:
$ gdb -q /tmp/hello.x
...
(gdb) save gdb-index /non_existing_dir
Error while writing index for `/tmp/hello': mkstemp: No such file or directory.
That the error message mentions '/tmp/hello', which does exist, but
doesn't mention '/non_existing_dir', which doesn't is, I think,
confusing.
Also, I find the 'mkstemp' in the error message confusing for a user
facing error. A user might not know what mkstemp means, and even if
they do, that it appears in the error message is an internal GDB
detail. The user doesn't care what function failed, but wants to know
what was wrong with their input, and what they should do to fix
things.
Similarly, for a directory that does exist, but can't be written to:
(gdb) save gdb-index /no_access_dir
Error while writing index for `/tmp/hello': mkstemp: Permission denied.
In this case, the 'Permission denied' might make the user thing there
is a permissions issue with '/tmp/hello', which is not the case.
After this patch, the new errors are:
(gdb) save gdb-index /non_existing_dir
Error while writing index for `/tmp/hello': `/non_existing_dir': No such file or directory.
and:
(gdb) save gdb-index /no_access_dir
Error while writing index for `/tmp/hello': `/no_access_dir': Permission denied.
we also have:
(gdb) save gdb-index /tmp/not_a_directory
Error while writing index for `/tmp/hello': `/tmp/not_a_directory': Is not a directory.
I think these do a better job of guiding the user towards fixing the
problem.
I've added a new test that exercises all of these cases, and also
checks the case where a user tries to use an executable that already
contains an index in order to generate an index. As part of the new
test I've factored out some code from ensure_gdb_index (lib/gdb.exp)
into a new proc (get_index_type), which I've then used in the new
test. I've confirmed that all the tests that use ensure_gdb_index
still pass.
During review it was pointed out that the testsuite proc
have_index (lib/gdb.exp) is similar to the new get_index_type proc, so
I've rewritten have_index to also use get_index_type, I've confirmed
that all the tests that use have_index still pass.
Nothing that worked correctly before this patch should give an error
after this patch; I've only changed the output when the user was going
to get an error anyway.
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently, when creating a gdb.FinishBreakpoint in a function
called from an inline frame, it will never be hit:
```
(gdb) py fb=gdb.FinishBreakpoint()
Temporary breakpoint 1 at 0x13f1917b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
(gdb) c
Continuing.
Thread-specific breakpoint 1 deleted - thread 1 no longer in the thread list.
[Inferior 1 (process 1208) exited normally]
```
The reason is that the frame_id of a breakpoint has to be the
ID of a real frame, ignoring any inline frames.
With this fixed, it's working correctly:
```
(gdb) py fb=gdb.FinishBreakpoint()
Temporary breakpoint 1 at 0x13f5617b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
(gdb) c
Continuing.
Breakpoint 1, increase_inlined (a=0x40fa5c) at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c:47
(gdb) py print(fb.return_value)
-8
```
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When using $_thread in info threads to showonly the current thread,
you get this error:
```
(gdb) info thread $_thread
Convenience variable must have integer value.
Args must be numbers or '$' variables.
```
It's because $_thread is a dynamically computed convenience
variable, which isn't supported yet by get_internalvar_integer.
Now the output looks like this:
```
(gdb) info threads $_thread
Id Target Id Frame
* 1 Thread 10640.0x2680 main () at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/gdbvars.c:21
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17600
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This implements DAP cancellation. A new object is introduced that
handles the details of cancellation. While cancellation is inherently
racy, this code attempts to make it so that gdb doesn't inadvertently
cancel the wrong request.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30472
Approved-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
Cancellation will generally be seen by the DAP code as a
KeyboardInterrupt. However, this derives from BaseException and not
Exception, so a small change is needed to send_gdb_with_response, to
forward the exception to the DAP server thread.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This renames a couple of DAP procs in the testsuite, to clarify that
they are now exported. The cancellation test will need these.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
DAP cancellation needs a way to interrupt whatever is happening on
gdb's main thread -- whether that is the inferior, a gdb CLI command,
or Python code.
This patch adds a new gdb.interrupt() function for this purpose. It
simply sets the quit flag and lets gdb do the rest.
No tests in this patch -- instead this is tested via the DAP
cancellation tests.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This changes the DAP server to move the JSON reader to a new thread.
This is key to implementing request cancellation, as now requests can
be read while an earlier one is being serviced.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This patch introduces a new NotStoppedException type and changes the
DAP implementation of "not stopped" to use it. I was already touching
some code in this area and I thought this looked a little cleaner.
This also has the advantage that we can now choose not to log the
exception -- previously I was sometimes a bit alarmed when seeing this
in the logs, even though it is harmless.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
Now that gdb adds stop-reason details to stop events, we can simplify
the DAP code to emit correct stop reasons in its own events. For the
most part a simple renaming of gdb reasons is sufficient; however,
"pause" must still be handled specially.
|
|
This changes Python stop events to carry a "details" dictionary, that
holds any relevant information about the stop. The details are
constructed using more or less the same procedure as is done for MI.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13587
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This moves the declaration of py_ui_out to a new header, so that it
can more readily be used by other code.
|
|
Commit cff71358132 ("gdb/testsuite: tighten up some end-of-line patterns") replaced:
...
set eol "\[\r\n\]+"
...
with the more strict:
...
set eol "\r\n"
...
in a few test-cases, but didn't update all uses of eol accordingly.
Fix this in three gdb.ada test-cases.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I found some spots using "target:"; I think it's better to use the
define everywhere, so this changes these to use TARGET_SYSROOT_PREFIX.
In some spots, is_target_filename is used rather than an explicit
check.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Now that DAP is in GDB 14, significant changes to it should be noted
in NEWS. This patch adds a note for a fix that's already gone in. I
started a new section in NEWS because more changes are coming.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30473
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
PR29011 notes that dynamic_cast does not work correctly if
classes with virtual methods are involved, some of the results
wrongly point into the vtable of the derived class:
```
(gdb) p vlr
$1 = (VirtualLeftRight *) 0x162240
(gdb) p vl
$2 = (VirtualLeft *) 0x162240
(gdb) p vr
$3 = (VirtualRight *) 0x162250
(gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
$4 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeftRight*>(vl)
$5 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeftRight*>(vr)
$6 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeft*>(vlr)
$7 = (VirtualLeft *) 0x162240
(gdb) p dynamic_cast<VirtualLeft*>(vl)
$8 = (VirtualLeft *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeft*>(vr)
$9 = (VirtualLeft *) 0x162240
(gdb) p dynamic_cast<VirtualRight*>(vlr)
$10 = (VirtualRight *) 0x162250
(gdb) p dynamic_cast<VirtualRight*>(vl)
$11 = (VirtualRight *) 0x162250
(gdb) p dynamic_cast<VirtualRight*>(vr)
$12 = (VirtualRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
```
For the cases where the dynamic_cast type is the same as the
original type, it used the ARG value for the result, which in
case of pointer types was already the dereferenced value.
And the TEM value at the value address was created with the
pointer/reference type, not the actual class type.
With these fixed, the dynamic_cast results make more sense:
```
(gdb) p vlr
$1 = (VirtualLeftRight *) 0x692240
(gdb) p vl
$2 = (VirtualLeft *) 0x692240
(gdb) p vr
$3 = (VirtualRight *) 0x692250
(gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
$4 = (VirtualLeftRight *) 0x692240
(gdb) p dynamic_cast<VirtualLeftRight*>(vl)
$5 = (VirtualLeftRight *) 0x692240
(gdb) p dynamic_cast<VirtualLeftRight*>(vr)
$6 = (VirtualLeftRight *) 0x692240
(gdb) p dynamic_cast<VirtualLeft*>(vlr)
$7 = (VirtualLeft *) 0x692240
(gdb) p dynamic_cast<VirtualLeft*>(vl)
$8 = (VirtualLeft *) 0x692240
(gdb) p dynamic_cast<VirtualLeft*>(vr)
$9 = (VirtualLeft *) 0x692240
(gdb) p dynamic_cast<VirtualRight*>(vlr)
$10 = (VirtualRight *) 0x692250
(gdb) p dynamic_cast<VirtualRight*>(vl)
$11 = (VirtualRight *) 0x692250
(gdb) p dynamic_cast<VirtualRight*>(vr)
$12 = (VirtualRight *) 0x692250
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29011
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed a "not not" in the Python documentation where just "not" was
meant. This patch fixes the error.
|
|
In tui_layout_split::apply I noticed that for variable-size layouts we take
share_box into account by decreasing used_size:
...
used_size += info[i].size;
if (info[i].share_box)
--used_size;
...
but not for fixed-size layouts:
...
if (info[i].min_size == info[i].max_size)
available_size -= info[i].min_size;
...
Fix this by increasing available_size for fixed-size layouts with shared box.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The focused window is highlighted by using active-border-kind instead of
border-kind.
But if the focused window is the cmd window (which is an unboxed window), then
no highlighting is done, and it's not obvious from looking at the screen which
window has the focus. Instead, you have to notice the absence of highlighting
on boxed windows, and then infer that the focus is on the unboxed window.
That approach stops working if there are multiple unboxed windows.
Likewise if highlighting is switched off by setting active-border-kind to the
same value as border-kind.
Make it more explicit which window has the focus by mentioning it in the status
window, like so:
...
native process 8282 (src) In: main L7 PC: 0x400525
...
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Since 3c45e9f915ae4aeab7312d6fc55a947859057572 gdb crashes when trying
to print a global variable stub without a running inferior, because of
a missing nullptr-check (the block_scope function took care of that
check before it was converted to a method).
With this check it works again:
```
(gdb) print s
$1 = <incomplete type>
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31128
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Following on from the previous commit, I searched the testsuite for
places where we did:
set eol "<some pattern>"
in most cases the <some pattern> could be replaced with "\r\n" though
in the stabs test I've switched to using the multi_line proc as that
seemed like a better choice.
In gdb.ada/info_types.exp I did need to add an extra use of $eol as
the previous pattern would match multiple newlines, and in this one
place we were actually expecting to match multiple newlines. The
tighter pattern only matches a single newline, so we now need to be
explicit when multiple newlines are expected -- I think this is a good
thing.
All the tests are still passing for me after these changes.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While reviewing another patch I spotted a timeout in
gdb.ada/complete.exp when testing in READ1 mode, e.g.:
$ make check-read1 TESTS="gdb.ada/complete.exp"
...
FAIL: gdb.ada/complete.exp: complete break ada (timeout)
...
The problem is an attempt to match the entire output from GDB within a
single gdb_test_multiple pattern, for a completion command that
returns a large number of completions.
This commit changes the gdb_test_multiple to process the output line
by line. I don't use the gdb_test_multiple -lbl option, as I've
always found that option backward -- it checks for the \r\n at the
start of each line rather than the end, I think it's much clearer to
use '^' at the start of each pattern, and '\r\n' at the end, so that's
what I've done here.
.... Or I would, if this test didn't already define $eol as the end of
line regexp ... except that $eol was set to '[\r\n]*', which isn't
that helpful, so I've updated $eol to be just '\r\n' the actual end of
line regexp.
And now, the test passes without a timeout when using READ1.
There should be no change in what is tested after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Building on the last commit, which added a general --debug=COMPONENT
option to the gdbserver command line, this commit updates the monitor
command to allow for general:
(gdb) monitor set debug COMPONENT off|on
style commands. Just like with the previous commit, the COMPONENT can
be any one of all, threads, remote, event-loop, and correspond to the
same set of global debug flags.
While on the command line it is possible to do:
--debug=remote,event-loop,threads
the components have to be entered one at a time with the monitor
command. I guess there's no reason why we couldn't allow component
grouping within the monitor command, but (to me) what I have here
seemed more in the spirit of GDB's existing 'set debug ...' commands.
If people want it then we can always add component grouping later.
Notice in the above that I use 'off' and 'on' instead of '0' and '1',
which is what the 'monitor set debug' command used to use. The 0/1
can still be used, but I now advertise off/on in all the docs and help
text, again, this feels more inline with GDB's existing boolean
settings.
I have removed the two existing monitor commands:
monitor set remote-debug 0|1
monitor set event-loop-debug 0|1
These are replaced by:
monitor set debug remote off|on
monitor set debug event-loop off|on
respectively.
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Currently, gdbserver has the following command line options related to
debugging output:
--debug
--remote-debug
--event-loop-debug
This doesn't scale well. If I want an extra debug component I need to
add another command line flag.
This commit changes --debug to take a list of components.
The currently supported components are: all, threads, remote, and
event-loop. The 'threads' component represents the debug we currently
get from the --debug option. And if --debug is used without a
component list then the threads component is assumed as the default.
Currently the threads component actually includes a lot of output that
is not really threads related. In the future I'd like to split this
up into some new, separate components. But that is not part of this
commit, or even this series.
The special component 'all' does what you'd expect: enables debug
output from all supported components.
The component list is parsed left to write, and you can prefix a
component with '-' to disable that component, so I can write:
target> gdbserver --debug=all,-event-loop
to get debug for all components except the event-loop component.
I've removed the existing --remote-debug and --event-loop-debug
command line options, these are equivalent to --debug=remote and
--debug=event-loop respectively, or --debug=remote,event-loop to
enable both components.
In this commit I've only update the command line options, in the next
commit I'll update the monitor commands to support a similar
interface.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The gdb/testsuite/README file documents GDB_DEBUG and GDBSERVER_DEBUG
flags, which can be passed to make in order to enable debugging within
GDB or gdbserver respectively.
However, when I do:
make check-gdb GDB_DEBUG=infrun
I don't see the corresponding debug feature within GDB being enabled.
Nor does:
make check-gdb GDBSERVER_DEBUG=debug \
RUNTESTFLAGS="--target_board=native-extended-gdbserver"
Appear to enable gdbserver debugging.
I tracked this down to the GDB_DEBUG and GDBSERVER_DEBUG flags being
missing from the TARGET_FLAGS_TO_PASS variable in gdb/Makefile. This
variable already contains lots of testing related flags, like
RUNTESTFLAGS and TESTS, so I think it makes sense to add GDB_DEBUG and
GDBSERVER_DEBUG here too.
With this done, this debug feature is now working as expected.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR29079 shows that pretty printers can be used for an incomplete
type (stub), but only when printing it directly, not if it's
part of another struct:
```
(gdb) p s
$1 = {pp m_i = 5}
(gdb) p s2
$2 = {m_s = <incomplete type>, m_l = 20}
```
The reason is simply that in common_val_print the check for stubs
is before any pretty printer is tried.
It works if the pretty printer is tried before the stub check:
```
(gdb) p s
$1 = {pp m_i = 5}
(gdb) p s2
$2 = {m_s = {pp m_i = 10}, m_l = 20}
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29079
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A TUI src window is displaying either:
- the source for the current frame,
- the source for main, or
- the string "[ No Source Available ]".
Since commit 03893ce67b5 ("[gdb/tui] Fix resizing of terminal to 1 or 2 lines")
we're able to resize the TUI to 1 line without crashing.
I noticed that if TUI is displaying main, and we resize to 1 line (destroying
the src window) and then back to a larger terminal (reconstructing the src
window), the TUI displays "[ No Source Available ]" instead of main.
Fix this by moving the responsibility for showing main from tui_enable to
tui_source_window_base::rerender.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR rust/31082 points out that casting a 128-bit integer to a pointer
will fail. This happens because a case in value_cast was not
converted to use GMP.
This patch fixes the problem. I am not really sure that testing
against the negative value here makes sense, but I opted to just
preserve the existing behavior rather than change it.
Regression tested on x86-64 Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31082
|
|
PR rust/31005 points out that dynamic type resolution of a LOC_CONST
or LOC_CONST_BYTES symbol will fail, leading to output like:
from_index=<error reading variable: Cannot access memory at address 0x0>
This patch fixes the problem by using the constant value or bytes when
performing type resolution.
Thanks to tpzker@thepuzzlemaker.info for a first version of this
patch.
I also tested this on a big-endian PPC system (cfarm203).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31005
|
|
When examining a failure that happens when testing
gdb.python/py-symtab.c with clang, I noticed that it was going wrong
because the test assumed that whenever we get an SAL, its end would
always be right before statement in the line table. This is true for GCC
compiled binaries, since gcc only adds statements to the line table, but
not true for clang compiled binaries.
This is the second time I run into a problem where GDB doesn't handle
non-statement line table entries correctly. The other was eventually
committed as 9ab50efc463ff723b8e9102f1f68a6983d320517: "gdb: fix until
behavior with trailing !is_stmt lines", but that commit only changes the
behavior for the 'until' command. In this patch I propose a more general
solution, making it so every time we generate the SAL for a given pc, we
set the end of the SAL to before the next statement or the first
instruciton in the next line, instead of naively assuming that to be the
case.
With this new change, the edge case is removed from the processing of
the 'until' command without regressing the accompanying test case, and
no other regressions were observed in the testsuite.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch adds support for process recording of the instruction rdtscp in
x86 architecture.
Debugging applications with "record full" fail to record with the error
message "Process record does not support instruction 0xf01f9".
Approved-by: Guinevere Larsen <blarsen@redhat.com>
|
|
The test gdb.base/watchpoint.exp has a proc named 'test_stepping'
which claims to "Test stepping and other mundane operations with
watchpoints enabled". It sets a watchpoint on ival2, performs an
inferior function call (which is not at all mundane), and uses 'next',
'until', and, finally, does a 'step'.
However, that final 'step' command steps to (but not over/through) the
line at which the assignment to ival2 takes place. At no time while
performing these operations is a watchpoint hit.
This commit adds a test to see what happens when stepping over/through
the assignment to ival2. The watchpoint on ival2 should be triggered
during this step. I've added another 'step' to make sure that the
correct statement is reached after performing the watchpoint-hitting
step.
After running the 'test_stepping' proc, gdb.base/watchpoint.exp does
a clean_restart before doing further tests, so nothing depends upon
'test_stepping' to stop at the particular statement at which it had
been stopping.
I've examined all tests which set watchpoints and step. I haven't
been able to identify a(nother) test case which tests what happens
when stepping over/through a statement which triggers a watchpoint.
Therefore, adding these new 'step' tests is testing something which
hasn't being tested elsewhere.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
I noticed it when I was trying to set a breakpoint at ExitProcess:
```
(gdb) b ExitProcess
Breakpoint 1 at 0x14001fdd0
(gdb) r
Starting program: C:\qiewer\heob\heob64.exe
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x3dbf4120
Cannot insert breakpoint 1.
Cannot access memory at address 0x77644120
```
The problem doesn't exist in gdb 13.2, and the difference can easily be
seen when printing ExitProcess.
gdb 14.1:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77644120 <UserHandleGrantAccess+36128>
```
gdb 13.2:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77734120 <ntdll!RtlExitUserProcess>
```
The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a,
where VMA was then calculated relative to FORWARD_DLL_NAME, while it was
relative to DLL_NAME before.
Fixed by calculating VMA relative to DLL_NAME again.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31112
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This fixes a small grammar issue in gdb.texinfo -- "additional" was
written where "additionally" is correct.
|
|
The only caller of quick_symbol_functions::expand_matching_symbols was
removed, so now this method and all implementations of it can be
removed.
|
|
The recent changes to the way Ada names are matched means that
split_style::UNDERSCORE is no longer used. This patch removes it.
|
|
The previous patch fixed the immediate performance problem with Ada
name matching, by having a subset of matches call
expand_symtabs_matching rather than expand_matching_symbols. However,
it seemed to me that expand_matching_symbols should not be needed at
all.
To achieve this, this patch changes ada_lookup_name_info::split_name
to use the decoded name, rather than the encoded name. In order to
make this work correctly, a new decoded form is used: one that does
not decode operators (this is already done) and also does not decode
wide characters. The latter change is done so that changes to the Ada
source charset don't affect the DWARF index.
With this in place, we can change ada-lang.c to always use
expand_symtabs_matching rather than expand_matching_symbols.
|
|
A user reported that certain operations -- like printing a large
structure -- could be slow. I tracked this down to
ada-lang.c:map_matching_symbols taking an inordinate amount of time.
Specifically, calls like the one to look for a parallel "__XVZ"
variable, in ada_to_fixed_type_1, could result in gdb walking over all
the entries in the cooked index over and over.
Looking into this reveals that
cooked_index_functions::expand_matching_symbols is not written
efficiently -- it ignores its "ordered_compare" parameter. While
fixing this would be good, it turns out that this entire method isn't
needed; so this series removes it.
However, the deletion is not done in this patch. This one, instead,
fixes the immediate cause of the slowdown, by using
objfile::expand_symtabs_matching when possible. This approach is
faster because it is more selective about which index entries to
examine.
|
|
I noticed that the DWARF assembler starts abbrevs at 2.
I think 1 should be preferred.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
|
|
Changes introduced by commit 9e8915c6cee5c37637521b424d723e990e06d597
caused a regression that meant hardware watchpoint stops would not
trigger in reverse execution or replay mode. This was documented in
PR breakpoints/21969.
The problem is that record_check_stopped_by_breakpoint always overwrites
record_full_stop_reason, thus loosing the TARGET_STOPPED_BY_WATCHPOINT
value which would be checked afterwards.
This commit fixes that by not overwriting the stop-reason in
record_full_stop_reason if we're not stopped at a breakpoint.
And the test for hw watchpoints in gdb.reverse/watch-reverse.exp actually
tested sw watchpoints again, since "set can-use-hw-watchpoints 1"
doesn't convert enabled watchpoints to use hardware.
This is fixed by disabling said watchpoint while enabling hw watchpoints.
The same is not done for gdb.reverse/watch-precsave.exp, since it's not
possible to use hw watchpoints in restored recordings anyways.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21969
Approved-by: Guinevere Larsen <blarsen@redhat.com>
|
|
After this commit:
commit 33ae45434d0ab1f7de365b9140ad4e4ffc34b8a2
Date: Mon Dec 4 14:23:17 2023 +0000
gdb: Enable early init of thread pool size
I am now seeing this assert from libstdc++:
/usr/include/c++/9/bits/stl_algo.h:3715: constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&) [with _Tp = int]: Assertion '!(__hi < __lo)' failed.
This may only be visible because I compile with:
-D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1
but I haven't checked. The issue the assert is highlighting is real,
and is caused by this block of code:
if (n_threads < 0)
{
const int hardware_threads = std::thread::hardware_concurrency ();
/* Testing in #29959 indicates that parallel efficiency drops between
n_threads=5 to 8. Therefore, clamp the default value to 8 to avoid an
excessive number of threads in the pool on many-core systems. */
const int throttle = 8;
n_threads = std::clamp (hardware_threads, hardware_threads, throttle);
}
The arguments to std::clamp are VALUE, LOW, HIGH, but in the above, if
we have more than 8 hardware threads available the LOW will be greater
than the HIGH, which is triggering the assert I see above.
I believe std::clamp is the wrong tool to use here. Instead std::min
would be a better choice; we want the smaller value of
HARDWARE_THREADS or THROTTLE. If h/w threads is 2, then we want 2,
but if h/w threads is 16 we want 8, this is what std::min gives us.
After this commit, I no longer see the assert.
|
|
This reverts commit 1c04f72368c ("[gdb/symtab] Fix assert in set_length"), due
to a regression reported in PR29572, and implements a different fix for PR29453.
The fix is to not use the CU table in a .debug_names section to construct
all_units, but instead use create_all_units, and then verify the CU
table from .debug_names. This also fixes PR25969, so remove the KFAIL.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29572
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25969
|
