In gdb/python/py-tui.c we have code like this:
...
gdbpy_ref<> result (PyObject_CallMethod (m_window.get(), "hscroll",
"i", num_to_scroll, nullptr));
...
The nullptr is superfluous, the format string already indicates that there's
only one method argument.
OTOH, passing no method args does use a nullptr:
...
gdbpy_ref<> result (PyObject_CallMethod (m_window.get (), "render",
nullptr));
...
Furthermore, choosing the right format string chars can be tricky.
Add a typesafe wrapper around PyObject_CallMethod that hides these
details, such that we can use the more intuitive:
...
gdbpy_ref<> result (gdbpy_call_method (m_window.get(), "hscroll",
num_to_scroll));
...
and:
...
gdbpy_ref<> result (gdbpy_call_method (m_window.get (), "render"));
...
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom Tromey <tom@tromey.com>
Currently it's not possible to call user-defined function call
operators, at least not without specifying operator() directly:
```
(gdb) l 1
1 struct S {
2 int operator() (int x) { return x + 5; }
3 };
4
5 int main () {
6 S s;
7
8 return s(23);
9 }
(gdb) p s(10)
Invalid data type for function to be called.
(gdb) p s.operator()(10)
$1 = 15
```
This now looks if an user-defined call operator is available when
trying to 'call' a struct value, and calls it instead, making this
possible:
```
(gdb) p s(10)
$1 = 15
```
The change in operation::evaluate_funcall is to make sure the type
fields are only used for function types, only they use them as the
argument types.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12213
Approved-By: Tom Tromey <tom@tromey.com>
Add a new 'error_message' feature to the qSupported packet. When GDB
supports this feature then gdbserver is able to send
errors in the E.errtext format for the qRcmd and m packets.
Update qRcmd packet and m packets documentation as qRcmd newly
accepts errors in a E.errtext format.
Previously these two packets didn't support E.errtext style errors.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Convert 'set/show debug separate-debug-file' to the new debug scheme.
Though I'm not sure if we can really call it "new" any more!
Approved-By: Tom Tromey <tom@tromey.com>
While working on a later patch in this series, I noticed that GDB
would print the message:
Reading /path/to/file from remote target...
Even when /path/to/file doesn't exist on the remote target.
GDB does indeed try to open /path/to/file, but I'm not sure we really
need to tell the user unless we actually manage to open the file, and
plan to read content from it.
If we consider how GDB probes for separate debug files, we can attempt
to open multiple possible files, most of them will not exist. When we
are native debugging we don't bother telling the user about each file
we're checking for, we just announce any file we finally use.
I think it makes sense to do a similar thing for remote files.
So, in remote_target::remote_hostio_open(), I'd like to move the block
of code that prints the above message to after the open call has been
made, and we should only print the message if the open succeeds.
Now GDB only tells the user about files that we actually open and read
from the remote.
Approved-By: Tom Tromey <tom@tromey.com>
In build_id_to_bfd_suffix we look in each debug-file-directory for a
file matching the required build-id.
If we don't find one then we add the sysroot and perform the search
again.
However, the default sysroot is 'target:', and for a native target
this just means to search on the local machine. So by default, if the
debug information is not present, then we end up searching each
location twice.
I think we only need to perform the "with sysroot" check if either:
1. The sysroot is something other than 'target:'. If the user has
set it to '/some/directory' then we should check this sysroot. Or if
the user has set it to 'target:/some/other_directory', this is also
worth checking.
2. If the sysroot is 'target:', but the target's filesystem is not
local (i.e. the user is connected to a remote target), then we should
check using the sysroot as this will be looking on the remote
machine.
There's no tests for this as the whole point here is that I'm removing
duplicate work. No test regressions were seen though.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
In remote.c lives remote_target::remote_hostio_send_command(), which
is used to handle sending a fileio packet to the remote, and for
parsing the reply packet.
Some commands, e.g. open, pwrite, close, send some arguments to the
remote, and then get back a single integer return value.
Other commands though, e.g. pread, readlink, fstat, send some
arguments and get back an integer return value and some additional
data. This additional data is called the attachment.
Except, we only get the attachment if the command completes
successfully. For example, calling readlink with a non existent path
will result in a return packet: 'F-1,2' with no attachment. This is
as expected.
Within remote_hostio_send_command we call remote_hostio_parse_result,
this parses the status code (-1 in our example above) and
then parses the errno value (2 in our example above).
Back in remote_hostio_parse_result we then hit this block:
/* Make sure we saw an attachment if and only if we expected one. */
if ((attachment_tmp == NULL && attachment != NULL)
|| (attachment_tmp != NULL && attachment == NULL))
{
*remote_errno = FILEIO_EINVAL;
return -1;
}
Which ensures that commands that expect an attachment, got an
attachment.
The problem is, we'll only get an attachment if the command
succeeded. If it didn't, then there is no attachment, and that is as
expected.
As remote_hostio_parse_result always sets the returned error number to
FILEIO_SUCCESS unless the packet contained an actual error
number (e.g. 2 in our example above), I suggest we should return early
if remote_hostio_parse_result indicates an error packet.
I ran into this issue while working on another patch. In that patch I
was checking the error code returned by a remote readlink call and
spotted that when I passed an invalid path I got EINVAL instead of
ENOENT. This patch fixes this issue.
Unfortunately the patch I was working on evolved, and my need to check
the error code went away, and so, right now, I have no way to reveal
this bug. But I think this is an obviously correct fix, and worth
merging even without a test.
Approved-By: Tom Tromey <tom@tromey.com>
The bitshift tests for opencl have these failures:
print /x (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8
print (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8
Apparently opencl doesn't have the 'signed' modifier for types, only
the 'unsigned' modifier.
Even 'char' is guaranteed to be signed if no modifier is used, so
this changes the casts to match this logic.
Approved-By: Tom Tromey <tom@tromey.com>
On systems where long has 32-bit size you get these failures:
print 1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff
print 1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff
print -1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff
print -1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff
Fixed by changing the number-of-bits variable to ULONGEST.
Approved-By: Tom Tromey <tom@tromey.com>
As seen in these test failures:
print -1 >> -1
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1
print -4 >> -2
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2
Fixed by restoring the logic from before the switch to gmp.
Approved-By: Tom Tromey <tom@tromey.com>
PR31590 shows that right shift of negative numbers doesn't work
correctly since GDB 14:
(gdb) p (-3) >> 1
$1 = -1
GDB 13 and earlier returned the correct value -2.
And there actually is one test that shows the failure:
print -1 >> 1
$84 = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1
The problem was introduced with the change to gmp functions in
commit 303a881f87.
It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which
always rounds toward zero, and the gmp docu says this:
For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple
bitwise right shifts.
For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift
treating n as two's complement the same as the bitwise logical functions
do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude.
So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it
does right shifts for both positive and negative numbers.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31590
Approved-By: Tom Tromey <tom@tromey.com>
Commit cdd4206647 unintentionally disabled all tests of bitshift.exp,
so it actually just does this:
Running /c/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/bitshift.exp ...
PASS: gdb.base/bitshift.exp: complete set language
=== gdb Summary ===
# of expected passes 1
It changed the 'continue' of unsupported languages to 'return', and
since ada is the first language and is unsupported, no tests were run.
This changes it back to 'continue', and the following patches fix
the regressions that were introduced since then unnoticed.
Approved-By: Tom Tromey <tom@tromey.com>
Under certain circumstances, a floating point exception in
target_read_string() can happen when the type has been obtained
by a call to stpy_lazy_string_elt_type(). In the latter function,
a call to check_typedef() has been forgotten. This makes
type->length = 0 in this case.
This call to wnoutrefresh is not useful. It's based on the
misunderstanding that wnoutrefresh somehow prevents display, whereas
actually what it does is copy from one curses buffer to another.
I'm working on a larger patch to clean up this area, but this
particular call can be removed immediately without consequence.
Approved-By: Andrew Burgess <aburgess@redhat.com>
On macOS sonoma, printing a string would only print the first
character. For instance, if there was a 'const char *s = "foobar"',
then the 'print s' command would print '$1 = "f"' rather than the
expected '$1 = "foobar"'.
It seems that this is due to Apple silently replacing the version
of libiconv they ship with the OS to one which silently fails to
handle the 'outbytesleft' parameter correctly when using 'wchar_t'
as a target encoding.
This specifically causes issues when using iterating through a
string as wchar_iterator does.
This bug is visible even if you build for an old version of macOS,
but then run on Sonoma. Therefore this fix in the code applies
generally to macOS, and not specific to building on Sonoma. Building
for an older version and expecting forwards compatibility is a
common situation on macOS.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31853
This patch renames global_symbol_searcher::filenames and makes it
private, adding a new method to append a filename to the vector. This
also cleans up memory management here, removing an alloca from rbreak,
and removing a somewhat ugly SCOPE_EXIT from the Python code, in favor
of having global_symbol_searcher manage the memory itself.
Regression tested on x86-64 Fedora 38.
If in gdb/python/python-internal.h, we pretend to have a platform that doesn't
support long long:
...
-#ifdef HAVE_LONG_LONG
+#if 0
...
I get on arm-linux:
...
(gdb) placement_candidate()
disassemble test^M
Dump of assembler code for function test:^M
0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M
0x004004dc <+4>: Python Exception <class 'ValueError'>: \
Buffer returned from read_memory is sized 0 instead of the expected 4^M
^M
unknown disassembler error (error = -1)^M
(gdb) FAIL: $exp: memory source api: second disassembler pass
...
The problem is that gdb_py_longest is typedef-ed to long, but the
corresponding format character GDB_PY_LL_ARG is defined to "L", meaning
"long long" [1].
Fix this by using "l", meaning long instead. Likewise for GDB_PY_LLU_ARG.
Tested on arm-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31845
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845
[1] https://docs.python.org/3/c-api/arg.html
After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop:
...
nop {0}
...
we run into:
...
disassemble test^M
Dump of assembler code for function test:^M
0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M
0x004004dc <+4>: add r11, sp, #0^M
0x004004e0 <+8>: nop {0}^M
=> 0x004004e4 <+12>: Python Exception <class 'ValueError'>: Buffer \
returned from read_memory is sized 0 instead of the expected 4^M
^M
unknown disassembler error (error = -1)^M
(gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test
...
This is caused by this code in gdbpy_disassembler::read_memory_func:
...
gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj,
"read_memory",
"KL", len, offset));
...
where len has type "unsigned int", while "K" means "unsigned long long" [1].
Fix this by using "I" instead, meaning "unsigned int".
Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means
"long long".
Fix this by using type gdb_py_longest for offset, in combination with format
character "GDB_PY_LL_ARG". Likewise in disasmpy_info_read_memory.
Tested on arm-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31845
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845
[1] https://docs.python.org/3/c-api/arg.html
Starting with python 3.6, support for platforms without long long support
has been removed [1].
HAVE_LONG_LONG and PY_LONG_LONG are still defined, but only for compatibility,
so stop relying on them.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://github.com/python/cpython/issues/72148
Commit 9102a6c15c ("gdb/tui: cleanup includes") broke
gdb.python/tui-window.exp on Linux:
Running /data/vries/gdb/src/gdb/testsuite/gdb.python/tui-window.exp ...
WARNING: timeout in accept_gdb_output
WARNING: timeout in accept_gdb_output
FAIL: gdb.python/tui-window.exp: Window was updated
and caused a build failure on AIX:
CXX tui/tui-win.o
tui/tui-win.c: In function 'void tui_sigwinch_handler(int)':
tui/tui-win.c:532:3: error: 'mark_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'?
532 | mark_async_signal_handler (tui_sigwinch_token);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| async_signal_handler
tui/tui-win.c: At global scope:
tui/tui-win.c:538:1: error: variable or field 'tui_async_resize_screen' declared void
538 | tui_async_resize_screen (gdb_client_data arg)
| ^~~~~~~~~~~~~~~~~~~~~~~
tui/tui-win.c:538:26: error: 'gdb_client_data' was not declared in this scope
538 | tui_async_resize_screen (gdb_client_data arg)
| ^~~~~~~~~~~~~~~
tui/tui-win.c: In function 'void tui_initialize_win()':
tui/tui-win.c:579:36: error: 'tui_async_resize_screen' was not declared in this scope
579 | = create_async_signal_handler (tui_async_resize_screen, NULL,
| ^~~~~~~~~~~~~~~~~~~~~~~
tui/tui-win.c:579:7: error: 'create_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'?
579 | = create_async_signal_handler (tui_async_resize_screen, NULL,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| async_signal_handler
gmake: *** [Makefile:1947: tui/tui-win.o] Error 1
On Linux, the removal of the signal.h include causes the `#ifdef
SIGWINCH` sections to become inactive. The code builds, but then the
TUI fails to react to terminal size changes. When we add back the
inclusion of signal.h, then we see the same build error as on AIX.
On AIX, I suppose that the SIGWINCH define is still seen by some other
transitive include.
When I go back to before 9102a6c15c, I don't see async-event.h and
signal.h being marked as unneeded by clangd, so I'm not sure why I
removed them in the first place... I'll be more careful in the future
(files with #ifdef/#ifndef can be tricky w.r.t. determining necessary
includes).
So, re-add the inclusion of signal.h and async-event.h
Change-Id: I3ed385c2dc1726ade2118a5186ea7cccffd12635
Reported-By: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
Reported-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31865
In test-case gdb.mi/mi-var-child-f.exp, we have:
...
mi_gdb_test "-gdb-set auto-solib-add off" "\\^done"
mi_runto prog_array
mi_gdb_test "nosharedlibrary" ".*\\^done"
...
This was added to avoid a name clash between the array variable as defined in
gdb.mi/array.f90 and debug info in shared libraries, and used in other places
in the testsuite.
The same workaround is also used to ignore symbols from shared libraries when
excercising for instance a command that prints all symbols.
However, this approach can cause problems for targets like arm that require
symbol info for some libraries like ld.so and libc to fully function.
While absense of debug info for shared libraries should be handled gracefully
(which does need fixing, see PR31817), failure to do so should not result
in failures in unrelated test-cases.
Fix this by removing "set auto-solib-add off".
This ensures that we don't run into PR31817, while the presence of
nosharedlibrary still ensures that in the rest of the test-case we're not
bothered by shared library symbols.
Likewise in other test-cases.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Tested on arm-linux.
I believe that the get_exec_file function is unnecessary, and the code
can be simplified if we remove it.
Consider for instance when you "run" a program on Linux with native
debugging.
1. run_command_1 obtains the executable file from
`current_program_space->exec_filename ()`
2. it passes it to `run_target->create_inferior()`, which is
`inf_ptrace_target::create_inferior()` in this case, which then
passes it to `fork_inferior()`
3. `fork_inferior()` then has a fallback, where if the passed exec file
is nullptr, it gets its from `get_exec_file()`.
4. `get_exec_file()` returns `current_program_space->exec_filename ()`
- just like the things we started with - or errors out if the
current program space doesn't have a specified executable.
If there's no exec filename passed in step 1, there's not going to be
any in step 4, so it seems pointless to call `get_exec_file()`, we could
just error out when `exec_file` is nullptr. But we can't error out
directly in `fork_inferior()`, since the error is GDB-specific, and that
function is shared with GDBserver.
Speaking of GDBserver, all code paths that lead to `fork_inferior()`
provide a non-nullptr exec file.
Therefore, to simplify things:
- Make `fork_inferior()` assume that the passed exec file is not
nullptr, don't call `get_exec_file()`
- Change some targets (darwin-nat, go32-nat, gnu-nat, inf-ptrace,
nto-procfs, procfs) to error out when the exec file passed to their
create_inferior method is nullptr. Some targets are fine with a
nullptr exec file, so we can't check that in `run_command_1()`.
- Add the `no_executable_specified_error()` function, which re-uses the
error message that `get_exec_file()` had.
- Change some targets (go32-nat, nto-procfs) to not call
`get_exec_file()`, since it's pointless for the same reason as in the
example above, if it returns, it's going the be the same value as the
`exec_file` parameter. Just rely on `exec_file`.
- Remove the final use of `get_exec_file()`, in `load_command()`.
- Remove the `get_exec_file()` implementations in GDB and GDBserver and
remove the shared declaration.
Change-Id: I601c16498e455f7baa1f111a179da2f6c913baa3
Approved-By: Tom Tromey <tom@tromey.com>
`get_exec_file()` never returns nullptr, so remove some dead code that
check for a nullptr return.
Change-Id: I9eff2a013d602588aaf4477a22cf45f2bc417c6a
Approved-By: Tom Tromey <tom@tromey.com>
Calls of `get_exec_file (0)` are equivalent to just getting the exec
filename from the current program space. I'm looking to remove
`get_exec_file`, so replace these uses with
`current_program_space->exec_filename ()`.
Remove the `err` parameter of `get_exec_wrapper` since all the calls
that remain pass 1, meaning to error out if no executable is specified.
Change-Id: I7729ea4c7f03dbb046211cc5aa3858ab3a551965
Approved-By: Tom Tromey <tom@tromey.com>
Just like the title says... I think this makes things a bit clearer, for
instance where the exec filename is set. It also makes the read call
sites a bit nicer, avoiding the `.get ()`.
Change-Id: If8b58ae8f6270c8a34b868f6ca06128c6671ea3c
Approved-By: Tom Tromey <tom@tromey.com>
Remove includes reported as unused by clangd. Then, add any includes
necessary to get rid of errors (includes possibly relying on previous
includes)..
I didn't remove the includes of gdb-safe-ctypes.h, because it appears to
do some some preprocessor magic, redefining standard macros. I'm afraid
that removing these includes could change the behavior unintentionally.
Change-Id: I4c5b652355c3bbce022fe0d447a72dc4e1d17d34
Approved-By: Tom Tromey <tom@tromey.com>
It seems like gdb_curses.h is included whenever we want to access
ncurses functionality, instead of including directly ncurses.h. As a
result, clangd often erroneously shows that gdb_curses.h inclusions are
unused.
By adding those pragmas, clangd (and the include-what-you-use tool)
understands that gdb_curses.h is a valid provider for whatever these
ncurses.h files provide.
Change-Id: Ia8acd761dae1577f7151d5fb558f35514b4e4ea2
Approved-By: Tom Tromey <tom@tromey.com>
Change the `TUI_*` macros to access known windows to functions. Define
them in their respective files, because trying to define them in
tui-data.h would end up causing include cycles.
This makes static analysis (detection of unused include files in this
case) more accurate, and I think in general we should avoid hiding
code behind macros if not necessary.
Change-Id: I1e38cee843984c48ab34030b19dac0d726f851af
Approved-By: Tom Tromey <tom@tromey.com>
Test behaviour of watchpoints triggered by MOPS instructions. This test
is similar to gdb.base/memops-watchpoint.exp, but specifically for MOPS
instructions rather than whatever instructions are used in the libc's
implementation of memset/memcpy/memmove.
There's a separate watched variable for each set of instructions so that
the testcase can test whether GDB correctly identified the watchpoint
that triggered in each case.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
There are two kinds of MOPS instructions: set instructions and copy
instructions. Within each group there are variants with minor
differences in how they read or write to memory — e.g., non-temporal
read and/or write, unprivileged read and/or write and permutations of
those — but they work in the same way in terms of the registers and
regions of memory that they modify.
The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS
instructions are recorded and correctly reversed. Not all variants of the
copy and set instructions are tested, since there are many and the record
and replay target processes them in the same way.
PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
The AArch64 MOPS (Memory Operation) instructions provide a standardised
instruction sequence to perform a memset, memcpy or memmove. A sequence is
always composed of three instructions: a prologue instruction, a main
instruction and an epilogue instruction. As an illustration, here are the
implementations of these memory operations in glibc 2.39:
(gdb) disassemble/r
Dump of assembler code for function __memset_mops:
=> 0x0000fffff7e8d780 <+0>: d503201f nop
0x0000fffff7e8d784 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8d788 <+8>: 19c10443 setp [x3]!, x2!, x1
0x0000fffff7e8d78c <+12>: 19c14443 setm [x3]!, x2!, x1
0x0000fffff7e8d790 <+16>: 19c18443 sete [x3]!, x2!, x1
0x0000fffff7e8d794 <+20>: d65f03c0 ret
End of assembler dump.
(gdb) disassemble/r
Dump of assembler code for function __memcpy_mops:
=> 0x0000fffff7e8c580 <+0>: d503201f nop
0x0000fffff7e8c584 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8c588 <+8>: 19010443 cpyfp [x3]!, [x1]!, x2!
0x0000fffff7e8c58c <+12>: 19410443 cpyfm [x3]!, [x1]!, x2!
0x0000fffff7e8c590 <+16>: 19810443 cpyfe [x3]!, [x1]!, x2!
0x0000fffff7e8c594 <+20>: d65f03c0 ret
End of assembler dump.
(gdb) disassemble/r
Dump of assembler code for function __memmove_mops:
=> 0x0000fffff7e8d180 <+0>: d503201f nop
0x0000fffff7e8d184 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8d188 <+8>: 1d010443 cpyp [x3]!, [x1]!, x2!
0x0000fffff7e8d18c <+12>: 1d410443 cpym [x3]!, [x1]!, x2!
0x0000fffff7e8d190 <+16>: 1d810443 cpye [x3]!, [x1]!, x2!
0x0000fffff7e8d194 <+20>: d65f03c0 ret
End of assembler dump.
The Arm Architecture Reference Manual says that "the prologue, main, and
epilogue instructions are expected to be run in succession and to appear
consecutively in memory". Therefore this patch disables displaced stepping
on them.
The testcase verifies that MOPS sequences are correctly single-stepped.
PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
In arm-linux-tdep.c, ARM_LINUX_JB_PC_EABI is defined as 9, but it's been 1
since glibc 2.20.
See glibc commit 80a56cc3ee ("ARM: Add SystemTap probes to longjmp and
setjmp.").
Update it, allowing us to run into the gdb/26967 kfail.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR arm/tdep
Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31089
When running test-case gdb.fortran/array-bounds.exp on arm-linux, we run into:
...
(gdb) print &foo^M
$1 = (PTR TO -> ( real(kind=4) (0:1) )) 0xfffef008^M
(gdb) FAIL: gdb.fortran/array-bounds.exp: print &foo
print &bar^M
$2 = (PTR TO -> ( real(kind=4) (-1:0) )) 0xfffef010^M
(gdb) FAIL: gdb.fortran/array-bounds.exp: print &bar
...
This is due to gcc PR debug/54934.
The test-case contains a kfail for this, which is only activated for
x86_64/i386.
Fix this by enabling the kfail for all ilp32 targets.
Also:
- change the kfail into an xfail, because gdb is not at fault here, and
- limit the xfail to the gfortran compiler.
Tested on arm-linux.
In commit:
commit 824083f34c
Date: Fri Apr 12 17:47:20 2024 +0100
gdb/doc: use silent-rules.mk in the Makefile
I rewrote the rules for building the man pages. While doing this I
accidentally switched from using MAN2POD5 to MAN2POD1 for generating
the file gdbinit.5.
Restore use of MAN2POD5 where appropriate.
Previously a "stepOut" request when in the outermost frame would result
in a sucessful response even though gdb internally would reject the
associated "finish" request, which means no stoppedEvent would ever be
sent back to the client. Thus the client would believe the inferior was
still running and as a consequence reject subsequent "next" and "stepIn"
requests from the user.
The solution is to execute the underlying finish command as a background
command, i.e. `finish &`. If we're in the outermost frame an exception
will be raised immediately, which we can now capture and report back to
the client as success=False so then the absence of a `stopped` event is
no longer a problem.
We also make use of the `defer_stop_event` option to prevent a stop
event from reaching the client until the response has been sent.
Approved-By: Tom Tromey <tom@tromey.com>
This allows a request to specify that any gdb exception raised in
exec_and_log within the gdb thread to be propagated back to the DAP
thread (using the Canceller object as the orchestrator).
Approved-By: Tom Tromey <tom@tromey.com>
The existing `send_event_later()` method allows commands processed on
the DAP thread to queue an event for execution until after the response
has been sent to the client.
We now introduce a corresponding method for use by the gdb thread. This
method `send_event_maybe_later()` will queue the event just like
`send_event_later()`, but only if it has been configured to do so by a
new @request option `defer_stop_events`. As the name implies the
functionality is currently only used for handling stop events.
Approved-By: Tom Tromey <tom@tromey.com>
I noticed that the value returned by rust_llvm_version had a trailing
carriage return. I don't think this is causing any problems right
now, but looking at the code I don't think this was the desired
behaviour.
The current code runs 'rustc --version --verbose', splits the output
at each '\n' and then loops over every line looking for the line that
contains the LLVM version.
There are two problems here. First, at the end of each captured line
we have '\r\n', so when we split the lines on '\n', each of the lines
will still end with a '\r' character.
Second, though we loop over the lines, when we try to compare the line
contents we actually compare the unsplit full output. Luckily this
still finds the match, but this renders the loop over lines redundant.
This commit makes two fixes:
1. I use regsub to convert all '\r\n' sequences to '\n'; now when we
split on '\n' the lines will not end in '\r'.
2. Within the loop over lines block I now check the line contents
rather than the unsplit full output; now we capture a value
without a trailing '\r'.
There's only one test (gdb.rust/simple.exp) that uses
rust_llvm_version, and it doesn't care if there's a trailing '\r' or
not, so this change should make no difference there.
Approved-By: Tom Tromey <tom@tromey.com>
I spotted a few more places where we could apply filename styling in
remote.c and target.c. Other than the styling, there should be no
user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
A co-worker requested that the DAP code emit a scope for global
variables. It's not really practical to do this for all globals, but
it seemed reasonable to do this for globals coming from the frame's
compilation unit. For Ada in particular, this is convenient as it
exposes package-scoped variables.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
In subsequent patches, it's handy if gdb.Block is hashable, so it can
be stored in a set or a dictionary. However, doing this in a
straightforward way is not really possible, because a block isn't
truly immutable -- it can be invalidated. And, while this isn't a
real problem for my use case (in DAP the maps are only used during a
single stop), it seemed error-prone.
This patch instead takes the approach of using the gdb.Block's own
object identity to allow hashing. This seems fine because the
contents don't affect the hashing. In order for this to work, though,
the blocks have to be memoized -- two requests for the same block must
return the same object.
This also allows (actually, requires) the simplification of the
rich-compare method for blocks.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
I noticed a FIXME comment in the DAP code about adding a "source"
field to a scope. This is easy to implement; I don't know why I
didn't do this originally.
The bcache uses memcpy to make copies of the data passed to it. In
C++, this is only safe for trivially-copyable types.
This patch changes bcache to require this property, and slightly
changes the API to make it easier to use when copying a single object.
It also makes the new 'insert' template methods return the correct
type.
This patch changes some spots in psymtab.[ch] to use 'const'. This is
just preparation for a subsequent patch. Note that psymbols are
conceptually const, and since they were changed to be
objfile-indepdendent, they are truly never modified -- which is what
makes this patch reasonably short.
