Tom de Vries [Tue, 26 Mar 2024 16:32:09 +0000 (17:32 +0100)]
[gdb/testsuite] Fix valgrind tests on debian
On debian 12, I run into:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M
relaying data between gdb and process 618591^M
warning: remote target does not support file transfer, \
attempting to access files from local filesystem.^M
Reading symbols from /lib/ld-linux-aarch64.so.1...^M
(No debugging symbols found in /lib/ld-linux-aarch64.so.1)^M
0x000000000401a980 in ?? () from /lib/ld-linux-aarch64.so.1^M
(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb
...
The problem is that we're expecting to match either of these regexps:
...
set start_re1 " in \\.?_start "
set start_re2 "\\.?_start \\(\\) at "
...
but there are no dwarf or elf symbols present.
Fix this by also allowing:
...
set start_re3 "$::hex in \\?\\? \\(\\) from "
...
Tom Tromey [Tue, 13 Feb 2024 20:55:34 +0000 (13:55 -0700)]
Capture warnings when writing to the index cache
PR symtab/30837 points out a race that can occur when writing to the
index cache: a call to ada_encode can cause a warning, which is
forbidden on a worker thread.
This patch fixes the problem by arranging to capture any such
warnings.
This is v2 of the patch. It is rebased on top of some other changes
in the same area. v1 was here:
H.J. Lu [Thu, 6 Dec 2018 19:45:41 +0000 (11:45 -0800)]
Don't claim a fat IR object if no IR object should be claimed
When the linker sees an input object containing nothing but IR during
rescan, it should ignore it (LTO phase is over). But if the input object
is a fat IR object, which has non-IR code as well, it should be used to
resolve references as if it did not contain any IR at all. This patch
adds lto_type to bfd and linker avoids claiming a fat IR object if no IR
object should be claimed.
bfd/
PR ld/23935
* archive.c (_bfd_compute_and_write_armap): Check bfd_get_lto_type
instead of lto_slim_object.
* elflink.c (elf_link_add_object_symbols): Likewise.
* bfd.c (bfd_lto_object_type): New.
(bfd): Remove lto_slim_object and add lto_type.
(bfd_get_lto_type): New function.
* elf.c (lto_section): Removed.
(_bfd_elf_make_section_from_shdr): Don't set lto_slim_object.
* format.c: (lto_section): New.
(bfd_set_lto_type): New function.
(bfd_check_format_matches): Call bfd_set_lto_type.
* bfd-in2.h: Regenerated.
binutils/
PR ld/23935
* nm.c (display_rel_file): Check bfd_get_lto_type instead of
lto_slim_object.
ld/
PR ld/23935
* ldmain.c (add_archive_element): Don't claim a fat IR object if
no IR object should be claimed.
* testsuite/ld-plugin/lto.exp (pr20103): Adjust fat IR test.
Add PR ld/23935 test.
* testsuite/ld-plugin/pr23935a.c: New file.
* testsuite/ld-plugin/pr23935b.c: Likewise.
added some functions which are always defined, but their use is
guarded within various #ifdef blocks. As a result we were seeing
errors about defined, but unused, functions.
I've fixed this problem in this commit by wrapping the function
definitions within #ifdef blocks.
I'm a little worried that there might be too many #ifdef blocks within
this file, however, I'm going to commit this fix for now as this will
fix the build, then I'll think about if there's a better way to split
this file so we might avoid some of these #ifdef blocks.
a possible use of an uninitialised variable was introduced, the
'tdesc' variable in i386_linux_core_read_description might be read
without being written too if 'xcr0' was 0.
This is fixed in this commit. I've updated the function to follow the
same pattern as amd64_linux_core_read_description, if xcr0 is 0 then
we select a default xcr0 value and use that to select a tdesc.
Simon Marchi [Mon, 25 Mar 2024 18:27:59 +0000 (14:27 -0400)]
gdb: mark addrmap classes `final`
When building GDB with clang, I see:
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:95:2: error: delete called on non-final 'addrmap_mutable' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non
-abstract-non-virtual-dtor]
95 | delete __ptr;
| ^
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:396:4: note: in instantiation of member function 'std::default_delete<addrmap_mutable>::operator()' requested here
396 | get_deleter()(std::move(__ptr));
| ^
/home/smarchi/src/binutils-gdb/gdb/addrmap.c:422:14: note: in instantiation of member function 'std::unique_ptr<addrmap_mutable>::~unique_ptr' requested here
422 | auto map = std::make_unique<struct addrmap_mutable> ();
| ^
Fix that by making `addrmap_mutable` final, and `addrmap_fixed` too
while at it.
Change-Id: I03aa0b0907c8d0e3390ddbedeb77d73b19b2b526 Approved-By: Tom Tromey <tom@tromey.com>
gprofng: fix infinite recursion on calloc with multi-threaded applications
libcollector uses pthread_getspecific() and pthread_setspecific() to access
thread local memory. libcollector uses this memory to check that
interposed functions (like malloc, calloc or free) don't have recursion.
The first time we call calloc(), we call pthread_setspecific() to create
a thread-specific value.
On Ubuntu machine, pthread_setspecific() calls calloc(), and we cannot intercept
such recursion.
gcc supports thread-local storage. For example,
static __thread int reentrance = 0;
I rewrote code using this instead of pthread_setspecific().
gprofng/ChangeLog
2024-03-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/31460
* libcollector/heaptrace.c: Use the __thread variable to check for
* reentry. Clean up code.
Pedro Alves [Fri, 22 Mar 2024 19:38:39 +0000 (19:38 +0000)]
gdb/testsuite: Fix set_unbuffered_mode.o handling in parallel mode
Cygwin/MinGW testing links in a set_unbuffered_mode.o object to all
test programs. When running the testsuite in parallel mode, on
Cygwin, I noticed errors like:
ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot open '..../build/set_unbuffered_mode.o' for reading: No such file or directory
...
ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot stat '..../build/set_unbuffered_mode.o': No such file or directory
...
ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: skipping file '..../build/set_unbuffered_mode.o', as it was replaced while being copied
(Absolute paths elided above.)
The problem is that gdb_compile's unbuffered_mode_obj cache isn't
parallel safe. This is fixed in this commit.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I67a289473c14ce0603d4b0beb755b124588f18d2
Pedro Alves [Fri, 22 Mar 2024 19:28:55 +0000 (19:28 +0000)]
Fix windows_nat_target::fake_create_process ptid
While working on Windows non-stop mode, I managed to introduce a bug
that led to fake_create_process being called. That then resulted in
GDB crashes later on, because fake_create_process added a thread with
an incorrect ptid for this target. It is putting dwThreadId in the
tid field of the ptid instead of on the lwp field. This is fixed by
this patch.
Andrew Burgess [Wed, 6 Dec 2023 13:27:20 +0000 (13:27 +0000)]
bfd: make _bfd_section_size_insane part of the public API
If a BFD user is making use of a function like
bfd_get_section_contents to read a section into a pre-allocated
buffer, then that BFD user might also want to make use of
_bfd_section_size_insane prior to allocating the buffer they intend to
use in order to validate that the buffer size that plan to allocate is
sane.
This commit makes _bfd_section_size_insane public, by renaming it to
bfd_section_size_insane.
I've updated the existing uses within bfd/, I don't believe this
function is used outside of bfd/ currently.
One place that I plan to make use of this function is in
gdb/gdb_bfd.c, in the function gdb_bfd_get_full_section_contents.
This change isn't included in this commit, but will come later if/when
this has been merged into bfd.
There should be no change in behaviour after this commit.
bfd/
* bfd-in2.h (bfd_section_size_insane): Add declaration.
* compress.c (bfd_get_full_section_contents): Update for new name
of _bfd_section_size_insane.
(bfd_init_section_compress_status): Likewise.
* dwarf2.c (read_section): Likewise.
(_bfd_dwarf2_slurp_debug_info): Likewise.
* libbfd.h (_bfd_section_size_insane): Remove declaration.
* section.c (_bfd_section_size_insane): Rename to ...
(bfd_section_size_insane): ... this.
binutils/
* readelf.c (uncompress_section_contents): Update comment to
account for new name of _bfd_section_size_insane.
Andrew Burgess [Mon, 19 Feb 2024 10:53:54 +0000 (10:53 +0000)]
gdb: move more completion setup into completer.c
Move more setup of the readline global state relating to tab
completion into completer.c out of top.c.
Lots of the readline setup is done in init_main (top.c). This commit
moves those bits of initialisation that relate to completion, and
which are only set the one time, into completer.c. This does mean
that readline initialisation is now done in multiple locations, some
in init_main (top.c) and some in completer.c, but I think this is OK.
The work done in init_main is the general readline setup.
I think making static what can be made static, and having it all in
one file, makes things easier to reason about. So I'm OK with having
this split initialisation.
The only completion related thing which is still setup in top.c is
rl_completion_display_matches_hook. I've left this where it is for
now as rl_completion_display_matches_hook is also updated in the tui
code, and the display hook functions are not in completer.c anyway, so
moving this initialisation to completer.c would not allow anything
else to be made static.
There should be no user visible changes after this commit.
Andrew Burgess [Mon, 15 Jan 2024 13:44:34 +0000 (13:44 +0000)]
gdb: remove special case completion word handling for filenames
This commit removes some code which is special casing the filename
completion logic. The code in question relates to finding the
beginning of the completion word and was first introduced, or modified
into its existing form in commit 7830cf6fb9571c3357b1a0 (from 2001).
The code being removed moved the start of the completion word backward
until a character in gdb_completer_file_name_break_characters was
found, or until we reached the end of the actual command.
However, I doubt that this is needed any more. The filename completer
has a corresponding filename_completer_handle_brkchars function which
provides gdb_completer_file_name_break_characters as the word break
characters to readline, and also sets rl_completer_quote_characters.
As such, I would expect readline to be able to correctly find the
start of the completion word.
There is one change which I've needed to make as a consequence of
removing the above code, and I think this is a bug fix.
In complete_line_internal_normal_command we initialised temporary
variable P to the CMD_ARGS; this is the complete text after the
command name. Meanwhile, complete_line_internal_normal_command also
accepts an argument WORD, which is the completion word that readline
found for us.
In the code I removed P was updated, it was first set to WORD, and
then moved backwards to the "new" start of the completion word.
But notice, the default for P is the complete command argument text,
and only if we are performing filename completion do we modify P to be
the completion word.
We then passed P through to the actual commands completion function.
If we are doing anything other than filename completion then the value
of P passed is the complete argument text.
If we are doing filename completion then the value of P passed is the
completion word.
In filename_completer we get two arguments TEXT and WORD, the TEXT
argument is the value of P which is the "new" completion word, while
WORD is the completion word that readline calculated.
After simplifying complete_line_internal_normal_command, and the
temporary P is removed, we always pass the complete argument text into
TEXT, while WORD remains the completion word that readline found.
Previously in filename_completer we actually tried to generate
completions based on TEXT, which worked fine as TEXT actually
contained the completion word that we found in
complete_line_internal_normal_command. But I believe that we should
be fine to use the completion word that readline found, so I have
updated filename_completer to generate completions based on WORD.
If I'm correct, then I don't expect to see any user visible changes
after this commit.
Andrew Burgess [Tue, 16 Jan 2024 16:08:12 +0000 (16:08 +0000)]
gdb: remove some dead code from completer.c
In completer.c there is some code that is surrounded with '#if 0',
this code:
#if 0
/* There is no way to do this just long enough to affect quote
inserting without also affecting the next completion. This
should be fixed in readline. FIXME. */
/* Ensure that readline does the right thing
with respect to inserting quotes. */
rl_completer_word_break_characters = "";
#endif
This code, in some form, and always defined out, has been around since
the original import of GDB. Though the comment hints at what the
problem might be, it's not really clear what the issue is. And
completion within GDB has moved on a long way since this code was
written ... but not used.
I'm proposing that we just remove this code.
If/when a problem comes up then we can look at how to solve it. Maybe
this code would be the answer ... but also, I suspect, given all the
changes ... maybe not. I'm not sure carrying around this code for
another 20+ years adds much value.
There should be no user visible changes after this commit.
Andrew Burgess [Tue, 16 Jan 2024 12:21:52 +0000 (12:21 +0000)]
gdb: allow double quotes for quoting filenames
Currently GDB only supports using single quotes for quoting things,
the reason for this, as explained in completer.c (next to the variable
gdb_completer_expression_quote_characters) is that double quoted
strings need to be treated differently by the C expression parser.
But for filenames I don't believe this restriction holds. The file
names as passed to things like the 'file' command are not passing
through the C expression parser, so it seems like we should be fine to
allow double quotes for quoting in this case.
And so, this commit extends GDB to allow double quotes for quoting
filenames. Maybe in future we might be able to allow double quote
quoting in additional places, but this seems enough for now.
The testing has been extended to cover double quotes in addition to
the existing single quote testing.
This change does a number of things:
1. Set rl_completer_quote_characters in filename_completer and
filename_completer_handle_brkchars, this overrides the default which
is set in complete_line_internal_1,
2. In advance_to_completion_word we now take a set of quote
characters as a parameter, the two callers
advance_to_expression_complete_word_point and
advance_to_filename_complete_word_point now pass in the required set
of quote characters,
3. In completion_find_completion_word we now use the currently active
set of quote characters, this means we'll use
gdb_completer_expression_quote_characters or
gdb_completer_file_name_quote_characters depending on what type of
things we are completing.
Andrew Burgess [Mon, 15 Jan 2024 13:25:01 +0000 (13:25 +0000)]
gdb: fix bug where quote characters would become nullptr
In gdb_completion_word_break_characters_throw, after calling
complete_line_internal, if the completion function chose to use a
custom word point then we set rl_completer_quote_characters to NULL.
However, nowhere do we set rl_completer_quote_characters back to its
default value, which is setup in init_main (top.c).
An example of something that uses a custom word point for its
completion is 'thread apply all ...'.
An example of something that relies on rl_completer_quote_characters
would be completion of a quoted filename that contains white space.
Consider this shell and GDB session. The <TAB> markers indicate where
I've used tab to trigger completion:
$ mkdir /tmp/aaa\ bbb
$ touch /tmp/aaa\ bbb/xx\ 11
$ touch /tmp/aaa\ bbb/xx\ 22
$ gdb -q
(gdb) file '/tmp/aaa bbb/xx<TAB><TAB>
xx 11 xx 22
(gdb) thread apply all hel<TAB>
(gdb) thread apply all help
(gdb) file '/tmp/aaa bbb/xx<TAB><TAB>
First I create a directory structure which uses white space within
file and directory names. Then within GDB I use the 'file' command
and use a single quote to quote the filename. When I tab complete GDB
correctly offers the two files within the directory '/tmp/aaa bbb/'.
This works because rl_completer_quote_characters contains the single
quote, and so readline knows that it is trying to complete the string
that starts after the single quote: /tmp/aaa bbb/xx
Next I invoke the completer for the 'thread apply all' command, to do
this I type 'thread apply all hel' and hit tab, this expands to the
one completion 'thread apply all help'. We can run this command or
not, it doesn't matter (there are no threads, so we'll get no output).
Now I repeat the original 'file' completion. This time though I don't
get offered any completions.
The reason is that the 'thread apply all' completer set
rl_completer_quote_characters to nullptr. Now, when readline tries to
figure out the word to complete it doesn't see the single quote as the
start of a quoted word, so instead readline falls back to the word
break characters, and in this case spots the white space. As a result
readline tries to complete the string 'bbb/xx' which obviously doesn't
have any completions.
By setting rl_completer_quote_characters each time completion is
invoked this problem is resolved and the second 'file' command
completes as expected.
I've extended gdb.base/filename-completion.exp to also test with
quoted filenames, and added a 'thread apply all' completion at the
start to expose this bug.
As setting of rl_completer_quote_characters is now all done in the
completer.c file the function get_gdb_completer_quote_characters()
could be made static. However, as this function is only used one time
to initialise rl_completer_quote_characters, I've instead just deleted
get_gdb_completer_quote_characters() and used
gdb_completer_quote_characters directly.
Andrew Burgess [Mon, 15 Jan 2024 15:55:28 +0000 (15:55 +0000)]
gdb: remove skip_quoted and skip_quoted_chars
The function skip_quoted_chars (completer.c) is only used by
skip_quoted (also completer.c), so could be made static. The function
skip_quoted just calls directly to skip_quoted_chars but fills in some
default arguments.
The function skip_quoted is only used by the Pascal expression parser,
and is only used in one place.
The skip_quoted_chars function skips a single string; it either looks
for a string between matching quotes, or for a string up to a word
break character.
However, given how the Pascal expression parser calls this function,
we know that the first character will always be a single quote, in
which case skip_quoted_chars will looks for a string between matching
single quotes.
The skip_quoted_chars doesn't do any escaped character handling, it
will just stop at the next single quote character.
In this commit I propose to remove skip_quoted and skip_quoted_chars,
and replace these with a smaller function pascal_skip_string which
I've placed in p-exp.y. This new function only skips a string between
matching single quotes, which is exactly the use case that we need.
The benefit of this change is to remove (some) code duplication. It
feels like skip_quoted is similar in some ways to
extract_string_maybe_quoted, however, there are some differences;
skip_quoted uses the quotes and word break characters from the
completion engine which extract_string_maybe_quoted does not.
However, I'm currently working on improving filename completion, one
part of this is that I'm looking at allowing filenames to be quoted
with single or double quotes, while the default string quoting in
GDB (for expressions) can only use single quotes. If I do end up
allowing single and double quotes in some cases, but we retain the
single quotes only for expressions then skip_quoted starts to become a
problem, should it accept both quote types, or only one?
But given how skip_quoted is used, I can avoid worrying about this by
simply removing skip_quoted.
The Pascal tests do still pass. The code that called skip_quoted is
called at least once in the Pascal tests (adding an abort() call
causes gdb.pascal/types.exp to fail), but I doubt the testing is
extensive. Not sure how widely used GDB for Pascal actually is
though.
Andrew Burgess [Wed, 18 Jan 2023 10:17:57 +0000 (10:17 +0000)]
gdb: introduce unwind-on-timeout setting
Now that inferior function calls can timeout (see the recent
introduction of direct-call-timeout and indirect-call-timeout), this
commit adds a new setting unwind-on-timeout.
This new setting is just like the existing unwindonsignal and
unwind-on-terminating-exception, but the new setting will cause GDB to
unwind the stack if an inferior function call times out.
The existing inferior function call timeout tests have been updated to
cover the new setting.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Tested-By: Luis Machado <luis.machado@arm.com> Tested-By: Keith Seitz <keiths@redhat.com>
Andrew Burgess [Fri, 7 Oct 2022 11:39:07 +0000 (12:39 +0100)]
gdb: add timeouts for inferior function calls
In the previous commits I have been working on improving inferior
function call support. One thing that worries me about using inferior
function calls from a conditional breakpoint is: what happens if the
inferior function call fails?
If the failure is obvious, e.g. the thread performing the call
crashes, or hits a breakpoint, then this case is already well handled,
and the error is reported to the user.
But what if the thread performing the inferior call just deadlocks?
If the user made the call from a 'print' or 'call' command, then the
user might have some expectation of when the function call should
complete, and, when this time limit is exceeded, the user
will (hopefully) interrupt GDB and regain control of the debug
session.
But, when the inferior function call is from a breakpoint condition it
is much harder to understand that GDB is deadlocked within an inferior
call. Maybe the breakpoint hasn't been hit yet? Or maybe the
condition was always false? Or maybe GDB is deadlocked in an inferior
call? The only way to know for sure is for the user to periodically
interrupt the inferior, check on the state of all the threads, and
then continue.
Additionally, the focus of the previous commit was inferior function
calls, from a conditional breakpoint, in a multi-threaded inferior.
This opens up a whole new set of potential failure conditions. For
example, what if the function called relies on interaction with some
other thread, and the other thread crashes? Or hits a breakpoint?
Given how inferior function calls work (in a synchronous manner), a
stop event in some other thread is going to be ignored while the
inferior function call is being executed as part of a breakpoint
condition, and this means that GDB could get stuck waiting for the
original condition thread, which will now never complete.
In this commit I propose a solution to this problem. A timeout. For
targets that support async-mode we can install an event-loop timer
before starting the inferior function call. When the timer expires we
will stop the thread performing the inferior function call. With this
mechanism in place a user can be sure that any inferior call they make
will either complete, or timeout eventually.
Adding a timer like this is obviously a change in behaviour for the
more common 'call' and 'print' uses of inferior function calls, so, in
this patch, I propose having two different timers. One I call the
'direct-call-timeout', which is used for 'call' and 'print' commands.
This timeout is by default set to unlimited, which, not surprisingly,
means there is no timeout in place.
A second timer, which I've called 'indirect-call-timeout', is used for
inferior function calls from breakpoint conditions. This timeout has
a default value of 30 seconds. This is a reasonably long time to
wait, and hopefully should be enough in most cases to allow the
inferior call to complete. An inferior call that takes more than 30
seconds, which is installed on a breakpoint condition is really going
to slow down the debug session, so hopefully this is not a common use
case.
The user is, of course, free to reduce, or increase the timeout value,
and can always use Ctrl-c to interrupt an inferior function call, but
this timeout will ensure that GDB will stop at some point.
The new commands added by this commit are:
set direct-call-timeout SECONDS
show direct-call-timeout
set indirect-call-timeout SECONDS
show indirect-call-timeout
These new timeouts do depend on async-mode, so, if async-mode is
disabled (maint set target-async off), or not supported (e.g. target
sim), then the timeout is treated as unlimited (that is, no timeout is
set).
For targets that "fake" non-async mode, e.g. Linux native, where
non-async mode is really just async mode, but then we park the target
in a sissuspend, we could easily fix things so that the timeouts still
work, however, for targets that really are not async aware, like the
simulator, fixing things so that timeouts work correctly would be a
much bigger task - that effort would be better spent just making the
target async-aware. And so, I'm happy for now that this feature will
only work on async targets.
The two new show commands will display slightly different text if the
current target is a non-async target, which should allow users to
understand what's going on.
There's a somewhat random test adjustment needed in gdb.base/help.exp,
the test uses a regexp with the apropos command, and expects to find a
single result. Turns out the new settings I added also matched the
regexp, which broke the test. I've updated the regexp a little to
exclude my new settings.
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Tested-By: Luis Machado <luis.machado@arm.com> Tested-By: Keith Seitz <keiths@redhat.com>
Andrew Burgess [Fri, 9 Oct 2020 11:27:13 +0000 (13:27 +0200)]
gdb: fix b/p conditions with infcalls in multi-threaded inferiors
This commit fixes bug PR 28942, that is, creating a conditional
breakpoint in a multi-threaded inferior, where the breakpoint
condition includes an inferior function call.
Currently, when a user tries to create such a breakpoint, then GDB
will fail with:
(gdb) break infcall-from-bp-cond-single.c:61 if (return_true ())
Breakpoint 2 at 0x4011fa: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-single.c, line 61.
(gdb) continue
Continuing.
[New Thread 0x7ffff7c5d700 (LWP 2460150)]
[New Thread 0x7ffff745c700 (LWP 2460151)]
[New Thread 0x7ffff6c5b700 (LWP 2460152)]
[New Thread 0x7ffff645a700 (LWP 2460153)]
[New Thread 0x7ffff5c59700 (LWP 2460154)]
Error in testing breakpoint condition:
Couldn't get registers: No such process.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(return_true) will be abandoned.
When the function is done executing, GDB will silently stop.
Selected thread is running.
(gdb)
Or, in some cases, like this:
(gdb) break infcall-from-bp-cond-simple.c:56 if (is_matching_tid (arg, 1))
Breakpoint 2 at 0x401194: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c, line 56.
(gdb) continue
Continuing.
[New Thread 0x7ffff7c5d700 (LWP 2461106)]
[New Thread 0x7ffff745c700 (LWP 2461107)]
../../src.release/gdb/nat/x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The precise error depends on the exact thread state; so there's race
conditions depending on which threads have fully started, and which
have not. But the underlying problem is always the same; when GDB
tries to execute the inferior function call from within the breakpoint
condition, GDB will, incorrectly, try to resume threads that are
already running - GDB doesn't realise that some threads might already
be running.
The solution proposed in this patch requires an additional member
variable thread_info::in_cond_eval. This flag is set to true (in
breakpoint.c) when GDB is evaluating a breakpoint condition.
In user_visible_resume_ptid (infrun.c), when the in_cond_eval flag is
true, then GDB will only try to resume the current thread, that is,
the thread for which the breakpoint condition is being evaluated.
This solves the problem of GDB trying to resume threads that are
already running.
The next problem is that inferior function calls are assumed to be
synchronous, that is, GDB doesn't expect to start an inferior function
call in thread #1, then receive a stop from thread #2 for some other,
unrelated reason. To prevent GDB responding to an event from another
thread, we update fetch_inferior_event and do_target_wait in infrun.c,
so that, when an inferior function call (on behalf of a breakpoint
condition) is in progress, we only wait for events from the current
thread (the one evaluating the condition).
In do_target_wait I had to change the inferior_matches lambda
function, which is used to select which inferior to wait on.
Previously the logic was this:
This compares the pid of the inferior against the complete ptid we
want to wait on. Before this commit wait_ptid was only ever
minus_one_ptid (which is special, and means any process), and so every
inferior would match.
After this commit though wait_ptid might represent a specific thread
in a specific inferior. If we compare the pid of the inferior to a
specific ptid then these will not match. The fix is to compare
against the pid extracted from the wait_ptid, not against the complete
wait_ptid itself.
In fetch_inferior_event, after receiving the event, we only want to
stop all the other threads, and call inferior_event_handler with
INF_EXEC_COMPLETE, if we are not evaluating a conditional breakpoint.
If we are, then all the other threads should be left doing whatever
they were before. The inferior_event_handler call will be performed
once the breakpoint condition has finished being evaluated, and GDB
decides to stop or not.
The final problem that needs solving relates to GDB's commit-resume
mechanism, which allows GDB to collect resume requests into a single
packet in order to reduce traffic to a remote target.
The problem is that the commit-resume mechanism will not send any
resume requests for an inferior if there are already events pending on
the GDB side.
Imagine an inferior with two threads. Both threads hit a breakpoint,
maybe the same conditional breakpoint. At this point there are two
pending events, one for each thread.
GDB selects one of the events and spots that this is a conditional
breakpoint, GDB evaluates the condition.
The condition includes an inferior function call, so GDB sets up for
the call and resumes the one thread, the resume request is added to
the commit-resume queue.
When the commit-resume queue is committed GDB sees that there is a
pending event from another thread, and so doesn't send any resume
requests to the actual target, GDB is assuming that when we wait we
will select the event from the other thread.
However, as this is an inferior function call for a condition
evaluation, we will not select the event from the other thread, we
only care about events from the thread that is evaluating the
condition - and the resume for this thread was never sent to the
target.
And so, GDB hangs, waiting for an event from a thread that was never
fully resumed.
To fix this issue I have added the concept of "forcing" the
commit-resume queue. When enabling commit resume, if the force flag
is true, then any resumes will be committed to the target, even if
there are other threads with pending events.
A note on authorship: this patch was based on some work done by
Natalia Saiapova and Tankut Baris Aktemur from Intel[1]. I have made
some changes to their work in this version.
There was nothing wrong with the commit which I'm reverting here, but
it removed some functionality that will be needed for a later commit;
that is, the ability for GDB to ask for events from a specific ptid_t
via the do_target_wait function.
In a follow up commit, this functionality will be used to implement
inferior function calls in multi-threaded inferiors.
This is not a straight revert of the above commit. Reverting the
above commit replaces a 'nullptr' with 'NULL', I've gone in and
changed that, preserving the 'nullptr'.
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tested-By: Luis Machado <luis.machado@arm.com> Tested-By: Keith Seitz <keiths@redhat.com>
Andrew Burgess [Tue, 30 Jan 2024 15:37:23 +0000 (15:37 +0000)]
gdb/gdbserver: share x86/linux tdesc caching
This commit builds on the previous series of commits to share the
target description caching code between GDB and gdbserver for
x86/Linux targets.
The objective of this commit is to move the four functions (2 each of)
i386_linux_read_description and amd64_linux_read_description into
gdb/nat/x86-linux-tdesc.c and combine them so we have just a single
copy of each. Then both GDB and gdbserver will link against these
shared functions.
It is worth reading the description of the previous commit to see why
this merging is not as simple as it seems: on the gdbserver side we
actually have two users of these functions, gdbserver itself, and the
in process agent (IPA).
However, the previous commit streamlined the gdbserver code, and so
now it is simple to move the two functions along with all their
support functions from the gdbserver directory into the gdb/nat/
directory, and then GDB is fine to call these functions.
One small curiosity with this patch is the function
x86_linux_post_init_tdesc. On the gdbserver side the two functions
amd64_linux_read_description and i386_linux_read_description have some
functionality that is not present on the GDB side, that is some
additional configuration that is performed as each target description
is created to setup the expedited registers.
To support this I've added the function x86_linux_post_init_tdesc.
This function is called from the two *_linux_read_description
functions, but is implemented separately for GDB and gdbserver.
This does mean adding back some non-shared code when this whole series
has been about sharing code, but now the only non-shared bit is the
single line that is actually different between GDB and gdbserver, all
the rest, which is identical, is now shared.
I did need to add a new rule to the gdbserver Makefile, this is to
allow the nat/x86-linux-tdesc.c file to be compiled for the IPA.
Andrew Burgess [Wed, 31 Jan 2024 11:18:34 +0000 (11:18 +0000)]
gdbserver: update target description creation for x86/linux
This commit is part of a series which aims to share more of the target
description creation between GDB and gdbserver for x86/Linux.
After some refactoring, the previous commit actually started to share
some code, we added the shared x86_linux_tdesc_for_tid function into
nat/x86-linux-tdesc.c. However, this function still relies on
amd64_linux_read_description and i386_linux_read_description which are
implemented separately for both gdbserver and GDB. Given that at
their core, all these functions to is:
1. take an xcr0 value as input,
2. mask out some feature bits,
3. look for a cached pre-generated target description and return it
if found,
4. if no cached target description is found then call either
amd64_create_target_description or
i386_create_target_description to create a new target
description, which is then added to the cache. Return the newly
created target description.
The inner functions amd64_create_target_description and
i386_create_target_description are already shared between GDB and
gdbserver (in the gdb/arch/ directory), so the only thing that
the *_read_description functions really do is add the caching layer,
and it feels like this really could be shared.
However, we have a small problem.
On the GDB side we create target descriptions using a different set of
cpu features than on the gdbserver side! This means that for the
exact same target, we might get a different target description when
using native GDB vs using gdbserver. This surely feels like a
mistake, I would expect to get the same target description on each.
The table below shows the number of possible different target
descriptions that we can create on the GDB side vs on the gdbserver
side for each target type:
So in theory, all I want to do is move the GDB version
of *_read_description into the nat/ directory and have gdbserver use
that, then both GDB and gdbserver would be able to create any of the
possible target descriptions.
Unfortunately it's a little more complex than that due to the in
process agent (IPA).
When the IPA is in use, gdbserver sends a target description index to
the IPA, and the IPA uses this to find the correct target description
to use.
** START OF AN ASIDE **
Back in the day I suspect this approach made perfect sense. However
since this commit:
I think passing the index is now more trouble than its worth.
We used to pass the index, and then use that index to lookup which
target description to instantiate and use. However, the above commit
fixed an issue where we can't call malloc() within (certain parts of)
the IPA (apparently), so instead we now pre-compute _every_ possible
target description within the IPA. The index is now only used to
lookup which of the (many) pre-computed target descriptions to use.
It would (I think) have been easier all around if the IPA just
self-inspected, figured out its own xcr0 value, and used that to
create the one target description that is required. So long as the
xcr0 to target description code is shared (at compile time) with
gdbserver, then we can be sure that the IPA will derive the same
target description as gdbserver, and we would avoid all this index
passing business, which has made this commit so very, very painful.
** END OF AN ASIDE **
Currently then for x86/linux, gdbserver sends a number between 0 and 7
to the IPA, and the IPA uses this to create a target description.
However, I am proposing that gdbserver should now create one of (up
to) 64 different target descriptions for i386, so this 0 to 7 index
isn't going to be good enough any more (amd64 and x32 have slightly
fewer possible target descriptions, but still more than 8, so the
problem is the same).
For a while I wondered if I was going to have to try and find some
backward compatible solution for this mess. But after seeing how
lightly the IPA is actually documented, I wonder if it is not the case
that there is a tight coupling between a version of gdbserver and a
version of the IPA? At least I'm hoping so.
In this commit I have thrown out the old IPA target description index
numbering scheme, and switched to a completely new numbering scheme.
Instead of the index that is passed being arbitrary, the index is
instead calculated from the set of cpu features that are present on
the target. Within the IPA we can then reverse this logic to recreate
the xcr0 value based on the index, and from the xcr0 value we can
create the correct target description.
With the gdbserver to IPA numbering scheme issue resolved I have then
update the gdbserver versions of amd64_linux_read_description and
i386_linux_read_description so that they create target descriptions
using the same set of cpu features as GDB itself.
After this gdbserver should now always come up with the same target
description as GDB does on any x86/Linux target.
This commit does not introduce any new code sharing between GDB and
gdbserver as previous commits in this series does. Instead this
commit is all about bringing GDB and gdbserver into alignment
functionally so that the next commit can merge the GDB and gdbserver
versions of these functions.
I worried that there could be other paths that could result in an xcr0
value that has X86_XSTATE_MPX set in x32 mode. As everyone eventually
calls amd64_create_target_description to build their target
description, I figured we could assert in here that if X86_XSTATE_MPX
is set then we should not be an x32 target, this should uncover any
other bugs in this area.
I'm not currently able to build/run any x32 binaries, so I have no way
to test this.
Andrew Burgess [Thu, 25 Jan 2024 14:25:57 +0000 (14:25 +0000)]
gdb/gdbserver: share some code relating to target description creation
This commit is part of a series to share more of the x86 target
description creation code between GDB and gdbserver.
Unlike previous commits which were mostly refactoring, this commit is
the first that makes a real change, though that change should mostly
be for gdbserver; I've largely adopted the "GDB" way of doing things
for gdbserver, and this fixes a real gdbserver bug.
On a x86-64 Linux target, running the test:
gdb.server/connect-with-no-symbol-file.exp
results in two core files being created. Both of these core files are
from the inferior process, created after gdbserver has detached.
In this test a gdbserver process is started and then, after gdbserver
has started, but before GDB attaches, we either delete the inferior
executable, or change its permissions so it can't be read. Only after
doing this do we attempt to connect with GDB.
As GDB connects to gdbserver, gdbserver attempts to figure out the
target description so that it can send the description to GDB, this
involves a call to x86_linux_read_description.
In x86_linux_read_description one of the first things we do is try to
figure out if the process is 32-bit or 64-bit. To do this we look up
the executable via the thread-id, and then attempt to read the
architecture size from the executable. This isn't going to work if
the executable has been deleted, or is no longer readable.
And so, as we can't read the executable, we default to an i386 target
and use an i386 target description.
A consequence of using an i386 target description is that addresses
are assumed to be 32-bits. Here's an example session that shows the
problems this causes. This is run on an x86-64 machine, and the test
binary (xx.x) is a standard 64-bit x86-64 binary:
Notice the difference between the mappings reported via GDB and those
reported directly from the kernel via /proc/PID/maps, the addresses of
every mapping is clamped to 32-bits for GDB, while the kernel reports
real 64-bit addresses.
Notice also that the $pc value is a 32-bit value. It appears to be
within one of the mappings reported by GDB, but is outside any of the
mappings reported from the kernel.
And this is where the problem arises. When gdbserver detaches from
the inferior we pass the inferior the address from which it should
resume. Due to the 32/64 bit confusion we tell the inferior to resume
from the 32-bit $pc value, which is not within any valid mapping, and
so, as soon as the inferior resumes, it segfaults.
If we look at how GDB (not gdbserver) figures out its target
description then we see an interesting difference. GDB doesn't try to
read the executable. Instead GDB uses ptrace to query the thread's
state, and uses this to figure out the if the thread is 32 or 64 bit.
If we update gdbserver to do it the "GDB" way then the above problem
is resolved, gdbserver now sees the process as 64-bit, and when we
detach from the inferior we give it the correct 64-bit address, and
the inferior no longer segfaults.
Now, I could just update the gdbserver code, but better, I think, to
share one copy of the code between GDB and gdbserver in gdb/nat/.
That is what this commit does.
The cores of x86_linux_read_description from gdbserver and
x86_linux_nat_target::read_description from GDB are moved into a new
file gdb/nat/x86-linux-tdesc.c and combined into a single function
x86_linux_tdesc_for_tid which is called from each location.
This new function does things the GDB way, the only changes are to
allow for the sharing; we now have a callback function to call the
first time that the xcr0 state is read, this allows for GDB and
gdbserver to perform their own initialisation as needed, and
additionally, the new function takes a pointer for where to cache the
xcr0 value, this isn't needed for this commit, but will be useful in a
later commit where gdbserver will want to read this cached xcr0
value.
Another thing to note about this commit is how the functions
i386_linux_read_description and amd64_linux_read_description are
handled. For now I've left these function as implemented separately
in GDB and gdbserver. I've moved the declarations of these functions
into gdb/nat/x86-linux-tdesc.h, but the implementations are left as
separate.
A later commit in this series will make these functions shared too,
but doing this is not trivial, so I've left that for a separate
commit. Merging the declarations as I've done here ensures that
everyone implements the function to the same API, and once these
functions are shared (in a later commit) we'll want a shared
declaration anyway.
Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and
gdbserver.
This commit is part of a series that aims to share more of the x86
target description creation code between GDB and gdbserver. The
I386_LINUX_XSAVE_XCR0_OFFSET #define is used as part of the target
description creation, and I noticed that this constant is defined
separately for GDB and gdbserver.
This commit moves the definition into gdb/nat/x86-linux.h, which
allows the #define to be shared.
There should be no user visible changes after this commit.
Andrew Burgess [Sat, 27 Jan 2024 09:33:14 +0000 (09:33 +0000)]
gdbserver/x86: move no-xml code earlier in x86_linux_read_description
This commit is part of a series that aims to share more of the x86
target description reading/generation code between GDB and gdbserver.
There are a huge number of similarities between the code in
gdbserver's x86_linux_read_description function and GDB's
x86_linux_nat_target::read_description function, and it is this
similarity that I plan, in a later commit, to share between GDB and
gdbserver.
However, one thing that is different in x86_linux_read_description is
the code inside the '!use_xml' block. This is the code that handles
the case where gdbserver is not allowed to send an XML target
description back to GDB. In this case gdbserver uses some predefined,
fixed, target descriptions.
First, it's worth noting that I suspect this code is not tested any
more. I couldn't find anything in the testsuite that tries to disable
XML target description support. And the idea of having a single
"fixed" target description really doesn't work well when we think
about all the various x86 extensions that exist. Part of me would
like to rip out the no-xml support in gdbserver (at least for x86),
and if a GDB connects that doesn't support XML target descriptions,
gdbserver can just give an error and drop the connection. GDB has
supported XML target descriptions for 16 years now, I think it would
be reasonable for our shipped gdbserver to drop support for the old
way of doing things.
Anyway.... this commit doesn't do that.
What I did notice was that, over time, the '!use_xml' block appears to
have "drifted" within the x86_linux_read_description function; it's
now not the first check we do. Instead we make some ptrace calls and
return a target description generated based on the result of these
ptrace calls. Surely it only makes sense to generate variable target
descriptions if we can send these back to GDB?
So in this commit I propose to move the '!use_xml' block earlier in
the x86_linux_read_description function.
The benefit of this is that this leaves the later half of
x86_linux_read_description much more similar to the GDB function
x86_linux_nat_target::read_description and sets us up for potentially
sharing code between GDB and gdbserver in a later commit.
Andrew Burgess [Sat, 27 Jan 2024 09:15:35 +0000 (09:15 +0000)]
gdb/x86: move reading of cs and ds state into gdb/nat directory
This patch is part of a series that has the aim of making the code
that, for x86, reads the target description for a native process
shared between GDB and gdbserver.
Within GDB part of this process involves reading the cs and ds state
from the 'struct user_regs_struct' using a ptrace call.
This isn't done by gdbserver, which is part of the motivation for this
whole series; the approach gdbserver takes is inferior to the approach
GDB takes.
This commit moves the reading of cs and ds, which is used to figure
out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat
directory so that the code could be shared with gdbserver, but at this
point I'm not actually using the code in gdbserver, that will come
later.
As such there should be no user visible changes after this commit, GDB
continues to do things as it did before (reading cs/ds), while
gdbserver continues to use its own approach (which doesn't require
reading cs/ds).
Andrew Burgess [Thu, 25 Jan 2024 14:10:42 +0000 (14:10 +0000)]
gdbserver: convert have_ptrace_getregset to a tribool
Convert the have_ptrace_getregset global within gdbserver to a
tribool. This brings the flag into alignment with the corresponding
flag in GDB.
The gdbserver have_ptrace_getregset variable is already used as a
tribool, it just doesn't have the tribool type.
In a future commit I plan to share more code between GDB and
gdbserver, and having this variable be the same type in both code
bases will make the sharing much easier.
There should be no user visible changes after this commit.
Tom de Vries [Mon, 25 Mar 2024 14:28:35 +0000 (15:28 +0100)]
[gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with gcc <= 12
With gcc 13, test-case gdb.ada/tagged-lookup.exp passes for me, but with gcc
12, I get:
...
(gdb) set debug symtab-create 1^M
(gdb) print *the_local_var^M
...
$1 = (n => 2)^M
(gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded
...
The problem is that this fails:
...
-re -wrap ".* = \\\(n => $decimal\\\)" {
if {$found_pck + $found_pck2 == 1} {
pass $gdb_test_name
} else {
fail $gdb_test_name
}
...
because $found_pck == 0 and $found_pck2 == 0.
Indeed, with gcc 13 we have:
...
$ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%'
b~foo.adb
b~foo.adb
b~foo.adb
b~foo.ads
pck2.adb
pck2.adb
pck2.ads
pck2.adb
pck2.ads
...
and with gcc 12:
...
$ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%'
b~foo.adb
b~foo.adb
b~foo.adb
b~foo.ads
...
Fix this by checking for "$found_pck + $found_pck2 <= 1" instead.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31514
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31514
Tom de Vries [Mon, 25 Mar 2024 08:55:25 +0000 (09:55 +0100)]
[gdb/testsuite] Fix tdlabel_re references
Commit 467a34bb9e6 ("gdb tests: Allow for "LWP" or "process" in thread IDs
from info threads") introduces a new global variable tdlabel_re, but fails to
indicate it's global when used in procs in four test-cases.
John Baldwin [Sat, 23 Mar 2024 00:29:47 +0000 (17:29 -0700)]
gdb tests: Allow for "LWP" or "process" in thread IDs from info threads
Several tests assume that the first word after a thread ID in 'info
threads' output is "Thread". However, several targets use "LWP"
instead such as the FreeBSD and NetBSD native targets. The Linux
native target also uses "LWP" if libthread_db is not being used.
Targets that do not support threads use "process" as the first word
via normal_pid_to_str.
Add a tdlabel_re global variable as a regular-expression for a thread
label in `info threads' that matches either "process", "Thread", or
"LWP".
Some other tests in the tree don't require a specific word, and
some targets may use other first words (e.g. OpenBSD uses "thread"
and Ravenscar threads use "Ravenscar Thread").
Pedro Alves [Fri, 22 Mar 2024 19:46:59 +0000 (19:46 +0000)]
windows-nat: Remove SO_NAME_MAX_PATH_SIZE limit
There is no need to limit shared library path sizes to
SO_NAME_MAX_PATH_SIZE nowadays. windows_solib::name and
windows_solib::original_name are std::strings nowadays, and so are
solib::so_name and solib::so_original_name in the core solib code.
This commit reworks the code to remove that limit. This also fixes a
leak where we were not releasing 'rname' in the realpath branch if the
'rname' string was larger than SO_NAME_MAX_PATH_SIZE.
Note: I tested the cygwin_conv_path with a manual hack to force that
path, and then stepping through the code. You only get to that path
if Windows doesn't report an absolute path for ntdll.dll, and on my
machine (running Windows 10), it always does.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: I79e9862d5a7646eebfef7ab5b05b96318a7ca0c5
Pedro Alves [Fri, 22 Mar 2024 19:46:59 +0000 (19:46 +0000)]
Simplify windows-nat.c:windows_make_so #ifdefery
There are two separate #ifndef __CYGWIN__/#else/#endif sections in the
windows_make_so function with 3 lines of shared code separating them.
I find this makes the code harder to understand than necessary.
AFAICS, there is no reason those three shared lines need to be after
the first #ifdef block. There is no early return, nor are 'load_addr'
nor 'name' modified.
This commit moves that shared code to the top of the function, and
then combines the two #ifndef sections.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: If2678b52836b1c3134a5e9f9fdaee74448d8b7bc
Pedro Alves [Fri, 22 Mar 2024 19:46:58 +0000 (19:46 +0000)]
Remove SO_NAME_MAX_PATH_SIZE limit from core solib code
solib_map_sections errors out if the library file name is longer than
SO_NAME_MAX_PATH_SIZE.
solib::so_name and solib::so_original_name used to be arrays of
SO_NAME_MAX_PATH_SIZE size, so that check made sense then.
However, since commit 98107b0b17ac ("gdb: make
so_list::{so_original_name,so_name} std::strings") those fields are of
std::string type, so there's really no need for the limit.
This commit simply removes the length limit check.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: I2ec676b231cd18ae900c61c5caea461f47e989e6
This patch caused problems for some users when building gdb, because
it would cause 'guild' to be invoked with the wrong versin of guile.
On the whole it seems simpler to just back this out.
I'm checking this in to the binutils-gdb repository in the interest of
fixing the build for Andrew. No one has responded to the identical
patch sent to gcc-patches, but I will ping it there.
Tiezhu Yang [Fri, 22 Mar 2024 03:35:02 +0000 (11:35 +0800)]
gdb: LoongArch: Clean up loongarch_iterate_over_regset_sections()
Define a new variable gpsize as gprsize * LOONGARCH_LINUX_NUM_GREGSET
to replace the related code in the first cb(), and also make use of
tabs and spaces in indentation to force the proper alignment of code,
then remove the empty line at the end of the function.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Pedro Alves [Fri, 22 Mar 2024 12:31:29 +0000 (12:31 +0000)]
Teach GDB to generate sparse core files (PR corefiles/31494)
This commit teaches GDB's gcore command to generate sparse core files
(if supported by the filesystem).
To create a sparse file, all you have to do is skip writing zeros to
the file, instead lseek'ing-ahead over them.
The sparse logic is applied when writing the memory sections, as
that's where the bulk of the data and the zeros are.
The commit also tweaks gdb.base/bigcore.exp to make it exercise
gdb-generated cores in addition to kernel-generated cores. We
couldn't do that before, because GDB's gcore on that test's program
would generate a multi-GB non-sparse core (16GB on my system).
After this commit, gdb.base/bigcore.exp generates, when testing with
GDB's gcore, a much smaller core file, roughly in line with what the
kernel produces:
real sizes:
$ du --hu testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*
2.2M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb
2.0M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel
apparent sizes:
$ du --hu --apparent-size testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*
16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb
16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel
Time to generate the core also goes down significantly. On my machine, I get:
when writing to an SSD, from 21.0s, down to 8.0s
when writing to an HDD, from 31.0s, down to 8.5s
The changes to gdb.base/bigcore.exp are smaller than they look at
first sight. It's basically mostly refactoring -- moving most of the
code to a new procedure which takes as argument who should dump the
core, and then calling the procedure twice. I purposely did not
modernize any of the refactored code in this patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31494 Reviewed-By: Lancelot Six <lancelot.six@amd.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1
Jan Beulich [Fri, 22 Mar 2024 08:08:51 +0000 (09:08 +0100)]
x86: fix Solaris testsuite failures
For one 0afc614c9938 ("x86: Warn .insn instruction with length > 15
bytes") introduced a .insn use involving a slash; such tests need to
have --divide passed to gas.
And then 5bc71c2a6b8e ("x86-64: Add R_X86_64_CODE_6_GOTTPOFF") broke
BFD_RELOC_X86_64_GOTTPOFF conversion to R_X86_64_CODE_4_GOTTPOFF, by
adding respective code in a section guarded by
generate_relax_relocations (the case of that not being required there
was limited to 32-bit object files). Re-arrange that block of code to
check generate_relax_relocations later.
Tom Tromey [Mon, 26 Feb 2024 18:39:49 +0000 (11:39 -0700)]
Don't use virtual destructor in addrmap
The addrmap polymorphism is sort of "phony" in that there isn't really
code in the tree that can be presented with either type. I haven't
tried to fix this (though perhaps I may); but meanwhile it's handy for
the next patch if addrmap_fixed has a trivial destructor. This patch
achieves this by making the addrmap destructor non-virtual, and also
making it protected so that objects of any of these types cannot be
destroyed when only the base class is known.
Tom Tromey [Mon, 26 Feb 2024 17:46:31 +0000 (10:46 -0700)]
Use addrmap_fixed in a few spots
There are a few spots in the tree that use 'addrmap' where only an
addrmap_fixed will ever really be seen. This patch changes this code
to use the more specific type.
Orgad Shaneh [Sun, 3 Mar 2024 10:22:14 +0000 (12:22 +0200)]
sim/erc32: Rename EVENT_MAX -> MAX_EVENTS
EVENT_MAX is defined as 0x7FFFFFFF (INT_MAX) in winuser.h, so when
building on Windows, the value is overridden and compilation fails
because the array size of evbuf is too large.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28476 Approved-By: Tom Tromey <tom@tromey.com>
Tiezhu Yang [Thu, 21 Mar 2024 01:55:10 +0000 (09:55 +0800)]
gdb: syscalls: Add some tips for LoongArch xml files
In commit a08dc2aa004b (gdb: syscalls: Add loongarch-linux.xml.in),
it needs special handling when generating xml file. This should at
least be mentioned in the file comment rather than git log to help
the next person who regenerates this file understand what needs to
be done, suggested by Pedro Alves, thank you.
At the beginning, I only added the tips in loongarch-linux.xml.in,
after executing the command "make" to generate loongarch-linux.xml
from loongarch-linux.xml.in, it generates the same tips in the file
loongarch-linux.xml automatically, so update loongarch-linux.xml.in
and loongarch-linux.xml together.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-by: Pedro Alves <pedro@palves.net>
Hui Li [Thu, 21 Mar 2024 01:41:30 +0000 (09:41 +0800)]
gdb: LoongArch: Silence warning about core file of lsx and lasx
In loongarch_iterate_over_regset_sections(), the second and third arguments
of the iterate_over_regset_sections_cb callback function should be the regset
size which is regsize * regnum. Otherwise when execute:
make check-gdb TESTS="gdb.base/corefile.exp"
there exists the following failed log:
(gdb) core-file /home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile.core
[New LWP 531099]
warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file.
warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file.
Core was generated by `/home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile'.
Program terminated with signal SIGABRT, Aborted.
warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file.
warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file.
#0 0x00007ffff3081600 in __pthread_kill_implementation.constprop.0 () from /lib64/libc.so.6
(gdb) FAIL: gdb.base/corefile.exp: core-file warning-free
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tom de Vries [Wed, 20 Mar 2024 18:31:24 +0000 (19:31 +0100)]
[gdb/testsuite] Fix gdb.server/server-connect.exp for missing ipv6
On a system without ipv6 support enabled, when running test-case
gdb.server/server-connect.exp, it takes about 4 minutes, and I get:
...
builtin_spawn gdbserver --once ::1:2347 server-connect^M
Can't open socket: Address family not supported by protocol.^M
Exiting^M
PASS: gdb.server/server-connect.exp: tcp6: start gdbserver
target remote tcp6:::1:2347^M
A program is being debugged already. Kill it? (y or n) y^M
could not connect: Address family not supported by protocol.^M
(gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
...
Fix this by:
- recognizing the error message in gdbserver_start, and returning an empty list
to signal unsupported, and
- handling the unsupported response in the test-case.
This brings testing time down to 2 seconds, and gets me:
...
UNSUPPORTED: gdb.server/server-connect.exp: tcp6: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: tcp6-with-brackets: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: udp6: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: udp6-with-brackets: start gdbserver
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31502
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31502
Tom de Vries [Wed, 20 Mar 2024 18:29:18 +0000 (19:29 +0100)]
[gdb/testsuite] Handle core without build-id in gdb.base/corefile-buildid.exp
On aarch64-linux (debian 12), when running test-case gdb.base/corefile-buildid.exp, I get:
...
expecting exec file "debugdir-exec/.build-id/ec/f10ec5d39648774f8c35d3cf757c8db52f5163"
info files^M
Local core dump file:^M
`build-exec/corefile-buildid.core', file type elf64-littleaarch64.^M
0x0000aaaac1d70000 - 0x0000aaaac1d71000 is load1^M
...
0x0000ffffffa8b000 - 0x0000ffffffaac000 is load16^M
(gdb) FAIL: gdb.base/corefile-buildid.exp: exec: info files
...
The problem is that the test-case expect the build-id to be available in the
core file, while it isn't.
Fix this by detecting that the build-id isn't available in the core file using eu-readelf, as in
gdb.base/coredump-filter-build-id.exp.
Tom de Vries [Wed, 20 Mar 2024 18:23:48 +0000 (19:23 +0100)]
[gdb/testsuite] Add PR gdb/26967 KFAIL in two more test-cases
On aarch64-linux (debian 12), when running test-case
gdb.base/longjmp-until-in-main.exp, I run into:
...
(gdb) until 33^M
warning: Breakpoint address adjusted from 0x70f727c678928489 to 0xfff727c678928489.^M
Warning:^M
Cannot insert breakpoint 0.^M
Cannot access memory at address 0xfff727c678928489^M
^M
0x0000fffff7e3a580 in siglongjmp () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.base/longjmp-until-in-main.exp: until $line, in main
...
This is PR gdb/26967: no longjmp probe is available:
...
(gdb) info probes stap libc ^longjmp$^M
No probes matched.^M
...
and glibc applies pointer mangling which makes it fairly difficult for gdb to
get the longjmp target.
There's a KFAIL for this in test-case gdb.base/longjmp.exp, added in commit b5e7cd5cd3d ("[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp").
Factor out new proc have_longjmp_probe, and use it to add similar KFAIL in
this and one more test-case.
Hannes Domani [Wed, 20 Mar 2024 17:23:40 +0000 (18:23 +0100)]
Fix casting in-memory values of primitive types to const reference
It's currently not possible to cast an in-memory value of a primitive
type to const reference:
```
(gdb) p Q.id
$1 = 42
(gdb) p (int&)Q.id
$2 = (int &) @0x22fd0c: 42
(gdb) p (const int&)Q.id
Attempt to take address of value not located in memory.
```
And if in a function call an argument needs the same kind of casting,
it also doesn't work:
```
(gdb) l f3
39 int f3(const int &i)
40 {
41 return i;
42 }
(gdb) p f3(Q.id)
Attempt to take address of value not located in memory.
```
It's because when the constness of the type changes in a call to
value_cast, a new not_lval value is allocated, which doesn't exist
in the target memory.
Fixed by ignoring const/volatile/restrict qualifications in
value_cast when comparing cast type to original type, so the new
value will point to the same location as the original value:
```
(gdb) p (int&)i
$2 = (int &) @0x39f72c: 1
(gdb) p (const int&)i
$3 = (const int &) @0x39f72c: 1
(gdb) p f3(Q.id)
$4 = 42
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19423 Approved-By: Tom Tromey <tom@tromey.com>
Hannes Domani [Wed, 20 Mar 2024 17:02:06 +0000 (18:02 +0100)]
Fix reinterpret_cast for classes with multiple inheritance
Currently a reinterpret_cast may change the pointer value if
multiple inheritance is involved:
```
(gdb) p r
$1 = (Right *) 0x22f75c
(gdb) p reinterpret_cast<LeftRight*>(r)
$2 = (LeftRight *) 0x22f758
```
It's because value_cast is called in this case, which automatically
does up- and downcasting.
Fixed by simply using the target pointer type in a copy of the
original value:
```
(gdb) p r
$1 = (Right *) 0x3bf87c
(gdb) p reinterpret_cast<LeftRight*>(r)
$2 = (LeftRight *) 0x3bf87c
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18861 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 11 Mar 2024 15:09:43 +0000 (11:09 -0400)]
Add .pre-commit-config.yaml
Add a pre-commit [1] config file, with a single hook to run black on the
gdb directory whenever a Python file is modified. We can always add
more hooks if we find some that are useful.
Using pre-commit to run hooks is opt-in, as in it's not mandatory at all
for development, but it can be useful to run some checks that are easy
to forget (like running black). The hooks run locally on the
developer's machine when doing `git commit` (although they can also be
configured to run at other stages of the git workflow).
Follow these instructions to install the hooks in your local development
git repository:
- Install pre-commit the way you prefer. It can be using your OS
package manager if it has a recent enough version, or using `pip
install pre-commit`.
- Go to the binutils-gdb repository and run `pre-commit install`.
This installs a git hook at `.git/hooks/pre-commit`.
Now, whenever you modify and try to commit a Python file, pre-commit
will run black on it. For instance, if I try to insert something
misformatted, I get this when doing `git commit`:
$ git commit
black....................................................................Failed
- hook id: black
- files were modified by this hook
reformatted gdb/python/lib/gdb/dap/breakpoint.py
All done! ✨ 🍰 ✨
1 file reformatted.
At this point, black has already reformatted the files in place, so the
changes that fix the formatting are ready to add and commit. black is
only ran on files modified in the commit.
The hook defines a black version, which is downloaded at `pre-commit
install` time. pre-commit manages its own env at
`$HOME/.cache/pre-commit/<some-hash>`, so it won't use the version of
black you have installed already. This may help ensure that
contributors use the right black version.
The procedure when there is a new version of black (or a new version of
any hook we might be using in the future) is:
- Modify .pre-commit-config.yaml to change the version number, push to
the upstream repo.
- Have contributors run `pre-commit autoupdate` to make their local
pre-commit installation update the hooks.
It is possible to have pre-commit skip some hooks if needed [2].
I will add these instructions to the wiki if this patch gets merged, so
they are easy to find. We could perhaps think of having a
gdb/CONTRIBUTING document of some sort checked in the repo with that
kind of information.
I have not used pre-commit in a real project before, but have heard good
things from it. If we want to give it a try before pushing it to the
repo, some volunteers can copy the .pre-commit-config.yaml file locally
and try it for some time. However, pushing the file upstream is not
going to impact anybody who doesn't care about it, so I'd say it's
relatively low-risk to push it right now.
Hannes Domani [Mon, 25 Dec 2023 18:05:55 +0000 (19:05 +0100)]
Fix comparison of array types
Currently it's not possible to call functions if an argument is a
pointer to an array:
```
(gdb) l f
1 int f (int (*x)[2])
2 {
3 return x[0][1];
4 }
5
6 int main()
7 {
8 int a[2][2] = {{0, 1}, {2, 3}};
9 return f (a);
10 }
(gdb) p f(a)
Cannot resolve function f to any overloaded instance
```
This happens because types_equal doesn't handle array types, so the
function is never even considered as a possibility.
With array type handling added, by comparing element types and array
bounds, the same works:
```
(gdb) p f(a)
$1 = 1
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15398 Co-Authored-By: Keith Seitz <keiths@redhat.com> Reviewed-By: Guinevere Larsen <blarsen@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Tiezhu Yang [Thu, 29 Feb 2024 08:39:10 +0000 (16:39 +0800)]
gdb: LoongArch: Set the correct XML syscall filename
Now, there exists syscalls/loongarch-linux.xml, let us set the correct
XML syscall filename for LoongArch, otherwise GDB won't be able to find
the correct XML file to open and get the syscalls definitions.
It should install the package expat-devel (a library for XML parsing)
and configure --with-expat (done by default if libexpat is installed
and found at configure time) for compiling gdb in this case.
Without this patch:
(gdb) catch syscall
warning: There is no XML file to open.
warning: GDB will not be able to display syscall names nor to verify if
any provided syscall numbers are valid.
Catchpoint 1 (any syscall)
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-By: John Baldwin <jhb@FreeBSD.org>
Tiezhu Yang [Thu, 29 Feb 2024 08:39:09 +0000 (16:39 +0800)]
gdb: syscalls: Add loongarch case in update-linux-from-src.sh
It shows that "Don't know how to generate loongarch-linux.xml.in"
when using the script update-linux-from-src.sh to regenerate the
syscall group info against Linux kernel, just add loongarch case.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-By: John Baldwin <jhb@FreeBSD.org>
Tiezhu Yang [Thu, 29 Feb 2024 08:39:07 +0000 (16:39 +0800)]
gdb: syscalls: Add loongarch-linux.xml.in
There is no syscall.tbl for LoongArch because it uses generic syscalls,
so it can not generate loongarch-linux.xml.in automatically through the
script update-linux-from-src.sh, make use of the script update-linux.sh
to generate loongarch-linux.xml.in.
Note that the system header file /usr/include/asm-generic/unistd.h
may be different with the latest upstream Linux kernel uapi header
file include/uapi/asm-generic/unistd.h, it is better to copy the
upstream header file into the system header file when generating
loongarch-linux.xml.in.
There exist some __NR3264_ prefixed syscall numbers, replace them
with digital numbers according to /usr/include/asm-generic/unistd.h
and sort them by syscall number manually, maybe we can modify the
script to do it automatically in the future.
Tiezhu Yang [Thu, 29 Feb 2024 08:39:05 +0000 (16:39 +0800)]
gdb: syscalls: Update .xml.in files for some archs
Make use of the script update-linux-from-src.sh to regenerate the Linux
syscall group info against Linux git commit d206a76d7d27 which will be
released in v6.8.
Tiezhu Yang [Thu, 29 Feb 2024 08:39:03 +0000 (16:39 +0800)]
gdb: syscalls: Update linux-defaults.xml.in
Make use of the script update-linux-defaults.sh to regenerate the Linux
syscall group info against strace git commit 8c480270653d which will be
released in v6.8.
Tom de Vries [Wed, 20 Mar 2024 08:57:49 +0000 (09:57 +0100)]
[gdb/symtab] Workaround PR gas/31115
On arm-linux, with gas 2.40, I run into:
...
(gdb) x /i main+8^M
0x4e1 <main+7>: vrhadd.u16 d14, d14, d31^M
(gdb) FAIL: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try)
...
This is a regression due to PR gas/31115, which makes gas produce a low_pc
with the thumb bit set (0x4d8 & 0x1):
...
<1><24>: Abbrev Number: 2 (DW_TAG_subprogram)
<25> DW_AT_name : main
<29> DW_AT_external : 1
<29> DW_AT_type : <0x2f>
<2a> DW_AT_low_pc : 0x4d9
<2e> DW_AT_high_pc : 12
...
The regression was introduced in 2.39, and is also present in 2.40 and 2.41,
and hasn't been fixed yet.
Work around this in read_func_scope, by using gdbarch_addr_bits_remove on
low_pc and high_pc.
Tom Tromey [Wed, 14 Feb 2024 16:48:34 +0000 (09:48 -0700)]
Speed up lookup of "type_specific_data"
I noticed that "info locals" on a certain large Ada program was very
slow. I tracked this down to ada_get_tsd_type expanding nearly every
CU in the program.
This patch fixes the problem by changing this code to use the more
efficient lookup_transparent_type which, unlike the Ada-specific
lookup functions, does not try to find all matching instances.
Note that I first tried fixing this by changing ada_find_any_type, but
this did not work -- I may revisit this approach at some later date.
Also note that the copyright dates on the test files are set that way
because I copied them from another test.
New in v2: the new test failed on the Linaro regression tester.
Looking at the logs, it seems that gdb was picking up a 'value' from
libgnat:
$1 = {<text variable, no debug info>} 0xf7e227a4 <ada.calendar.formatting.value>
This version renames the local variable in an attempt to work around
this.
v3: In v2, while trying to reproduce the problem locally, I
accidentally forgot to commit one of the changes.
Tom Tromey [Fri, 23 Feb 2024 18:52:40 +0000 (11:52 -0700)]
Fix two serious flake8 reports
flake8 points out that some code in frame_filters.py is referring to
undefined variables.
In the first hunk, I've changed the code to match what other
'complete' methods do in this file.
In the second hunk, I've simply removed the try/except -- if
get_filter_priority fails, it will raise GdbError, which is already
handled properly by gdb.
Andrew Burgess [Fri, 15 Mar 2024 11:14:05 +0000 (11:14 +0000)]
gdb/python: test exception case for gdb.solib_name
The gdb.solib_name() and Progspace.solib_name() functions can throw an
exception if the address argument is not a valid address, but this is
not currently tested.
This commit adds a couple of tests to check that exceptions are thrown
correctly.
An early version of this commit updated the documentation, but it was
pointed out that lots of functions throw an exception if passed an
argument of the wrong type, and we don't document all of these, it's
kind-of assumed that passing an object of the incorrect type might
result in an exception, so this updated version leaves the docs alone,
but I do think adding the extra tests has value.
Andrew Burgess [Wed, 6 Mar 2024 17:48:55 +0000 (17:48 +0000)]
gdbsupport: rename include guard in gdb-checked-static-cast.h
I noticed in passing that the include guard in the file
gdbsupport/gdb-checked-static-cast.h was wrong, it includes the word
DYNAMIC when STATIC would be better, fixed in this commit.
There should be no user visible changes after this commit.
addressed an issue where GDB would not compile in production mode due
to a use of gdb::checked_static_cast. The problem was that we were
asking GDB to cast from a virtual base class to a sub-class, this
works fine when using dynamic_cast, but does not work with
static_cast.
The gdb::checked_static_cast actually uses dynamic_cast under the hood
in development mode in order to ensure that the cast is valid, while
in a production build we use static_cast as this is more efficient.
What this meant however, was that when gdb::checked_static_cast was
used to cast from a virtual base class, the dynamic_cast of a
non-production build worked fine, while the production build's
static_cast caused a build failure.
However, the gdb::checked_static_cast function already contains some
static_assert calls that are intended to catch any issues with invalid
type casting, the goal of these asserts was to prevent issues like
this: the build only failing in production mode. Clearly the current
asserts are not enough.
I don't think there is a std::is_virtual_base type trait check, so
what I propose instead is that in non-production mode we also make use
of static_cast. This will ensure that any errors that crop up in
production mode should also be revealed in non-production mode, and
should catch issues like this in the future.
There should be no user visible changes after this commit.
H.J. Lu [Sat, 16 Mar 2024 13:23:19 +0000 (06:23 -0700)]
ld: Support LD_UNDER_TEST environment variable
Support LD_UNDER_TEST environment variable to test a different linker.
Issue an error if LD_UNDER_TEST isn't an absolute full path.
* testsuite/config/default.exp: If LD_UNDER_TEST environment
variable exists, set ld and LD to it and set up tmpdir/ld/ld.
Issue an error if LD_UNDER_TEST isn't an absolute full path.
gdb/python: Fix segfault when iterating over empty linetable
symtab-> linetable () is set to null in
buildsym_compunit::end_compunit_symtab_with_blockvector () if the symtab
has no linetable. Attempting to iterate over this linetable using the
Python API caused GDB to segfault.
Tom de Vries [Tue, 19 Mar 2024 09:30:36 +0000 (10:30 +0100)]
[gdb] Further fix "value is not available" with debug frame
In commit 2aaba744467 ("[gdb] Fix "value is not available" with debug frame")
I fixed a case in frame_unwind_register_value where using "set debug frame on"
caused an "info frame" command to abort, reporting a "value is not available"
error, due to the tpidruro register being unavailable.
Subsequently, commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register from
non-FreeBSD target descriptions") removed the unavailable register, which
caused a progression on test-case gdb.base/inline-frame-cycle-unwind.exp.
While investigating the progression (see PR python/31437), I found that the
"debug frame" output of the test-case (when reverting commit bbb12eb9c84)
showed a smilar problem:
...
Python Exception <class 'gdb.error'>: value is not available^M
...
that was absent without "debug frame".
Fix this likewise in fetch_lazy_register, and update the test-case to check
for the exception.
Furthermore, I realized that there's both value::entirely_available and
value::entirely_unavailable, and that commit 2aaba744467 handled the case
of !entirely_available by printing unavailable.
Instead, print:
- "unavailable" for entirely_unavailable, and
- "partly unavailable" for !entirely_unavailable && !entirely_available.
These instructions are part of Checked Pointer Arithmetic extension
and are enabled when both CPA and SVE are enabled. To achieve this,
both flag "+sve" and "+cpa" should be active.
This patch adds assembler and disassembler support for these instructions
with relevant checks. Tests are included as well.
Regression tested on the aarch64-none-linux-gnu target and no regressions
have been found.
Yury Khrustalev [Wed, 21 Feb 2024 12:52:23 +0000 (12:52 +0000)]
aarch64: Add support for (M)ADDPT and (M)SUBPT instructions
The following instructions are added in this patch:
- ADDPT and SUBPT - Add/Subtract checked pointer
- MADDPT and MSUBPT - Multiply Add/Subtract checked pointer
These instructions are part of Checked Pointer Arithmetic extension.
This patch adds assembler and disassembler support for these instructions
with relevant checks. Tests are included as well.
A new flag "+cpa" added to documentation. This flag enables CPA extension.
Regression tested on the aarch64-none-linux-gnu target and no regressions
have been found.
projects / thirdparty / binutils-gdb.git / log
