Tom de Vries [Wed, 23 Aug 2023 17:28:37 +0000 (19:28 +0200)]
[gdb/build] Support reference return type in make-target-delegates.py
When doing this in target.h:
...
- virtual gdb::byte_vector thread_info_to_thread_handle (struct thread_info *)
+ virtual gdb::byte_vector &thread_info_to_thread_handle (struct thread_info *)
...
make-target-delegates.py drops the function.
By handling '&' in POINTER_PART we can prevent that the function is dropped,
but when recompiling target.o we get:
...
gdb/target-delegates.c: In member function ‘virtual gdb::byte_vector& \
debug_target::thread_info_to_thread_handle(thread_info*)’:
gdb/target-delegates.c:1889:22: error: ‘result’ declared as reference but not \
initialized
gdb::byte_vector & result;
^~~~~~
make: *** [Makefile:1923: target.o] Error 1
...
Fix this by making sure result is initialized.
Regenerate target-delegates.c using this new style.
Peter Edwards [Tue, 22 Aug 2023 18:57:28 +0000 (19:57 +0100)]
x86: Fix DT_JMPREL/DT_PLTRELSZ when relocs share a section
If a linker script does not place the PLT relocations and "normal"
relocations in separate ELF sections, `ld` will currently output incorrect
values for DT_JMPREL and DT_PLTRELSZ - they cover the entire ELF section,
rather than just the PLT relocations
Don't ignore the extent of the BFD section - use the size of the srelplt
BFD section and its offset from the output_secttion
bfd/
PR ld/30787
* elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Use input
section for DT_JMPREL and DT_PLTRELSZ.
Lancelot Six [Wed, 23 Aug 2023 14:50:42 +0000 (14:50 +0000)]
gdb: fix build failure in amd-dbgapi-target.c
Since b080fe54fb3 "gdb: add inferior-specific breakpoints", the
breakpoint class has an "inferior" member used to handle
inferior-specific breakpoints. This creates a compilation error
in amd_dbgapi_target_breakpoint::check_status which declares a local
variable "inferior *inf".
Fix this by using "struct inferior *inf" instead.
Change-Id: Icc4dc1ba96c7d3ff9d33f9cb384ffcf64eba26fb Approved-By: Pedro Alves <pedro@palves.net>
Pedro Alves [Fri, 28 Apr 2023 18:11:31 +0000 (19:11 +0100)]
Fix Windows sharing_input_terminal hang
After running a number of programs under Windows gdb and detaching
them, I typed run in gdb, and got a hang, here:
(top-gdb) bt
#0 sharing_input_terminal (pid=4672) at /home/pedro/gdb/src/gdb/mingw-hdep.c:388
#1 0x00007ff71a2d8678 in sharing_input_terminal (inf=0x23bf23dafb0) at /home/pedro/gdb/src/gdb/inflow.c:269
#2 0x00007ff71a2d887b in child_terminal_save_inferior (self=0x23bf23de060) at /home/pedro/gdb/src/gdb/inflow.c:423
#3 0x00007ff71a2c80c0 in inf_child_target::terminal_save_inferior (this=0x23bf23de060) at /home/pedro/gdb/src/gdb/inf-child.c:111
#4 0x00007ff71a429c0f in target_terminal_is_ours_kind (desired_state=target_terminal_state::is_ours_for_output) at /home/pedro/gdb/src/gdb/target.c:1037
#5 0x00007ff71a429e02 in target_terminal::ours_for_output () at /home/pedro/gdb/src/gdb/target.c:1094
#6 0x00007ff71a2ccc8e in post_create_inferior (from_tty=0) at /home/pedro/gdb/src/gdb/infcmd.c:245
#7 0x00007ff71a2cd431 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at /home/pedro/gdb/src/gdb/infcmd.c:502
#8 0x00007ff71a2cd58b in run_command (args=0x0, from_tty=0) at /home/pedro/gdb/src/gdb/infcmd.c:527
The problem is that the loop around GetConsoleProcessList looped
forever, because there were exactly 10 processes to return.
GetConsoleProcessList's documentation says:
If the buffer is too small to hold all the valid process identifiers,
the return value is the required number of array elements. The
function will have stored no identifiers in the buffer. In this
situation, use the return value to allocate a buffer that is large
enough to store the entire list and call the function again.
In this case, the buffer wasn't too small, it was exactly the right
size, so we should have broken out of the loop. We didn't due to a
"<" check that should have been "<=". That is fixed by this patch.
Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: I14e4909f2ac2fa83d0d9b6e64418b5831ac4e4e3
Nick Clifton [Wed, 23 Aug 2023 10:36:25 +0000 (11:36 +0100)]
readelf/objdump: Handle DWARF info with mixed types of range section.
PR 30791
* dwarf.h (debug_info): Add range_versions field.
* dwarf.c (read_and_display_attr_value): When recording a range arribute also ecord the dwarf version number.
(is_range_list_for_this_section): New function.
(display_debug_ranges): Only show debug ranges whose version is suitable for the secction being displayed.
gdb: avoid double stop after failed breakpoint condition check
Addressed a problem where two MI stopped events would be reported if a
breakpoint condition failed due to a signal, this commit was a
replacement for this commit:
gdb: don't always print breakpoint location after failed condition check
which solved the two stop problem, but only for the CLI. Before both
of these commits, if a b/p condition failed due to a signal then the
user would see two stops reported, the first at the location where the
signal occurred, and the second at the location of the breakpoint.
By default GDB remains at the location where the signal occurred, so
the second reported stop can be confusing, this is the problem that
commit 2e411b8c68eb tried to solve (for the CLI) and b1c0ab20809a
extended also address the issue for MI too.
However, while working on another patch I realised that there was a
problem with GDB after the above commits. Neither of the above
commits considered 'set unwindonsignal on'. With this setting on,
when an inferior function call fails with a signal GDB will unwind the
stack back to the location where the inferior function call started.
In the b/p case we're looking at, the stop should be reported at the
location of the breakpoint, not at the location where the signal
occurred, and this isn't what happens.
This commit fixes this by ensuring that when unwindonsignal is 'on',
GDB reports a single stop event at the location of the breakpoint,
this fixes things for both CLI and MI.
The function call_thread_fsm::should_notify_stop is called when the
inferior function call completes and GDB is figuring out if the user
should be notified about this stop event by calling normal_stop from
fetch_inferior_event in infrun.c. If normal_stop is called, then this
notification will be for the location where the inferior call stopped,
which will be the location at which the signal occurred.
Prior to this commit, the only time that normal_stop was not called,
was if the inferior function call completed successfully, this was
controlled by ::should_notify_stop, which only turns false when the
inferior function call has completed successfully.
In this commit I have extended the logic in ::should_notify_stop. Now
there are three cases in which ::should_notify_stop will return false,
and we will not announce the first stop (by calling normal_stop).
These three reasons are:
1. If the inferior function call completes successfully, this is
unchanged behaviour,
2. If the inferior function call stopped due to a signal and 'set
unwindonsignal on' is in effect, and
3. If the inferior function call stopped due to an uncaught C++
exception, and 'set unwind-on-terminating-exception on' is in
effect.
However, if we don't call normal_stop then we need to call
async_enable_stdin in call_thread_fsm::should_stop. Prior to this
commit this was only done for the case where the inferior function
call completed successfully.
In this commit I now call ::should_notify_stop and use this to
determine if we need to call async_enable_stdin. With this done we
now call async_enable_stdin for each of the three cases listed above,
which means that GDB will exit wait_sync_command_done correctly (see
run_inferior_call in infcall.c).
With these two changes the problem is mostly resolved. However, the
solution isn't ideal, we've still lost some information.
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
24 return *p; /* Crash here. */
Error in testing breakpoint condition:
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(cond_fail) will be abandoned.
Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
30 global_counter += 1; /* Set breakpoint here. */
(gdb)
In this state we see two stop notifications, the first is where the
signal occurred, while the second is where the breakpoint is located.
As GDB has unwound the stack (thanks to unwindonsignal) the second
stop notification reflects where the inferior is actually located.
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
24 return *p; /* Crash here. */
Error in testing condition for breakpoint 1:
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(cond_fail) will be abandoned.
(gdb) bt 1
#0 foo () at /tmp/mi-condbreak-fail.c:30
(More stack frames follow...)
(gdb)
This is the broken state. GDB is reports the SIGSEGV location, but
not the unwound breakpoint location. The final 'bt 1' shows that the
inferior is not located in cond_fail, which is the only location GDB
reported, so this is clearly wrong.
After implementing the fixes described above we now get this
behaviour:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Error in testing breakpoint condition for breakpoint 1:
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(cond_fail) will be abandoned.
Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
30 global_counter += 1; /* Set breakpoint here. */
(gdb)
This is better. GDB now reports a single stop at the location of the
breakpoint, which is where the inferior is actually located. However,
by removing the first stop notification we have lost some potentially
useful information about which signal caused the inferior to stop.
To address this I've reworked the message that is printed to include
the signal information. GDB now reports this:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Error in testing condition for breakpoint 1:
The program being debugged received signal SIGSEGV, Segmentation fault
while in a function called from GDB. GDB has restored the context
to what it was before the call. To change this behavior use
"set unwindonsignal off". Evaluation of the expression containing
the function (cond_fail) will be abandoned.
Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
30 global_counter += 1; /* Set breakpoint here. */
(gdb)
This is better, the user now sees a single stop notification at the
correct location, and the error message describes which signal caused
the inferior function call to stop.
However, we have lost the information about where the signal
occurred. I did consider trying to include this information in the
error message, but, in the end, I opted not too. I wasn't sure it was
worth the effort. If the user has selected to unwind on signal, then
surely this implies they maybe aren't interested in debugging failed
inferior calls, so, hopefully, just knowing the signal name will be
enough. I figure we can always add this information in later if
there's a demand for it.
Andrew Burgess [Fri, 4 Aug 2023 13:25:54 +0000 (14:25 +0100)]
gdb/testsuite: add mi_info_frame helper proc (and use it)
New helper proc mi_info_frame which takes care of running the MI
-stack-info-frame command and matching its output.
Like the breakpoint helper procs, this new proc takes a name/value
argument list and uses this to build the expected result regexp. This
means that we can now write something like:
mi_info_frame "test name here" \
-level 0 -func name -line 123
Instead of the current equivalent:
mi_gdb_test "235-stack-info-frame" \
"235\\^done,frame=\{level=\"0\",addr=\"$hex\",func=\"name\",file=\".*\",fullname=\".*\",line=\"123\",arch=\".*\"\}" \
"test name here"
There's also a helper proc mi_make_info_frame_regexp which is
responsible for building the 'frame={...}' part of the pattern.
I've update the two existing tests that use -stack-info-frame and
expect the command to succeed. There is another test that runs
-stack-info-frame and expects the command to fail -- the helper proc
doesn't help with this case, so that test is not changed.
Currently, each target backend is responsible for printing "[Thread
...exited]" before deleting a thread. This leads to unnecessary
differences between targets, like e.g. with the remote target, we
never print such messages, even though we do print "[New Thread ...]".
E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp
with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we
currently see:
Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
(gdb)
Above, we only see "New Thread" notifications, even though threads
were deleted.
Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
(gdb) q
This commit fixes this by moving the thread exit printing to common
code instead, triggered from within delete_thread (or rather,
set_thread_exited).
There's one wrinkle, though. While most targest want to print:
[Thread ... exited]
the Windows target wants to print:
[Thread ... exited with code <exit_code>]
... and sometimes wants to suppress the notification for the main
thread. To address that, this commits adds a delete_thread_with_code
function, only used by that target (so far).
This fix was originally posted as part of a larger series:
But didn't really need to be part of that series. In order to get
this fix merged sooner, I (Andrew Burgess) have rebased this commit
outside of the original series. Any bugs introduced while splitting
this patch out and rebasing, are entirely my own.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129 Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Andrew Burgess [Thu, 17 Aug 2023 09:34:27 +0000 (10:34 +0100)]
gdb: remove the silent parameter from exit_inferior_1 and cleanup
After the previous commit, exit_inferior_1 no longer makes use of the
silent parameter. This commit removes this parameter and cleans up
the callers.
After doing this exit_inferior_1, exit_inferior, and
exit_inferior_silent are all equivalent, so rename exit_inferior_1 to
exit_inferior and delete exit_inferior_silent, update all the callers.
Also I spotted the declaration exit_inferior_num_silent in inferior.h,
but this function is not defined anywhere, so I deleted the
declaration.
There should be no user visible changes after this commit.
Which also didn't really need to be part of the larger series, but
does depend, at least a little, on this commit. In order to get the
fix I'm interested in merged quicker, I (Andrew Burgess) have rebased
this commit outside of the original series. Any bugs introduced while
splitting this patch out and rebasing, are entirely my own.
There should be no user visible changes after this commit.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
which introduced the mi_parse::make functions, though after discussion
on the list the reasons for seem to have been lost[1]. Given there
are no test regressions when moving back to using the constructors, I
propose we should do that for now.
There should be no user visible changes after this commit.
Andrew Burgess [Thu, 10 Aug 2023 16:57:46 +0000 (17:57 +0100)]
gdb: add gdb::make_unique function
While GDB is still C++11, lets add a gdb::make_unique template
function that can be used to create std::unique_ptr objects, just like
the C++14 std::make_unique.
If GDB is being compiled with a C++14 compiler then the new
gdb::make_unique function will delegate to the std::make_unique. I
checked with gcc, and at -O1 and above gdb::make_unique will be
optimised away completely in this case.
If C++14 (or later) becomes our minimum, then it will be easy enough
to go through the code and replace gdb::make_unique with
std::make_unique later on.
I've make use of this function in all the places I think this can
easily be used, though I'm sure I've probably missed some.
Should be no user visible changes after this commit.
limited support was added in lib/mi-support.exp to help with testing
of inferior specific breakpoints.
Though the changes that were added were not wrong, while working on a
later patch, I realised that I had added the support in the wrong
place -- I only added support to mi_make_breakpoint_multi, when really
I should have added the support to mi_make_breakpoint_1, which is used
by all of the MI procs that create breakpoints.
This commit moves the support to mi_make_breakpoint_1, and updates all
the procs that use mi_make_breakpoint_1 to accept, and then pass
through, and (optional) inferior argument. This will make it much
easier to write MI tests for inferior specific breakpoints.
There's no change in what is tested after this commit.
introduced a bug in the function breakpoint_set_inferior. The above
commit includes this line:
gdb::observers::breakpoint_modified.notify (b);
when it should have instead used this line:
notify_breakpoint_modified (b);
The change to use notify_breakpoint_modified was introduced to GDB
after commit b080fe54fb34 was written, but before it was merged, and I
failed to update this part of the code during the rebase.
The consequence of this error is that the MI interpreter will not emit
breakpoint-modified notifications when breakpoint_set_inferior is
called.
In this commit I update the code to call notify_breakpoint_modified,
and add a test that checks the MI events are being emitted correctly
in this case.
Paul Iannetta [Thu, 17 Aug 2023 14:08:29 +0000 (16:08 +0200)]
kvx: fix 32-bit build
bfd/
* Makefile.am: Move elf32-kvx.lo from BFD32_BACKENDS to
BFD64_BACKENDS. Remove elfxx-kvx.lo from BFD32_BACKENDS.
Remove elfxx-kvx.c from BFD32_BACKENDS_CFILES.
* Makefile.in: Regenerate.
* config.bfd: Adjust targ_defvec and targ_selvecs and gate them
behind BFD64.
* configure.ac: Add target_size=64 to kvx_elf64_*vec.
* configure: Regenerate.
* elfnn-kvx.c (elfNN_kvx_stub_name): Cast rel->r_addend to
uint64_t to match format string.
(elfNN_kvx_relocate_section): Similarly for r_offset, and
use PRIx64 in format string.
* targets.c (_bfd_target_vector <kvx_elf32_vec>): Move inside
#ifdef BFD64.
ld/
* Makefile.am: Move eelf32kvx.c from ALL_EMULATION_SOURCES to
ALL_64_EMULATION_SOURCES.
* Makefile.in: Regenerate.
Alan Modra [Tue, 22 Aug 2023 23:26:13 +0000 (08:56 +0930)]
kvx: O_pseudo_fixup
O_pseudo_fixup was defined as O_max+1, missing the fact that O_md1
through O_md32 enums are for use by target code. Worse, kvx-parse.c
used 64 rather than O_pseudo_fixup. Fix this, and wrap some overlong
lines.
* config/tc-kvx.h (O_pseudo_fixup): Define.
* config/tc-kvx.c (O_pseudo_fixup): Don't define here.
(insert_operand): Delete bogus comment and cast.
* config/kvx-parse.c (promote_token): Use O_pseudo_fixup
rather than hardcoded value. Wrap overlong lines.
(get_token_class): Likewise.
(parse_with_restarts): Wrap overlong line.
Alan Modra [Tue, 22 Aug 2023 23:04:12 +0000 (08:34 +0930)]
kvx: ubsan: integer overflow
This fixes a few places where ubsan complains about signed integer
overflow when running the testsuite, and that clz(0) is undefined.
When fixing the clz problem, I also noticed that we'd get complaints
if pval is ever LLONG_MIN. Fix that by using unsigned arithmetic.
* config/kvx-parse.c (get_token_class): Avoid signed overflow.
Don't clz(0).
* config/tc-kvx.c (PARALLEL_BIT): Avoid signed overflow.
Alan Modra [Tue, 22 Aug 2023 22:48:39 +0000 (08:18 +0930)]
kvx: asan: out-of-bounds read
kvx-parse.c:parse_with_restarts does
if (!tok.insn[tok.begin])
tok.class_id = -3;
then a little later
printf_debug (1, "\nEntering rule: %d (Trying to match: (%s)[%d])\n", jump_target,
TOKEN_NAME (CLASS_ID (tok)), CLASS_ID (tok));
This results in a buffer overrun in TOKEN_NAME. Fix that.
* config/tc-kvx.h (TOKEN_NAME): Check for tok <= 0, not just -1.
Alan Modra [Tue, 22 Aug 2023 06:36:32 +0000 (16:06 +0930)]
kvx bfd signed calculations and _bfd_kvx_elf_resolve_relocation
It is generally a good idea to avoid signed arithmetic on values
extracted from object files, to avoid ubsan warnings on overflow.
This patch replaces some uses of bfd_signed_vma in the kvx backend
with bfd_vma, and removes _bfd_kvx_elf_resolve_relocation, a
do-nothing function. In the process of making this patch I noticed
some dead code in the GOT entry handling, setting value to
got_entry_addr but using "off" in the _bfd_final_link_relocate call.
Since kvx_calculate_got_entry_vma also returns the GOT offset, I
presume the code is correct, but I've left the dead code and comment
there.
* elfxx-kvx.h (_bfd_kvx_elf_resolve_relocation): Delete.
* elfxx-kvx.c (kvx_signed_overflow): Rewrite using unsigned
arithmetic.
(_bfd_kvx_elf_resolve_relocation): Delete.
* elfnn-kvx.c (kvx_relocate): Update for
_bfd_kvx_elf_resolve_relocation removal.
(elfNN_kvx_final_link_relocate): Likewise. Don't use a signed
addend.
Alan Modra [Tue, 22 Aug 2023 11:50:57 +0000 (21:20 +0930)]
gdb: bfd_get_symbol_leading_char vs. ""
Some places matching the first char of a string against
bfd_get_symbol_leading_char, which may be zero, didn't check for "".
This could lead to accesses past the end of the string and potential
buffer overruns. Fix that, and also get rid of a stupid optimisation
in dbxread when looking for "__DYNAMIC" that also might access past
the end of a string.
Alan Modra [Tue, 22 Aug 2023 11:43:41 +0000 (21:13 +0930)]
bfd_get_symbol_leading_char vs. ""
Some places matching the first char of a string against
bfd_get_symbol_leading_char, which may be zero, didn't check for the
string being "". This patch adds the check to stop accesses past the
end of the string and potential buffer overruns.
The dlltool one was found by oss-fuzz quite a while ago.
bfd/
* cofflink.c (_bfd_coff_link_input_bfd): Ensure a zero
bfd_get_symbol_leading_char doesn't lead to accessing past the
zero string terminator.
* linker.c (bfd_wrapped_link_hash_lookup): Likewise.
(unwrap_hash_lookup): Likewise.
binutils/
* dlltool.c (scan_filtered_symbols): Ensure a zero
bfd_get_symbol_leading_char doesn't lead to accessing past the
zero string terminator.
Tom de Vries [Tue, 22 Aug 2023 17:35:52 +0000 (19:35 +0200)]
[gdb/build] Work around cgen odr violations
When building gdb with -flto -O2, I run into:
...
opcodes/mep-desc.h:250:14: warning: type 'cgen_operand_type' violates the \
C++ One Definition Rule [-Wodr]
typedef enum cgen_operand_type {
^
opcodes/or1k-desc.h:624:14: note: an enum with different value name is \
defined in another translation unit
typedef enum cgen_operand_type {
^
opcodes/mep-desc.h:212:14: warning: type 'cgen_hw_type' violates the C++ One \
Definition Rule [-Wodr]
typedef enum cgen_hw_type {
^
opcodes/or1k-desc.h:433:14: note: an enum with different value name is \
defined in another translation unit
typedef enum cgen_hw_type {
^
...
Fix this by making the conflicting type names unique, adding a target-specific
prefix using a define before the include:
...
#define cgen_operand_type <target-name>_cgen_operand_type
#define cgen_hw_type <target-name>_cgen_hw_type
#include "opcodes/<target-name>-desc.h"
...
and move those defines into a new file cgen-remap.h, similar to how that's
done for yacc in yy-remap.h.
Likewise for targets frv and lm32, the two other targets that include
opcodes/<target-name>-desc.h.
Likewise for more cgen symbols that I got the same warning for when using
-flto-partition=one.
A PR has been filed to take care of this in the opcodes dir instead (PR30758).
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/30757
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30757
Tom Tromey [Fri, 4 Aug 2023 13:58:32 +0000 (07:58 -0600)]
Remove value::copy call from gdbpy_get_varobj_pretty_printer
I noticed a call to value::copy in gdbpy_get_varobj_pretty_printer,
and I couldn't figure out why it was there. I think maybe it came
from the time when value_to_value_object would release values from the
value chain -- but that was removed in commit f3d3bbbc.
This patch removes this call. Regression tested on x86-64 Fedora 36.
aarch64: Improve naming conventions for A and R-profile architecture
Historically, flags and variables relating to architectural revisions
for the A-profile architecture omitted the trailing `A' such that, for
example, assembling for `-march=armv8.4-a' set the `AARCH64_ARCH_V8_4'
flag in the assembler.
This leads to some ambiguity, since Binutils also targets the
R-profile Arm architecture. Therefore, it seems prudent to have
everything associated with the A-profile cores end in `A' and likewise
`R' for the R-profile. Referring back to the example above, the flag
set for `-march=armv8.4-a' is better characterized if labeled
`AARCH64_ARCH_V8_4A'.
The only exception to the rule of appending `A' to variables is found
in the handling of the `AARCH64_FEATURE_V8' macro, as it is the
baseline from which ALL processors derive and should therefore be left
unchanged.
In reflecting the `ARM' architectural nomenclature choices, where we
have `ARM_ARCH_V8A' and `ARM_ARCH_V8R', the choice is made to not have
an underscore separating the numerical revision number and the
A/R-profile indicator suffix. This has meant that renaming of
R-profile related flags and variables was warranted, thus going from
`.*_[vV]8_[rR]' to `.*_[vV]8[rR]'.
Finally, this is more in line with conventions within GCC and adds consistency
across the toolchain.
Alan Modra [Tue, 22 Aug 2023 02:11:37 +0000 (11:41 +0930)]
objdump: file name table entry count check
Fuzzers have found that objdump -W takes a really long time if
the entry count uleb is ridiculously large, and format attributes
don't consume data (which doesn't make sense for a table of names).
* dwarf.c (display_formatted_table): Sanity check count of
table entries.
Alan Modra [Mon, 21 Aug 2023 22:01:03 +0000 (07:31 +0930)]
kvx_dis_init
kvx_dis_init currently always returns true, but error conditions do so
by "return -1" which converts to true. The return status is ignored
anyway, and it doesn't make much sense to error on unexpected arch or
mach: If print_insn_kvx is called then the atch is known to be kvx,
and it's better to choose some default for a user passing an unknown
mach value rather than segfaulting in decode_insn when env.opc_table
is NULL.
I've chosen the default mach to be bfd_mach_kv3_1, the default in
bfd/cpu-kvx.c, not that it matters very much. In normal objdump/gdb
usage, info->mach won't be an unexpected value.
* kvx-dis.c (kvx_dis_init): Return void. Don't error on
unexpected arch or mach. Default to bfd_mach_kv3_1 for
unknown mach. Don't clear info->disassembler_options.
David Faust [Mon, 21 Aug 2023 16:36:36 +0000 (09:36 -0700)]
sim: bpf: remove negi, neg32i insns
The BPF virtual machine does not support neg instructions operating on
immediates, and these erroneous instructions were recently removed from
gas. Remove them from the simulator as well.
David Faust [Mon, 21 Aug 2023 16:07:11 +0000 (09:07 -0700)]
bpf: correct neg and neg32 instruction encoding
The neg/neg32 BPF instructions always use BPF_SRC_K (=0) in their header
source bit, despite operating on registers. If BPF_SRC_X (=1) is set,
the instructions are rejected by the kernel.
Because of this there are also no neg/neg32 instructions which operate
on immediates, so remove them.
Luis Machado [Tue, 4 Apr 2023 13:13:50 +0000 (14:13 +0100)]
aarch64/sme2: Teach binutils/BFD about the NT_ARM_ZT register set
The Scalable Matrix Extension v2 (SME2) defines a new register, ZT0, that
the Linux Kernel handles through a new NT_ARM_ZT register set.
Teach binutils/BFD about it so that gdb can make use of it for reading
and writing core files. This also enables readelf/objdump to show the
correct identification for the NT_ARM_ZT register set.
Alan Modra [Mon, 21 Aug 2023 09:08:08 +0000 (18:38 +0930)]
bfd_close_all_done bug and bfd_last_cache
bfd_close ought to always call iovec->bclose so that cache_bclose is
called. If not, bfd_last_cache will be left pointing at freed memory.
This bug was found by oss-fuzz with the trigger being an old bug in
the ia64-vms support. Given a file of the "wrong" size,
elf64_vms_close_and_cleanup attempted to extend it, leading to an
error since the file was opened read-only by nm. nm bad_file bad_file
then hit the use-after-free when opening the second file.
commit 8219cab3f8 fixed multiple bugs of this type in bfd_close and
bfd_close_all_done, but didn't go quite far enough.
Tom Tromey [Sat, 19 Aug 2023 18:26:21 +0000 (12:26 -0600)]
Placate -Wmissing-declarations in sim/cris
I get a couple of -Wmissing-declarations errors when building the sim.
This happens because an earlier patch added the declarations to a
cgen-generated header, but the recent re-generation then removed them.
This patch fixes the build by adding declarations just before the
definition. This is normally not best practice, but in this
particular situation it at leat un-breaks the build.
Alan Modra [Thu, 10 Aug 2023 02:44:01 +0000 (12:14 +0930)]
sim regen
This regenerates sim files.
Tested with the following tools from a recent binutils build in
sim-site-config.exp, plus a few cross compilers.
set AS_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/gas/as-new"
set LD_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_AARCH64 "aarch64-linux-gnu-gcc"
set AS_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/gas/as-new"
set LD_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/ld/ld-new"
set CC_FOR_TARGET_ARM "arm-linux-gnueabi-gcc"
set AS_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/gas/as-new"
set LD_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/ld/ld-new"
set CC_FOR_TARGET_AVR ""
set AS_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/gas/as-new"
set LD_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/ld/ld-new"
set CC_FOR_TARGET_BFIN ""
set AS_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/gas/as-new"
set LD_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/ld/ld-new"
set CC_FOR_TARGET_BPF ""
set AS_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/gas/as-new"
set LD_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/ld/ld-new"
set CC_FOR_TARGET_CR16 ""
set AS_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/gas/as-new"
set LD_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/ld/ld-new"
set CC_FOR_TARGET_CRIS ""
set AS_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/gas/as-new"
set LD_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/ld/ld-new"
set CC_FOR_TARGET_D10V ""
set AS_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/gas/as-new"
set LD_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/ld/ld-new"
set CC_FOR_TARGET_FRV ""
set AS_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/gas/as-new"
set LD_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/ld/ld-new"
set CC_FOR_TARGET_FT32 ""
set AS_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/gas/as-new"
set LD_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/ld/ld-new"
set CC_FOR_TARGET_H8300 ""
set AS_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/gas/as-new"
set LD_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/ld/ld-new"
set CC_FOR_TARGET_IQ2000 ""
set AS_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/gas/as-new"
set LD_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_LM32 ""
set AS_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/gas/as-new"
set LD_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/ld/ld-new"
set CC_FOR_TARGET_M32C ""
set AS_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/gas/as-new"
set LD_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/ld/ld-new"
set CC_FOR_TARGET_M32R ""
set AS_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/gas/as-new"
set LD_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/ld/ld-new"
set CC_FOR_TARGET_M68HC11 ""
set AS_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/gas/as-new"
set LD_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/ld/ld-new"
set CC_FOR_TARGET_MCORE ""
set AS_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/gas/as-new"
set LD_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_MICROBLAZE "microblaze-linux-gnu-gcc"
set AS_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/gas/as-new"
set LD_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_MIPS "mips-linux-gnu-gcc"
set AS_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/gas/as-new"
set LD_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/ld/ld-new"
set CC_FOR_TARGET_MN10300 ""
set AS_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/gas/as-new"
set LD_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/ld/ld-new"
set CC_FOR_TARGET_MOXIE ""
set AS_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/gas/as-new"
set LD_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/ld/ld-new"
set CC_FOR_TARGET_MSP430 ""
set AS_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/gas/as-new"
set LD_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_OR1K ""
set AS_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/gas/as-new"
set LD_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_PPC "powerpc-linux-gnu-gcc"
set AS_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/gas/as-new"
set LD_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/ld/ld-new"
set CC_FOR_TARGET_PRU ""
set AS_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/gas/as-new"
set LD_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/ld/ld-new"
set CC_FOR_TARGET_RISCV ""
set AS_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/gas/as-new"
set LD_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/ld/ld-new"
set CC_FOR_TARGET_RL78 ""
set AS_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/gas/as-new"
set LD_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/ld/ld-new"
set CC_FOR_TARGET_RX ""
set AS_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/gas/as-new"
set LD_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/ld/ld-new"
set CC_FOR_TARGET_SH ""
set AS_FOR_TARGET_ERC32 ""
set LD_FOR_TARGET_ERC32 ""
set CC_FOR_TARGET_ERC32 ""
set AS_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/gas/as-new"
set LD_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/ld/ld-new"
set CC_FOR_TARGET_V850 ""
Alan Modra [Thu, 10 Aug 2023 01:42:39 +0000 (11:12 +0930)]
sim --enable-cgen-maint
I had reason yesterday to want to regenerate configury files which I
do with --enable-maintainer-mode, and added --enable-cgen-maint
accidentally. The first problem I hit is that sim looks for cgen in a
different directory by default than opcodes, and I had my source
layout set up for opcodes rather than sim. Fix that by making both
use ../cgen first, then ../../cgen relative to sim/ and opcodes/. The
next problem was that various sim local.mk files expected generated
sources in the build dir rather than the source dir. Fix that by
adding $(srcdir) to paths. Finally, the generated iq2000 files had a
compile error, fixed by the cpu/iq2000.cpu patch.
cpu/
* iq2000.cpu (syscall): Add pc arg.
opcodes/
* configure.ac (cgendir): Default to ../../cgen, but use ../cgen
if found there.
* configure: Regenerate.
sim/m4/
* sim_ac_option_cgen_maint.m4 (cgendir): Look in ../cgen too.
sim/
* cris/local.mk: Add $(srcdir) to paths for regenerated source.
* frv/local.mk: Likewise.
* iq2000/local.mk: Likewise.
* lm32/local.mk: Likewise.
* m32r/local.mk: Likewise.
* or1k/local.mk: Likewise.
* Makefile.in: Regenerate.
* configure: Regenerate.
... reserves 'size()' entries, but then proceeds to push one extra
one.
This shouldn't have any really bad effects, as insert will grow the
vector. Still, it seems better to use the correct size if we're going
to bother calling reserve.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30780 Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Tom Tromey [Tue, 1 Aug 2023 16:08:23 +0000 (10:08 -0600)]
Merge psympriv.h into psymtab.h
psympriv.h was intended for use by code that created partial symbols.
Now that no generic code needs psymtab.h any more, psympriv.h can be
merged into psymtab.h.
Jan Beulich [Fri, 18 Aug 2023 06:58:15 +0000 (08:58 +0200)]
x86: remove indirection from bx[] and di_si[]
The longest register name is 3 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also slightly reduces
the number of base relocations in the final image.
Jan Beulich [Fri, 18 Aug 2023 06:57:34 +0000 (08:57 +0200)]
gas: make S_IS_LOCAL() and S_IS_EXTERNAL() exclusive of one another
While they aren't opposites of each other, there also shouldn't be any
symbol for which both return true; both may return false. Therefore
use S_IS_EXTERNAL() in S_IS_LOCAL(), thus subsuming the sanity check
which so far both did alike.
gp-display-gui (https://savannah.gnu.org/projects/gprofng-gui)
can be installed in a different directory.
In this case, $PATH is used to look up gp-display-text.
execv() does not use $PATH to find the executable.
gprofng/ChangeLog
2023-08-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/gp-display-text.cc (reexec): Use execvp instead of execv.
Andrew Burgess [Tue, 8 Nov 2022 12:32:51 +0000 (12:32 +0000)]
gdb: add inferior-specific breakpoints
This commit extends the breakpoint mechanism to allow for inferior
specific breakpoints (but not watchpoints in this commit).
As GDB gains better support for multiple connections, and so for
running multiple (possibly unrelated) inferiors, then it is not hard
to imagine that a user might wish to create breakpoints that apply to
any thread in a single inferior. To achieve this currently, the user
would need to create a condition possibly making use of the $_inferior
convenience variable, which, though functional, isn't the most user
friendly.
This commit adds a new 'inferior' keyword that allows for the creation
of inferior specific breakpoints.
Inferior specific breakpoints are automatically deleted when the
associated inferior is removed from GDB, this is similar to how
thread-specific breakpoints are deleted when the associated thread is
deleted.
Watchpoints are already per-program-space, which in most cases mean
watchpoints are already inferior specific. There is a small window
where inferior-specific watchpoints might make sense, which is after a
vfork, when two processes are sharing the same address space.
However, I'm leaving that as an exercise for another day. For now,
attempting to use the inferior keyword with a watchpoint will give an
error, like this:
(gdb) watch a8 inferior 1
Cannot use 'inferior' keyword with watchpoints
A final note on the implementation: currently, inferior specific
breakpoints, like thread-specific breakpoints, are inserted into every
inferior, GDB then checks once the inferior stops if we are in the
correct thread or inferior, and resumes automatically if we stopped in
the wrong thread/inferior.
An obvious optimisation here is to only insert breakpoint locations
into the specific program space (which mostly means inferior) that
contains either the inferior or thread we are interested in. This
would reduce the number times GDB has to stop and then resume again in
a multi-inferior setup.
I have a series on the mailing list[1] that implements this
optimisation for thread-specific breakpoints. Once this series has
landed I'll update that series to also handle inferior specific
breakpoints in the same way. For now, inferior specific breakpoints
are just slightly less optimal, but this is no different to
thread-specific breakpoints in a multi-inferior debug session, so I
don't see this as a huge problem.
Tom de Vries [Thu, 17 Aug 2023 15:09:39 +0000 (17:09 +0200)]
[gdb/build] Fix yysymbol_kind_t odr violation
When building gdb with -O2 -flto on openSUSE Tumbleweed (using bison 3.8.2) I
run into:
...
ada-exp.c.tmp:653: warning: type 'yysymbol_kind_t' violates the C++ One \
Definition Rule [-Wodr]
c-exp.c.tmp:398: note: an enum with different value name is defined in \
another translation unit
ada-exp.c.tmp:660: note: name 'YYSYMBOL_NULL_PTR' differs from name \
'YYSYMBOL_COMPLEX_INT' defined in another translation unit
c-exp.c.tmp:405: note: mismatching definition
...
Fix this by renaming to ada_exp_yysymbol_kind_t and likewise for other .y
files.
Alan Modra [Wed, 16 Aug 2023 23:31:17 +0000 (09:01 +0930)]
generated bfd files, and kvx regen
The elf32-kvx.c and elf64-kvx.c rules in the bfd makefile are
different to the other similar generated files, and that reminded me
that we need to have $srcdir in the generated #line reference back to
the source for debugging, but don't want it for comments in bfd.pot
(because then bfd.pot will likely reference Nick's source tree).
This patch fixes that by making all the #line use $srcdir by virtue of
using $<, and edits bfd.pot.
I also uniq list of files to remove duplicated elfxx-x86.c, sort lists
of files and regen with our standard automake/autoconf.
* configure: Regenerate.
bfd/
* Makefile.am: Sort various lists of files. Use $< in #line
directive of generated C files.
(po/SRC-POTFILES.in): uniq SRC_POTFILES.
(po/BLD-POTFILES.in): uniq BFD_POTFILES.
* Makefile.in: Regenerate.
* po/Make-in (bfd.pot): Edit out source dir from comments.
* po/SRC-POTFILES.in: Regenerate.
gas/
* Makefile.in: Regenerate.
* configure: Regenerate.
* po/POTFILES.in: Regenerate.
ld/
* Makefile.am (ALL_64_EMULATION_SOURCES): Sort.
* Makefile.in: Regenerate.
Alan Modra [Wed, 16 Aug 2023 13:12:44 +0000 (22:42 +0930)]
Re: sim frv: Add a missing return value for frvbf_check_acc_range.
Commit f00b50d057 went the wrong way. As the comment says this
function is only applicable to fr550. If not fr550 return 1,
meaning we don't have acc restrictions.
When building gdb with -std=c++20, I run into:
...
gdbsupport/default-init-alloc.h:52:12: error: ‘construct’ has not been \
declared in ‘class std::allocator<unsigned char>’
52 | using A::construct;
| ^~~~~~~~~
...
Indeed, std::allocator::construct has been deprecated in c++17 and removed in
c++20.
Fix this by using instead std::pmr::polymorphic_allocator for c++20.
Tom de Vries [Thu, 17 Aug 2023 08:41:34 +0000 (10:41 +0200)]
[gdb/build, c++20] Fix invalid conversion in test_symbols
When building gdb with -std=c++20, I run into:
...
gdb/dwarf2/read.c:2709:3: error: invalid conversion from ‘const char8_t*’ to \
‘const char*’ [-fpermissive]
2709 | u8"u8função",
| ^~~~~~~~~~~~
| |
| const char8_t*
...
Tom de Vries [Thu, 17 Aug 2023 08:41:34 +0000 (10:41 +0200)]
[gdb/build, c++20] Fix deprecated implicit capture of this
When building gdb with -std=c++20 I run into:
...
gdb/ada-lang.c:10713:16: error: implicit capture of ‘this’ via ‘[=]’ is \
deprecated in C++20 [-Werror=deprecated]
10713 | auto do_op = [=] (LONGEST x, LONGEST y)
| ^
gdb/ada-lang.c:10713:16: note: add explicit ‘this’ or ‘*this’ capture
...
Tom de Vries [Thu, 17 Aug 2023 08:41:34 +0000 (10:41 +0200)]
[gdb/build, c++20] Fix DISABLE_COPY_AND_ASSIGN use in ui_out_emit_type
When building gdb with -std=c++20, I run into:
...
include/ansidecl.h:342:9: error: expected unqualified-id before ‘const’
342 | TYPE (const TYPE&) = delete; \
| ^~~~~
gdb/ui-out.h:412:3: note: in expansion of macro ‘DISABLE_COPY_AND_ASSIGN’
412 | DISABLE_COPY_AND_ASSIGN (ui_out_emit_type<Type>);
| ^~~~~~~~~~~~~~~~~~~~~~~
...
Fix this by using "DISABLE_COPY_AND_ASSIGN (ui_out_emit_type)".
Tom de Vries [Thu, 17 Aug 2023 08:41:34 +0000 (10:41 +0200)]
[gdb/build, c++20] Stop using deprecated is_pod
When building gdb with clang 15 and -std=c++20, I run into:
...
gdbsupport/poison.h:52:11: error: 'is_pod<timeval>' is deprecated: use \
is_standard_layout && is_trivial instead [-Werror,-Wdeprecated-declarations]
std::is_pod<T>>
^
...
When building gdb with clang 15 and -std=c++20, I run into:
...
gdbsupport/common-exceptions.h:203:32: error: arithmetic between different \
enumeration types ('const enum return_reason' and 'const enum errors') is \
deprecated [-Werror,-Wdeprecated-enum-enum-conversion]
size_t result = exc.reason + exc.error;
~~~~~~~~~~ ^ ~~~~~~~~~
...
Tom de Vries [Thu, 17 Aug 2023 08:21:18 +0000 (10:21 +0200)]
[gdb/testsuite] Fix copy-to-remote in gdb.base/vfork-follow-parent.exp
When running test-case gdb.base/vfork-follow-parent.exp, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.base/vfork-follow-parent.exp.
ERROR: error copying "vforked-prog": no such file or directory
while executing
"file copy -force $fromfile $tofile"
(procedure "gdb_remote_download" line 29)
invoked from within
"gdb_remote_download target $binfile3"
...
Fix this by:
- making the copy-to-remote conditional on is_remote target, and
- allowing gdb_remote_download to find $binfile3 by using
standard_output_file.
Jose E. Marchesi [Thu, 17 Aug 2023 07:38:37 +0000 (09:38 +0200)]
bpf: gas: consolidate handling of immediate overflows
This commit changes the BPF GAS port in order to handle immediate
overflows the same way than the clang BPF assembler:
- For an immediate field of N bits, any written number (positive or
negative) whose two's complement encoding fit in N its is accepted.
This means that -2 is the same than 0xffffffe. It is up to the
instructions to decide how to interpret the encoded value.
- Immediate fields in jump instructions are no longer relaxed.
Relaxing to jump instructions with wider range is only performed
when expressions are involved.
- The manual is updated to document this, and testsuite adapted
accordingly.
Tested in x86_64-linux-gnu host, bpf-unknown-none target.
gas/ChangeLog:
2023-08-17 Jose E. Marchesi <jose.marchesi@oracle.com>
* config/tc-bpf.c (check_immediate_overflow): New function.
(encode_insn): Use check_immediate_overflow.
(md_assemble): Do not relax instructions with
constant disp16 fields.
* doc/c-bpf.texi (BPF Instructions): Add note about how numerical
literal values are interpreted for instruction immediate operands.
* testsuite/gas/bpf/disp16-overflow.s: Adapt accordingly.
* testsuite/gas/bpf/jump-relax-jump.s: Likewise.
* testsuite/gas/bpf/jump-relax-jump.d: Likewise.
* testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
* testsuite/gas/bpf/jump-relax-ja.s: Likewise.
* testsuite/gas/bpf/jump-relax-ja.d: Likewise.
* testsuite/gas/bpf/jump-relax-ja-be.d: Likewise.
* testsuite/gas/bpf/disp16-overflow-relax.l: Likewise.
* testsuite/gas/bpf/imm32-overflow.s: Likewise.
* testsuite/gas/bpf/disp32-overflow.s: Likewise.
* testsuite/gas/bpf/disp16-overflow.l: Likewise.
* testsuite/gas/bpf/disp32-overflow.l: Likewise.
* testsuite/gas/bpf/imm32-overflow.l: Likewise.
* testsuite/gas/bpf/offset16-overflow.l: Likewise.
Tom de Vries [Wed, 16 Aug 2023 21:43:25 +0000 (23:43 +0200)]
[gdb/symtab] Handle self-reference DIE
While working on a dwarf assembly test-case I accidentally created the
following pathological dwarf:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xbe>
...
and noticed gdb segfaulting during cooked index creating due to running out of
stack. This is a regression from gdb-12, where gdb just hung.
Fix this by inhibiting the scan_attributes self-recursion for self-references.
The same test-case with -readnow makes gdb hang, so also fix this in
dwarf2_attr and follow_die_ref.
Note that this doesn't fix the same problems for the more complicated case of:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xc6>
<1><c6>: Abbrev Number: 4 (DW_TAG_class_type)
<c7> DW_AT_name : c2
<ca> DW_AT_specification: <0xbe>
...
but the approach for deciding whether to fix pathological dwarf cases is as
per PR27981 comment 3:
...
yes if it is cheap/obvious, and no if it is something complicated or expensive.
...
and at this point I'm not sure whether fixing this will fall in the first
category.
Tom Tromey [Wed, 16 Aug 2023 17:29:19 +0000 (11:29 -0600)]
Avoid buffer overflow in ada_decode
A bug report pointed out a buffer overflow in ada_decode, which Keith
helpfully analyzed. ada_decode had a logic error when the input was
all digits. While this isn't valid -- and would probably only appear
in fuzzer tests -- it still should be handled properly.
This patch adds a missing bounds check. Tested with the self-tests in
an asan build.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30639 Reviewed-by: Keith Seitz <keiths@redhat.com>
Tom Tromey [Tue, 15 Aug 2023 17:04:17 +0000 (11:04 -0600)]
Fix obvious bug in aggregate expression
I found an obvious bug in Ada aggregate expression handling:
if (vvo != nullptr)
error (_("Invalid record component association."));
name = vvo->get_symbol ()->natural_name ();
Here the code errors when vvo is not null -- and then proceeds to use
vvo.
This hasn't caused a crash because, I believe, there's currently no
way to reach this code in the null case. However, I'm not really
willing to assert this...
Fixing this shows another bug, which is that due to the way the parser
works, a field name in an aggregate expression might erroneously be
fully qualified if some global variable with the same base name
exists.
The included test case triggers both bugs. Note that the test
includes a confounding case for array aggregates as well, but as these
are harder to fix, I've left it as kfail.
As this is Ada-specific, and has already been tested internally at
AdaCore, I am checking it in.
Andrew Burgess [Mon, 14 Aug 2023 20:53:57 +0000 (21:53 +0100)]
gdb/testsuite: fix race condition in gdb.python/py-thread-exited.exp
I ran into a test failure on gdb.python/py-thread-exited.c. The test
creates two threads and then catches the thread exits in Python. The
test expects the threads to exit in a specific order.
As the test is currently written, it is _likely_, but not guaranteed,
that the threads will exit in the same order they are created, which
is what the test expects.
When running on a loaded system I ran into a case where the threads
exited in the reverse creation order, which caused the test to fail.
I could fix this by having the .exp file not care about the thread
order, or by changing the C file to force the order. I chose the
later, and added a pthread_barrier_t to ensure the threads exit in the
correct order.
There should be no change in what is tested after this commit.
gdb: don't resume vfork parent while child is still running
the test gdb.base/vfork-follow-parent.exp now has some failures when
run with the native-gdbserver or native-extended-gdbserver boards:
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2 (timeout)
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1 (timeout)
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: print unblock_parent = 1 (timeout)
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (timeout)
The reason that these failures don't show up when run on the standard
unix board is that the test is only run in the default operating mode,
so for Linux this will be all-stop on top of non-stop.
If we adjust the test script so that it runs in the default mode and
with target-non-stop turned off, then we see the same failures on the
unix board. This commit includes this change.
The way that the test is written means that it is not (currently)
possible to turn on non-stop mode and have the test still work, so
this commit does not do that.
I have also updated the test script so that the vfork child performs
an exec as well as the current exit. Exec and exit are the two ways
in which a vfork child can release the vfork parent, so testing both
of these cases is useful I think.
In this test the inferior performs a vfork and the vfork-child
immediately exits. The vfork-parent will wait for the vfork-child and
then blocks waiting for gdb. Once gdb has released the vfork-parent,
the vfork-parent also exits.
In the test that fails, GDB sets 'detach-on-fork off' and then runs to
the vfork. At this point the test tries to just "continue", but this
fails as the vfork-parent is still selected, and the parent can't
continue until the vfork-child completes. As the vfork-child is
stopped by GDB the parent will never stop once resumed, so GDB refuses
to resume it.
The test script then sets 'schedule-multiple on' and once again
continues. This time GDB, in theory, resumes both the parent and the
child, the parent will be held blocked by the kernel, but the child
will run until it exits, and which point GDB stops again, this time
with inferior 2, the newly exited vfork-child, selected.
What happens after this in the test script is irrelevant as far as
this failure is concerned.
To understand why the test started failing we should consider the
behaviour of four different cases:
1. All-stop-on-non-stop before commit b1e0126ec56e,
2. All-stop-on-non-stop after commit b1e0126ec56e,
3. All-stop-on-all-stop before commit b1e0126ec56e, and
4. All-stop-on-all-stop after commit b1e0126ec56e.
Only case #4 is failing after commit b1e0126ec56e, but I think the
other cases are interesting because, (a) they inform how we might fix
the regression, and (b) it turns out the behaviour of #2 changed too
with the commit, but the change was harmless.
For #1 All-stop-on-non-stop before commit b1e0126ec56e, what happens
is:
1. GDB calls proceed with the vfork-parent selected, as schedule
multiple is on user_visible_resume_ptid returns -1 (everything)
as the resume_ptid (see proceed function),
2. As this is all-stop-on-non-stop, every thread is resumed
individually, so GDB tries to resume both the vfork-parent and the
vfork-child, both of which succeed,
3. The vfork-parent is held stopped by the kernel,
4. The vfork-child completes (exits) at which point the GDB sees the
EXITED event for the vfork-child and the VFORK_DONE event for the
vfork-parent,
5. At this point we might take two paths depending on which event
GDB handles first, if GDB handles the VFORK_DONE first then:
(a) As GDB is controlling both parent and child the VFORK_DONE is
ignored (see handle_vfork_done), the vfork-parent will be
resumed,
(b) GDB processes the EXITED event, selects the (now defunct)
vfork-child, and stops, returning control to the user.
Alternatively, if GDB selects the EXITED event first then:
(c) GDB processes the EXITED event, selects the (now defunct)
vfork-child, and stops, returning control to the user.
(d) At some future time the user resumes the vfork-parent, at
which point the VFORK_DONE is reported to GDB, however, GDB
is ignoring the VFORK_DONE (see handle_vfork_done), so the
parent is resumed.
For case #2, all-stop-on-non-stop after commit b1e0126ec56e, the
important difference is in step (2) above, now, instead of resuming
both the vfork-parent and the vfork-child, only the vfork-child is
resumed. As such, when we get to step (5), only a single event, the
EXITED event is reported.
GDB handles the EXITED just as in (5)(c), then, later, when the user
resumes the vfork-parent, the VFORKED_DONE is immediately delivered
from the kernel, but this is ignored just as in (5)(d), and so,
though the pattern of when the vfork-parent is resumed changes, the
overall pattern of which events are reported and when, doesn't
actually change. In fact, by not resuming the vfork-parent, the order
of events (in this test) is now deterministic, which (maybe?) is a
good thing.
If we now consider case #3, all-stop-on-all-stop before commit b1e0126ec56e, then what happens is:
1. GDB calls proceed with the vfork-parent selected, as schedule
multiple is on user_visible_resume_ptid returns -1 (everything)
as the resume_ptid (see proceed function),
2. As this is all-stop-on-all-stop, the resume is passed down to the
linux-nat target, the vfork-parent is the event thread, while the
vfork-child is a sibling of the event thread,
3. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
for all threads, this causes the vfork-child to be resumed. Then
in linux_nat_target::resume, the event thread, the vfork-parent,
is also resumed.
4. The vfork-parent is held stopped by the kernel,
5. The vfork-child completes (exits) at which point the GDB sees the
EXITED event for the vfork-child and the VFORK_DONE event for the
vfork-parent,
6. We are now in a situation identical to step (5) as for
all-stop-on-non-stop above, GDB selects one of the events to
handle, and whichever we select the user sees the correct
behaviour.
And so, finally, we can consider #4, all-stop-on-all-stop after commit b1e0126ec56e, this is the case that started failing.
We start out just like above, in proceed, the resume_ptid is
-1 (resume everything), due to schedule multiple being on. And just
like above, due to the target being all-stop, we call
proceed_resume_thread_checked just once, for the current thread,
which, remember, is the vfork-parent thread.
The change in commit b1e0126ec56e was to avoid resuming a vfork-parent
thread, read the commit message for the justification for this change.
However, this means that GDB now rejects resuming the vfork-parent in
this case, which means that nothing gets resumed! Obviously, if
nothing resumes, then nothing will ever stop, and so GDB appears to
hang.
I considered a couple of solutions which, in the end, I didn't go
with, these were:
1. Move the vfork-parent check out of proceed_resume_thread_checked,
and place it in proceed, but only on the all-stop-on-non-stop
path, this should still address the issue seen in b1e0126ec56e,
but would avoid the issue seen here. I rejected this just
because it didn't feel great to split the checks that exist in
proceed_resume_thread_checked like this,
2. Extend the condition in proceed_resume_thread_checked by adding a
target_is_non_stop_p check. This would have the same effect as
idea 1, but leaves all the checks in the same place, which I
think would be better, but this still just didn't feel right to
me, and so,
What I noticed was that for the all-stop-on-non-stop, after commit b1e0126ec56e, we only resumed the vfork-child, and this seems fine.
The vfork-parent isn't going to run anyway (the kernel will hold it
back), so if feels like we there's no harm in just waiting for the
child to complete, and then resuming the parent.
So then I started looking at follow_fork, which is called from the top
of proceed. This function already has the task of switching between
the parent and child based on which the user wishes to follow. So, I
wondered, could we use this to switch to the vfork-child in the case
that we are attached to both?
Turns out this is pretty simple to do.
Having done that, now the process is for all-stop-on-all-stop after
commit b1e0126ec56e, and with this new fix is:
1. GDB calls proceed with the vfork-parent selected, but,
2. In follow_fork, and follow_fork_inferior, GDB switches the
selected thread to be that of the vfork-child,
3. Back in proceed user_visible_resume_ptid returns -1 (everything)
as the resume_ptid still, but now,
4. When GDB calls proceed_resume_thread_checked, the vfork-child is
the current selected thread, this is not a vfork-parent, and so
GDB allows the proceed to continue to the linux-nat target,
5. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
for all threads, this does not resume the vfork-parent (because
it is a vfork-parent), and then the vfork-child is resumed as
this is the event thread,
At this point we are back in the same situation as for
all-stop-on-non-stop after commit b1e0126ec56e, that is, the
vfork-child is resumed, while the vfork-parent is held stopped by
GDB.
Eventually the vfork-child will exit or exec, at which point the
vfork-parent will be resumed.
Puputti, Matti [Wed, 26 Jul 2023 12:29:15 +0000 (12:29 +0000)]
gdb, infcmd: support jump command in multi-inferior case
Fixes the issue where jump failed if multiple inferiors run the same
source.
See the below example
$ gdb -q ./simple
Reading symbols from ./simple...
(gdb) break 2
Breakpoint 1 at 0x114e: file simple.c, line 2.
(gdb) run
Starting program: /temp/simple
Breakpoint 1, main () at simple.c:2
2 int a = 42;
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (native)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) info inferiors
Num Description Connection Executable
1 process 6250 1 (native) /temp/simple
* 2 <null> 1 (native)
(gdb) file ./simple
Reading symbols from ./simple...
(gdb) run
Starting program: /temp/simple
Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2
2 int a = 42;
(gdb) info inferiors
Num Description Connection Executable
1 process 6250 1 (native) /temp/simple
* 2 process 6705 1 (native) /temp/simple
(gdb) jump 3
Unreasonable jump request
(gdb)
In this example, jump fails because the debugger finds two different
locations, one for each inferior.
Solution is to limit the search to the current program space.
This is done by having the jump_command function use
decode_line_with_current_source rather than
decode_line_with_last_displayed, which makes sense,
the *_current_source function always looks up a location based on the
current thread's location -- if a user is asking the current thread to
jump, then surely their destination should be relative to where the
current thread is located.
Then, inside decode_line_with_current_source, the call to
decode_line_1 is updated to pass through the current program_space,
which will limit the returned locations to those in the current
program space.
Tom Tromey [Mon, 14 Aug 2023 18:06:12 +0000 (12:06 -0600)]
Mention process_stratum in inferior::priv comment
From what I can tell, inferior::priv is reserved for the
process_stratum target. It seems to me that it has to be, because
currenlty only such targets use it, and if a target at another stratum
started using this field, then conflicts could occur. This patch
documents this.
Tsukasa OI [Tue, 27 Dec 2022 03:14:02 +0000 (03:14 +0000)]
RISC-V: Make T-Head testing pattern more generic
On some T-Head vendor extensions, we test against the constant 18446744073709551615 (2**64-1) to detect invalid immediate errors on -1.
However, it heavily depends on the fact that the value used to print
immediate value is a 64-bit unsigned type and this constant is not (and
should not be) important (we just want to know that -1 is not valid).
This commit replaces all such occurrences of 18446744073709551615 with
a more generic regular expression.
Tsukasa OI [Sat, 12 Aug 2023 16:14:04 +0000 (16:14 +0000)]
RISC-V: Make "fli.h" available to 'Zvfh' + 'Zfa'
The documentation of the 'Zfa' extension states that "fli.h" is available
"if the Zfh or Zvfh extension is implemented" (both the latest and the
oldest editions are checked).
This fact was not reflected in Binutils ('Zvfh' implies 'Zfhmin', not full
'Zfh' extension and "fli.h" required 'Zfh' and 'Zfa' extensions).
This commit makes "fli.h" also available when both 'Zfa' and 'Zvfh'
extensions are implemented.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add new
instruction class handling.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zfa-zvfh.s: New test.
* testsuite/gas/riscv/zfa-zvfh.d: Ditto.
include/ChangeLog:
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
class.
opcodes/ChangeLog:
* riscv-opc.c (riscv_opcodes): Change instruction class of "fli.h"
from INSN_CLASS_ZFH_AND_ZFA to new INSN_CLASS_ZFH_OR_ZVFH_AND_ZFA.
Tsukasa OI [Mon, 24 Jul 2023 02:45:29 +0000 (02:45 +0000)]
RISC-V: Add support for the 'Zihintntl' extension
This commit adds 'Zihintntl' extension and its hint instructions.
This is based on:
<https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6da7791d5a733c553e6e2506ddcab5>,
the first ISA Manual noting that the 'Zihintntl' extension is ratified.
Note that compressed 'Zihintntl' hints require either 'C' or
'Zca' extension.
Co-authored-by: Nelson Chu <nelson@rivosinc.com>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_supported_std_z_ext): Add 'Zihintntl'
standard hint 'Z' extension.
(riscv_multi_subset_supports): Support new instruction classes.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zihintntl.s: New test for 'Zihintntl'
including auto-compression without C prefix and explicit C prefix.
* testsuite/gas/riscv/zihintntl.d: Likewise.
* testsuite/gas/riscv/zihintntl-na.d: Likewise.
* testsuite/gas/riscv/zihintntl-base.s: New test for correspondence
between 'Zihintntl' and base 'I' or 'C' instructions.
* testsuite/gas/riscv/zihintntl-base.d: Likewise.
Jan Beulich [Tue, 15 Aug 2023 06:34:56 +0000 (08:34 +0200)]
RISC-V: remove indirection from register tables
The longest register name is 4 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also reduces the
number of base relocations in the final image.
To avoid old gcc, when generating 32-bit code, bogusly warning about
bounds being exceeded in the code processing Cs/Cw, Ct/Cx, and CD,
an adjustment to EXTRACT_BITS() is needed: This macro shouldn't supply
a 64-bit value, and it also doesn't need to - all operand fields to
date are far more narrow than 32 bits. This in turn allows dropping a
number of casts elsewhere.
Jan Beulich [Tue, 15 Aug 2023 06:34:13 +0000 (08:34 +0200)]
PPC: remove indirection from struct pd_reg
The longest register name is 5 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also reduces the
number of base relocations in the final image.
Tom de Vries [Mon, 14 Aug 2023 20:52:52 +0000 (22:52 +0200)]
[gdb/build] Fix YYSTYPE and yyalloc odr violation
When building gdb with -O2 -flto I run into:
...
ada-exp.c.tmp:576:7: error: type ‘union YYSTYPE’ violates the C++ One \
Definition Rule [-Werror=odr]
...
Fix this by renaming to ada_exp_YYSTYPE and likewise for other .y files.
Likewise for yyalloc.
Tested on x86_64-linux. Also tested with byacc rather than bison on
suggestion of Tom Tromey.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
John Baldwin [Mon, 14 Aug 2023 20:38:42 +0000 (13:38 -0700)]
fbsd-nat: Stop a process if it is running before killing it.
In addition, detach from any child processes implicitly attached to by
the kernel due to fork following that have not yet been processed by
GDB's core.
John Baldwin [Mon, 14 Aug 2023 20:38:42 +0000 (13:38 -0700)]
fbsd-nat: Fix thread_alive against a running thread.
FreeBSD's ptrace fails requests with EBUSY against a running process.
Report that the thread is alive instead of dead if ptrace fails with
EBUSY.
This fixes an internal error in the gdb.threads/detach-step-over.exp
test where one process was detached while a thread in a second process
was being stepped. The core incorrectly assumed the stepping thread
had vanished and discarded the pending stepping state. When the
thread later reported a SIGTRAP from completing the step, this
triggered an assertion.
projects / thirdparty / binutils-gdb.git / log
