Nick Clifton [Tue, 5 Dec 2023 15:18:40 +0000 (15:18 +0000)]
Fix: strip --strip-debug breaks relocations
PR 31106
* elfcode.h (elf_write_relocs): Do not convert a relocation against a zero-value absolute symbol into a relocation without a symbol if the symbol is being used for a complex relocation.
Mike Frysinger [Tue, 5 Dec 2023 13:09:49 +0000 (06:09 -0700)]
sim: mips: fix sim_fpu usage
Fix some of the sim_fpu calls to use the right types. While I'm
not familiar with the MIPS ISA in these cases, these look like
simple oversights due to the name/type mismatches. This at least
fixes compiling with -Wenum-conversion.
Mike Frysinger [Tue, 5 Dec 2023 13:05:19 +0000 (06:05 -0700)]
sim: sh: trim trailing whitespace in generated code
No functional change here, but makes it a little easier to read the
generated code when editors aren't highlighting all the spurious
trailing whitespace on lines.
Mike Frysinger [Tue, 5 Dec 2023 12:56:52 +0000 (07:56 -0500)]
sim: mn10300: fix sim_engine_halt call
The sim_stop argument is an enum and should only be one of those
values, not a signal constant. Fix the logic to pass the right
sim_xxx & SIM_xxx values in the right arguments.
This is aimed at fixing holes in two alpha-ecoff relocation functions
that access section contents without first bounds checking offsets.
I've also rewritten ALPHA_R_OP_STORE handling to support writing to
the bytes near the end of the section.
* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Don't
bother checking ALPHA_R_LITERAL insn. Range check before reading
contents for ALPHA_R_GPDISP, and simplify handling. Rewrite
ALPHA_R_OP_STORE handling. Correct error callback args.
(alpha_relocate_section): Similarly. Don't abort, report errors.
Alan Modra [Tue, 5 Dec 2023 06:01:13 +0000 (16:31 +1030)]
Don't use free_contents in _bfd_elf_slurp_version_tables
In commit 7ac6d0c38c36 I made more use of free_contents in
_bfd_elf_slurp_version_tables, a variable added to tag the case where
raw verneed and verdefs have been read locally by the function, and
thus should be freed before returning. In retrospect it may have been
better to do without the extra variable entirely. It's easy to infer
when "contents" should be freed, costing a little extra on an error
path but costing less elsewhere.
* elf.c (_bfd_elf_slurp_version_tables): Don't use free_contents.
Mike Frysinger [Tue, 5 Dec 2023 04:43:51 +0000 (23:43 -0500)]
sim: warnings: enable only for development builds
Reuse the bfd/development.sh script like most other project to
determine whether the current source tree is a dev build (e.g.
git) or a release build, and disable the warnings for releases.
Mike Frysinger [Tue, 5 Dec 2023 04:40:05 +0000 (23:40 -0500)]
sim: ppc: fix implicit enum conversion
This code tries to use attach_type enums as hw_phb_decode, and while
they're setup to have compatible values, the compiler doesn't like it
when the cast is missing. So cast it explicitly and then use that.
sim/ppc/hw_phb.c:322:28: error:
implicit conversion from enumeration type 'attach_type'
(aka 'enum _attach_type') to different enumeration type
'hw_phb_decode' [-Werror,-Wenum-conversion]
Mike Frysinger [Tue, 5 Dec 2023 04:32:51 +0000 (23:32 -0500)]
sim: ppc: cleanup getrusage decls
Don't conflate HAVE_GETRUSAGE & HAVE_SYS_RESOURCE_H. Use the latter
to include the header and nothing else. Use the former to determine
whether to use the function and nothing else. If we find a system
that doesn't follow POSIX and provides only one of these, we can
figure out how to support it then. The manual local definition is
clashing with the system ones and leading to build failures with
newer C standards.
sim/ppc/emul_netbsd.c:51:5: error: a function declaration without a
prototype is deprecated in all versions of C and is treated as a
zero-parameter prototype in C2x, conflicting with a previous
declaration [-Werror,-Wdeprecated-non-prototype]
Alan Modra [Sun, 3 Dec 2023 22:18:34 +0000 (08:48 +1030)]
aarch64-elf: FAIL: indirect call stub to BTI stub relaxation
aarch64-elf fails the ld-aarch64/bfd-far-3.d test, due to the stubs
being emitted in a different order to that of aarch64-linux. They are
emitted in a different order due to stub names for local symbols
having the section id in the stub name. aarch64-linux-ld generates
one more section than aarch64-elf-ld. That section is .gnu.hash. So
the stub names differ and are hashed to different slots in
stub_hash_table.
Fix this by running the test with --hash-style=sysv, and adjust
expected output. I've also changed the branch over stubs emitted at
the start of a group of stubs to not care about the symbol, for all
groups not just the one that needed changing.
Ciaran Woodward [Mon, 4 Dec 2023 18:49:26 +0000 (18:49 +0000)]
[gdb/doc] Escape the '@' symbols in generated texinfo files.
'@' is a special symbol meaning 'command' in GNU texinfo.
If the GDBINIT or GDBINIT_DIR path during configuration
included an '@' character, the makeinfo command would fail,
as it interpreted the '@' in the path as a start of a command
when expanding the path in the docs.
This patch simply escapes any '@' characters in the path,
by replacing them with '@@'. This was already done for the
bugurl variable.
This was detected because the 'Jenkins' tool sometimes puts
an '@' in the workspace path.
Tom Tromey [Mon, 4 Dec 2023 14:48:42 +0000 (07:48 -0700)]
Fix two buglets in .debug_names dumping
While working on gdb's .debug_names writer, I found a couple of small
bugs in binutils .debug_names dumping.
First, the DWARF spec (section 6.1.1.4.6 Name Table) says:
These two arrays are indexed starting at 1, [...]
I think it is clearer for binutils to follow this, particularly
because DW_IDX_parent refers to this number.
Second, I think the handling of an empty hash table is slightly wrong.
Currently the dumping code assumes there is always an array of hashes.
However, section 6.1.1.4.5 Hash Lookup Table says:
The optional hash lookup table immediately follows the list of
type signatures.
and then:
The hash lookup table is actually two separate arrays: an array of
buckets, followed immediately by an array of hashes.
My reading of this is that the hash table as a whole is optional, and
so the hashes will not exist in this case. (This also makes sense
because the hashes are not useful without the buckets anyway.)
This patch fixes both of these problems. FWIW I have some gdb patches
in progress that change gdb both to omit the hash table and to use
DW_IDX_parent.
2023-12-04 Tom Tromey <tom@tromey.com>
* dwarf.c (display_debug_names): Handle empty .debug_names hash
table. Name entries start at 1.
Jens Remus [Wed, 29 Nov 2023 20:44:34 +0000 (21:44 +0100)]
s390: Support for jump visualization in disassembly
Add support for jump visualization for the s390 architecture in
disassembly:
objdump -d --visualize-jumps ...
Annotate the (conditional) jump and branch relative instructions with
information required for jump visualization:
- jump: Unconditional jump / branch relative.
- condjump: Conditional jump / branch relative.
- jumpsr: Jump / branch relative to subroutine.
Unconditional jump and branch relative instructions are annotated as
jump.
Conditional jump and branch relative instructions, jump / branch
relative on count/index, and compare and jump / branch relative
instructions are annotated as condjump.
Jump and save (jas, jasl) and branch relative and save (bras, brasl)
instructions are annotated as jumpsr (jump to subroutine).
Provide instruction information required for jump visualization during
disassembly.
The instruction type is provided after determining the opcode.
For non-code it is set to dis_noninsn. Otherwise it defaults to
dis_nonbranch. No annotation is done for data reference instructions
(i.e. instruction types dis_dref and dis_dref2). Note that the
instruction type needs to be provided before printing of the
instruction, as it is used in print_address_func() to translate the
argument value into an address if it is assumed to be a PC-relative
offset. Note that this is never the case on s390, as
print_address_func() is only called with addresses and never with
offsets.
The target of the (conditional) jump and branch relative instructions
is provided during print, when the PC relative operand is decoded.
include/
* opcode/s390.h: Define opcode flags to annotate instruction
class information for jump visualization:
S390_INSTR_FLAG_CLASS_BRANCH, S390_INSTR_FLAG_CLASS_RELATIVE,
S390_INSTR_FLAG_CLASS_CONDITIONAL, and
S390_INSTR_FLAG_CLASS_SUBROUTINE.
Define opcode flags mask S390_INSTR_FLAG_CLASS_MASK for above
instruction class information.
Define helpers for common instruction class flag combinations:
S390_INSTR_FLAGS_CLASS_JUMP, S390_INSTR_FLAGS_CLASS_CONDJUMP,
and S390_INSTR_FLAGS_CLASS_JUMPSR.
opcodes/
* s390-mkopc.c: Add opcode flags to annotate information
for jump visualization: jump, condjump, and jumpsr.
* s390-opc.txt: Annotate (conditional) jump and branch relative
instructions with information for jump visualization.
* s390-dis.c (print_insn_s390, s390_print_insn_with_opcode):
Provide instruction information for jump visualization.
Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Richard Bunt [Mon, 4 Dec 2023 14:23:17 +0000 (14:23 +0000)]
gdb: Enable early init of thread pool size
This commit enables the early initialization commands (92e4e97a9f5) to
modify the number of threads used by gdb's thread pool.
The motivation here is to prevent gdb from spawning a detrimental number
of threads on many-core systems under environments with restrictive
ulimits.
With gdb before this commit, the thread pool takes the following sizes:
1. Thread pool size is initialized to 0.
2. After the maintenance commands are defined, the thread pool size is
set to the number of system cores (if it has not already been set).
3. Using early initialization commands, the thread pool size can be
changed using "maint set worker-threads".
4. After the first prompt, the thread pool size can be changed as in the
previous step.
Therefore after step 2. gdb has potentially launched hundreds of threads
on a many-core system.
After this change, step 2 and 3 are reversed so there is an opportunity
to set the required number of threads without needing to default to the
number of system cores first.
There does exist a configure option (added in 261b07488b9) to disable
multithreading, but this does not allow for an already deployed gdb to
be configured.
Additionally, the default number of worker threads is clamped at eight
to control the number of worker threads spawned on many-core systems.
This value was chosen as testing recorded on bugzilla issue 29959
indicates that parallel efficiency drops past this point.
GDB built with GCC 13.
No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel
LLVM, NVHPC; Platforms: x86_64, aarch64.
The scenario that interests me the most involves preventing GDB from
spawning any worker threads at all. This was tested by counting the
number of clones observed by strace:
The new test relies on "gdb: install CLI uiout while processing early
init files" developed by Andrew Burgess. This patch will need pushing
prior to this change.
The clamping was tested on machines with both 16 cores and a single
core. "maint show worker-threads" correctly reported eight and one
respectively.
Andrew Burgess [Mon, 4 Dec 2023 14:23:17 +0000 (14:23 +0000)]
gdb: install CLI uiout while processing early init files
The next commit wants to use a 'show' command within an early
initialisation file, despite these commands not being in the list of
acceptable commands for use within an early initialisation file.
The problem we run into is that the early initialisation files are
processed before GDB has installed the top level interpreter. The
interpreter is responsible to installing the default uiout (accessed
through current_uiout), and as a result code that depends on
uiout (e.g. 'show' commands) will end up dereferencing a nullptr, and
crashing GDB.
I did consider moving the interpreter installation before the early
initialisation, and this would work fine except for the new DAP
interpreter, which relies on having Python available during its
initialisation. Which means we can't install the interpreter until
after Python has been initialised, and the early initialisation
handling has to occur before Python is setup -- that's the whole point
of this feature (to allow customisation of how Python is setup).
So, what I propose is that early within captured_main_1, we install a
temporary cli_ui_out as the current_uiout. This will remain in place
until the top-level interpreter is installed, at which point the
temporary will be replaced.
What this means is that current_uiout will no longer be nullptr,
instead, any commands within an early initialisation file that trigger
output, will perform that output in a CLI style.
I propose that we don't update the documentation for early
initialisation files, we leave the user advice as being only 'set' and
'source' commands are acceptable. But now, if a user does try a
'show' command, then instead of crashing, GDB will do something
predictable.
I've not added a test in this commit. The next commit relies on this
patch and will serve as a test.
Tom de Vries [Mon, 4 Dec 2023 07:48:48 +0000 (08:48 +0100)]
[gdb/tui] Fix wrapping strings
I noticed that after resizing to a narrow window, I got:
...
┌────────────────┐
│ │
│[ No Source Avail
able ] │
│ │
└────────────────┘
...
Fix this by adding two new functions:
- tui_win_info::display_string (int y, int x, const char *str)
- tui_win_info::display_string (const char *str)
that make sure that borders are not overwritten, which get us instead:
...
┌────────────────┐
│ │
│[ No Source Avai│
│ │
│ │
└────────────────┘
...
Kevin Buettner [Sun, 3 Dec 2023 03:25:31 +0000 (20:25 -0700)]
Fix detach bug when lwp has exited/terminated
When using GDB on native linux, it can happen that, while attempting
to detach an inferior, the inferior may have been exited or have been
killed, yet still be in the list of lwps. Should that happen, the
assert in x86_linux_update_debug_registers in
gdb/nat/x86-linux-dregs.c will trigger. The line in question looks
like this:
gdb_assert (lwp_is_stopped (lwp));
For this case, the lwp isn't stopped - it's dead.
The bug which brought this problem to my attention is one in which the
pwntools library uses GDB to to debug a process; as the script is
shutting things down, it kills the process that GDB is debugging and
also sends GDB a SIGTERM signal, which causes GDB to detach all
inferiors prior to exiting. Here's a link to the bug:
The following shell command mimics part of what the pwntools
reproducer script does (with regard to shutting things down), but
reproduces the bug much less reliably. I have found it necessary to
run the command a bunch of times before seeing the bug. (I usually
see it within 5-10 repetitions.) If you choose to try this command,
make sure that you have no running "cat" or "gdb" processes first!
So, basically, the idea here is to kill both gdb and cat at roughly
the same time. If we happen to attempt the detach before the process
lwp has been deleted from GDB's (linux native) LWP data structures,
then the assert will trigger. The relevant part of the backtrace
looks like this:
#8 0x00000000008a83ae in x86_linux_update_debug_registers (lwp=0x1873280)
at gdb/nat/x86-linux-dregs.c:146
#9 0x00000000008a862f in x86_linux_prepare_to_resume (lwp=0x1873280)
at gdb/nat/x86-linux.c:81
#10 0x000000000048ea42 in x86_linux_nat_target::low_prepare_to_resume (
this=0x121eee0 <the_amd64_linux_nat_target>, lwp=0x1873280)
at gdb/x86-linux-nat.h:70
#11 0x000000000081a452 in detach_one_lwp (lp=0x1873280, signo_p=0x7fff8ca3441c)
at gdb/linux-nat.c:1374
#12 0x000000000081a85f in linux_nat_target::detach (
this=0x121eee0 <the_amd64_linux_nat_target>, inf=0x16e8f70, from_tty=0)
at gdb/linux-nat.c:1450
#13 0x000000000083a23b in thread_db_target::detach (
this=0x1206ae0 <the_thread_db_target>, inf=0x16e8f70, from_tty=0)
at gdb/linux-thread-db.c:1385
#14 0x0000000000a66722 in target_detach (inf=0x16e8f70, from_tty=0)
at gdb/target.c:2526
#15 0x0000000000a8f0ad in kill_or_detach (inf=0x16e8f70, from_tty=0)
at gdb/top.c:1659
#16 0x0000000000a8f4fa in quit_force (exit_arg=0x0, from_tty=0)
at gdb/top.c:1762
#17 0x000000000070829c in async_sigterm_handler (arg=0x0)
at gdb/event-top.c:1141
My colleague, Andrew Burgess, has done some recent work on other
problems with detach. Upon hearing of this problem, he came up a test
case which reliably reproduces the problem and tests for a few other
problems as well. In addition to testing detach when the inferior has
terminated due to a signal, it also tests detach when the inferior has
exited normally. Andrew observed that the linux-native-only
"checkpoint" command would be affected too, so the test also tests
those cases when there's an active checkpoint.
For the LWP exit / termination case with no checkpoint, that's handled
via newly added checks of the waitstatus in detach_one_lwp in
linux-nat.c.
For the checkpoint detach problem, I chose to pass the lwp_info
to linux_fork_detach in linux-fork.c. With that in place, suitable
tests were added before attempting a PTRACE_DETACH operation.
I added a few asserts at the beginning of linux_fork_detach and
modified the caller code so that the newly added asserts shouldn't
trigger. (That's what the 'pid == inferior_ptid.pid' check is about
in gdb/linux-nat.c.)
Lastly, I'll note that the checkpoint code needs some work with regard
to background execution. This patch doesn't attempt to fix that
problem, but it doesn't make it any worse. It does slightly improve
the situation with detach because, due to the check noted above,
linux_fork_detach() won't be called for the wrong inferior when there
are multiple inferiors. (There are at least two other problems with
the checkpoint code when there are multiple inferiors. See:
https://sourceware.org/bugzilla/show_bug.cgi?id=31065)
This commit also adds a new test,
gdb.base/process-dies-while-detaching.exp. Andrew Burgess is the
primary author of this test case. Its design is similar to that of
gdb.threads/main-thread-exit-during-detach.exp, which was also written
by Andrew.
This test checks that GDB correctly handles several cases that can
occur when GDB attempts to detach an inferior process. The process
can exit or be terminated (e.g. via SIGKILL) prior to GDB's event
loop getting a chance to remove it from GDB's internal data
structures. To complicate things even more, detach works differently
when a checkpoint (created via GDB's "checkpoint" command) exists for
the inferior. This test checks all four possibilities: process exit
with no checkpoint, process termination with no checkpoint, process
exit with a checkpoint, and process termination with a checkpoint.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
ld/x86: reduce testsuite dependency on system object files
changed some C compiler tests to assembler/linker tests which introduced
2 problems:
1. It broke x32 binutils tests since --64 was passed to assembler, but
-m elf_x86_64 wasn't passed to linker.
2. -nostdlib was passed to C compiler driver to exclude standard run-time
files which should be avoided with -r option for linker tests.
Fix them by passing -m elf_x86_64 to linker and removing -nostdlib for
linker tests with -r.
PR ld/30722
* testsuite/ld-x86-64/x86-64.exp: Pass -m elf_x86_64 to linker
for tests with --64. Remove -nostdlib for tests with -r.
Tom Tromey [Fri, 8 Sep 2023 14:25:15 +0000 (08:25 -0600)]
Bail out of "attach" if a thread cannot be traced
On Linux, threads are treated much like separate processes by the
kernel. In particular, it's possible to ptrace just a single thread.
If gdb tries to attach to a multi-threaded inferior, where a non-main
thread is already being traced (e.g., by strace), then gdb will get
into an infinite loop attempting to attach.
This patch fixes this problem by having the attach fail if ptrace
fails to attach to any thread of the inferior.
Simon Marchi [Wed, 29 Nov 2023 16:35:23 +0000 (11:35 -0500)]
gdb: add missing regcache_map_entry array null terminators in aarch64-linux-tdep.c
Fix two spots in aarch64-linux-tdep.c that build regcache_map_entry
arrays without a null terminator. The null terminators are needed for
regcache::transfer_regset and regcache_map_entry_size to work properly.
Change-Id: I3224a314e1360b319438f32de8c81e70ab42e105 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com>
Simon Marchi [Tue, 28 Nov 2023 19:48:57 +0000 (14:48 -0500)]
gdb: return when exceeding buffer size in regcache::transfer_regset
regcache::transfer_regset iterates over an array of regcache_map_entry,
transferring the registers (between regcache and buffer) described by
those entries. It stops either when it reaches the end of the
regcache_map_entry array (marked by a null entry) or (it seems like the
intent is) when it reaches the end of the buffer (in which case not all
described registers are transferred).
I said "seems like the intent is", because there appears to be a small
bug. transfer_regset is made of two loops:
foreach regcache_map_entry:
foreach register described by the regcache_map_entry:
if the register doesn't fit in the remainder of the buffer:
break
transfer register
When stopping because we have reached the end of the buffer, the break
only breaks out of the inner loop.
This problem causes some failures when I run tests such as
gdb.arch/aarch64-sme-core-3.exp (on AArch64 Linux, in qemu). This is
partly due to aarch64_linux_iterate_over_regset_sections failing to add
a null terminator in its regcache_map_entry array, but I think there is
still a problem in transfer_regset.
The sequence to the crash is:
- The `regcache_map_entry za_regmap` object built in
aarch64_linux_iterate_over_regset_sections does not have a null
terminator.
- When the target does not have a ZA register,
aarch64_linux_collect_za_regset calls `regcache->collect_regset` with
a size of 0 (it's actually pointless, but still it should work).
- transfer_regset gets called with a buffer size of 0.
- transfer_regset detects that the register to transfer wouldn't fit in
0 bytes, so it breaks out of the inner loop.
- The outer loop tries to go read the next regcache_map_entry, but
there isn't one, and we start reading garbage.
Obviously, this would get fixed by making
aarch64_linux_iterate_over_regset_sections use a null terminator (which
is what the following patch does). But I think that when detecting that
there is not enough buffer left for the current register,
transfer_regset should return, not only break out of the inner loop.
This is a kind of contrived scenario, but imagine we have these two
regcache_map_entry objects:
- 2 registers of 8 bytes
- 2 registers of 4 bytes
For some reason, the caller passes a buffer of 12 bytes.
transfer_regset will detect that the second 8 byte register does not
fit, and break out of the inner loop. However, it will then go try the
next regcache_map_entry. It will see that it can fit one 4 byte
register in the remaining buffer space, and transfer it from/to there.
This is very likely not an expected behavior, we wouldn't expect to
read/write this sequence of registers from/to the buffer.
In this example, whether passing a 12 bytes buffer makes sense or
whether it is a size computation bug in the caller, we don't know, but I
think that exiting as soon as a register doesn't fit is the sane thing
to do.
Change-Id: Ia349627d2e5d281822ade92a8e7a4dea4f839e07 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Reviewed-By: Luis Machado <luis.machado@arm.com>
Tom Tromey [Thu, 30 Nov 2023 19:27:04 +0000 (12:27 -0700)]
Add link to Debugger Adapter Protocol node in documentation
I noticed that the interpreters node in the docs links to the DAP
protocol docs, but I thought the DAP node ought to as well. This
patch adds a bit of introductory text there.
Jeff Law [Fri, 1 Dec 2023 14:19:50 +0000 (07:19 -0700)]
Fix right shifts in mcore simulator on 64 bit hosts.
If the value to be shifted has the sign bit set, the sign
bit would get copied into bits 32..63 of the temporary. Those
would then be right shifted into the final value giving an
incorrect final result.
This was observed with upcoming GCC improvements which eliminate
unnecessary extensions.
gdb/testsuite: fix completion tests when using READ1
The commit a3da2e7e550c4fe79128b5e532dbb90df4d4f418 has introduced
regressions when testing using the READ1 mechanism. The reason for that
is the new failure path in proc test_gdb_complete_tab_unique, which
looks for GDB suggesting more than what the test inputted, but not the
correct answer, followed by a white space. Consider the following case:
int foo(int bar, int baz);
Sending the command "break foo<tab>" to GDB will return
break foo(int, int)
which easily fits the buffer in normal testing, so everything works, but
when reading one character at a time, the test will find the partial
"break foo(int, " and assume that there was a mistake, so we get a
spurious FAIL.
That change was added because we wanted to avoid forcing a completion
failure to fail through timeout, which it had to do because there is no
way to verify that the output is done, mostly because when I was trying
to solve a different problem I kept getting reading errors and testing
completion was frustrating.
This commit implements a better way to avoid that frustration, by first
testing gdb's complete command and only if that passes we will test tab
completion. The difference is that when testing with the complete
command, we can tell when the output is over when we receive the GDB
prompt again, so we don't need to rely on timeouts. With this, the
change to test_gdb_complete_tab_unique has been removed as that test
will only be run and fail in the very unlikely scenario that tab
completion is different than command completion.
Remove unnecessary returns and unused variables in AIX.
This is a patch to simplify the pd_activate () in aix-thread.c incase of a failure to start a thread session
, since pd_activate () now has return type void.
Also this patch fixes the shadow declarartion warning in sync-threadlists.
Jan Beulich [Fri, 1 Dec 2023 09:13:17 +0000 (10:13 +0100)]
binutils/Dwarf: avoid "shadowing" of glibc function name
Yet once again: Old enough glibc has an (unguarded) declaration of
index() in string.h, which triggers a "shadows a global declaration"
warning with at least some gcc versions.
Jan Beulich [Fri, 1 Dec 2023 07:29:11 +0000 (08:29 +0100)]
x86: adjust NOP generation after potential non-insn
Just like avoiding to do certain transformations potentially affected by
stand-alone prefixes or direct data emission, also avoid emitting
optimized NOPs right afterwards; insert a plain old NOP first in such
cases.
Jan Beulich [Fri, 1 Dec 2023 07:28:45 +0000 (08:28 +0100)]
x86: i386_cons_align() badly affects diagnostics
Warning without knowing what's going to follow isn't useful, the more
that appropriate warnings are emitted elsewhere in all cases. Not
updating state (file/line in particular) also isn't helpful, as it's
always the last directive ahead of a construct potentially needing
fiddling with that's "guilty" in that fiddling being suppressed.
Jan Beulich [Fri, 1 Dec 2023 07:28:20 +0000 (08:28 +0100)]
gas: no md_cons_align() for .nop{,s}
.nop and .nops generate code, not data. Hence them invoking
md_cons_align() is at best inappropriate. In fact it actually gets in
the of x86'es state maintenance involving i386_cons_align().
Jan Beulich [Fri, 1 Dec 2023 07:27:49 +0000 (08:27 +0100)]
x86: suppress optimization after potential non-insn
Just like avoiding to do other transformations potentially affected by
stand-alone prefixes or direct data emission, also avoid optimization
on the following insn.
Jan Beulich [Fri, 1 Dec 2023 07:27:22 +0000 (08:27 +0100)]
x86: last-insn recording should be per-section
Otherwise intermediate section switches result in inconsistent behavior.
Note, however, that intermediate sub-section switches will continue to
result in inconsistent or even inappropriate behavior.
While there also add recording of state to s_insn().
Jan Beulich [Fri, 1 Dec 2023 07:26:36 +0000 (08:26 +0100)]
x86: allow 32-bit reg to be used with U{RD,WR}MSR
... as MSR index specifier: It is unreasonable to demand that people
write less readable / understandable code, just because the present
documentation mentions only Reg64. Whether to also adjust the
disassembler is a separate question, perhaps indeed more tightly tied
to what the spec says.
Patrick O'Neill [Fri, 1 Dec 2023 02:47:39 +0000 (18:47 -0800)]
RISC-V: Make riscv_is_mapping_symbol stricter
riscv_is_mapping_symbol currently accepts any symbol that starts with $x
or $d. This patch makes the check more strict, requiring exactly $x, $d,
or $xrv. It also makes use of this stricter mapping in
riscv_is_valid_mapping_symbol.
ChangeLog:
* bfd/cpu-riscv.c (riscv_elf_is_mapping_symbols): Match only
strings that are exactly $x, $d, or $xrv.
* opcodes/riscv-dis.c (riscv_is_valid_mapping_symbol): Use
riscv_elf_is_mapping_symbols.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Back then when the support for the RISC-V vector crypto extensions
was merged, the specification was frozen, but not ratified.
A frozen specification is allowed to change within tight bounds
before ratification and this has happend with the vector crypto
extensions.
The following changes were applied:
* A new extension Zvkb was defined, which is a strict subset of Zvbb.
* Zvkn and Zvks include now Zvkb instead of Zvbb.
This patch implements these changes between the frozen and the
ratified specification.
Note, that this technically an incompatible change of Zvkn and Zvks,
but I am not aware of any project that depends on the currently
implemented behaviour of Zvkn and Zvks. So this patch should be fine.
Reported-By: Jerry Shih <jerry.shih@sifive.com> Reported-By: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Tom de Vries [Thu, 30 Nov 2023 20:31:46 +0000 (21:31 +0100)]
[gdb/build] Fix adding -DNDEBUG to python flags of release build
In gdb/configure the line:
...
$development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
...
intends to ensure that -DNDEBUG is added to the python flags of a release
build.
However, when building gdb-14-branch we have:
...
configure:22024: checking compiler flags for python code
...
configure:22047: result: -fno-strict-aliasing -fwrapv
...
This is a regression since commit db6878ac553 ("Move sourcing of development.sh
to GDB_AC_COMMON"), which introduced a reference before assignment:
...
$development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
...
. $srcdir/../bfd/development.sh
...
and consequently -DNDEBUG is never added.
[ This was not obvious to me, but apparently evaluating an empty or undefined
variable in this context is similar to using ':' or 'true', so the line is
evaluated as:
...
true || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
... ]
Fix this by moving GDB_AC_COMMON up in gdb/configure.ac, similar to how that
was done for gdbserver/configure.ac in commit db6878ac553.
[ Unfortunately, the move might introduce issues similar to the one we're
fixing, and I'm not sure how to check for this. Shellcheck doesn't detect
this type of problem. FWIW, I did run shellcheck (using arguments -xa, in the
src/gdb directory to make sure ../bfd/development.sh is taken into account)
before and after and observed that the number of lines/words/chars in the
shellcheck output is identical. ]
Build & tested on top of trunk.
Also build on top of gdb-14-branch, and observed this in gdb/config.log:
...
configure:25214: checking compiler flags for python code
...
configure:25237: result: -fno-strict-aliasing -fwrapv -DNDEBUG
...
Approved-By: Tom Tromey <tom@tromey.com>
PR build/31099
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31099
YunQiang Su [Fri, 24 Nov 2023 06:35:12 +0000 (14:35 +0800)]
MIPS/GAS: Add -march=loongson2f to loongson-2f-3 test
On MIPSr6, the encoding of JR instruction has been chaned.
This patch can fix these failures for r6 default triples:
ST Microelectronics Loongson-2F workarounds of Jump Instruction issue
Rainer Orth [Thu, 30 Nov 2023 09:46:25 +0000 (10:46 +0100)]
Fix procfs.c compilation
procfs.c doesn't currently compile on Solaris:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual int procfs_target::can_use_hw_breakpoint(bptype, int, int)’:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3017:9: error: ‘ptr_type’ was not declared in this scope; did you mean ‘var_types’?
3017 | type *ptr_type
| ^~~~~~~~
| var_types
Patrick O'Neill [Thu, 30 Nov 2023 03:55:20 +0000 (19:55 -0800)]
RISC-V: Avoid updating state until symbol is found
Currently objdump gets and updates the map state once per symbol. Updating the
state (partiularly riscv_parse_subset) is expensive and grows quadratically
since we iterate over all symbols. By deferring this until once we've found the
symbol of interest, we can reduce the time to dump a 4k insn file of .norvc and
.rvc insns from ~47 seconds to ~0.13 seconds.
opcodes/ChangeLog:
* riscv-dis.c (riscv_get_map_state): Remove state updating logic
and rename to riscv_is_valid_mapping_symbol.
(riscv_update_map_state): Add state updating logic to seperate function.
(riscv_search_mapping_symbol): Use new riscv_update_map_state.
(riscv_data_length): Ditto.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Jose E. Marchesi [Thu, 30 Nov 2023 07:34:09 +0000 (08:34 +0100)]
gas: support double-slash line comments in BPF assembly
This patch makes the BPF assembler to support double-slash line
comments, like the llvm BPF assembler does. At this point both
assemblers support the same commenting styles:
- Line comments preceded by # or //.
- Non-nestable block comments delimited by /* and */.
This patch also adds a couple of tests to make sure all the comment
styles work in both normal and pseudoc syntax. The manual is also
updated to mention double-slash line comments.
Tom Tromey [Mon, 16 Oct 2023 19:36:03 +0000 (13:36 -0600)]
Switch to -Wimplicit-fallthrough=5
This changes the various gdb-related directories to use
-Wimplicit-fallthrough=5, meaning that only the fallthrough attribute
can be used in switches -- special 'fallthrough' comments will no
longer be usable.
Tom Tromey [Sun, 15 Oct 2023 17:09:07 +0000 (11:09 -0600)]
Use C++17 [[fallthrough]] attribute
This changes gdb to use the C++17 [[fallthrough]] attribute rather
than special comments.
This was mostly done by script, but I neglected a few spellings and so
also fixed it up by hand.
I suspect this fixes the bug mentioned below, by switching to a
standard approach that, presumably, clang supports.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
gprofng: support GNU option syntax in gp-display-html, plus various fixes
This is a major update of gp-display-html. The option handling has been
modified to support the GNU style long option syntax. Compatibility with
the previous syntax has been preserved. If still used, a warning is issued.
Through the --nowarnings option, this can be suppressed.
In addition to this, various lay-out changes have been implemented. In
particular to reduce the number of lines that extend beyond column 79.
Several bugs have been fixed, for example in the handling of directory names.
gprofng/ChangeLog
2023-11-28 Ruud van der Pas <ruud.vanderpas@oracle.com>
* gp-display-html/gp-display-html.in: Change option syntax plus fixes.
This is a major update of all the man pages. Bugs 30679 and 30895 are
addressed. In addition to fixes for typos, the texts have been expanded
and clarified, and line lengths no longer extend beyond column 79. In
case of gp-display-html, the new option syntax is documented. The user
guide has a new section on the gprofng GUI.
gprofng/ChangeLog
2023-11-28 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR 30679
PR 30895
* doc/gp-archive.texi: Expand the description of the options.
* doc/gp-collect-app.texi: Fix various typos and textual improvements.
* doc/gp-display-html.texi: Cover the new GNU long option syntax.
* doc/gp-display-src.texi: Fix various typos and textual improvements.
* doc/gp-display-text.texi: Fix typos fixed and textual improvements.
* doc/gp-macros.texi: Fix a bug in the vspace macro and add new macro.
* doc/gprofng.texi: Cover the GPROFNG_SYSCONFDIR environment variable.
* doc/gprofng_ug.texi: Fix various typos and textual improvements.
* doc/version.texi: Adapt the date and version number.
Andrew Burgess [Mon, 27 Nov 2023 21:29:53 +0000 (21:29 +0000)]
gdb/python: display errors from command completion
This commit makes the gdb.Command.complete methods more verbose when
it comes to error handling.
Previous to this commit if any commands implemented in Python
implemented the complete method, and if there were any errors
encountered when calling that complete method, then GDB would silently
hide the error and continue as if there were no completions.
This makes is difficult to debug any errors encountered when writing
completion methods, and encourages the idea that Python extensions can
be broken, and GDB will just silently work around them.
I don't think this is a good idea. GDB should encourage extensions to
be written correctly, and robustly, and one way in which GDB can (I
think) support this, is by pointing out when an extension goes wrong.
In this commit I've gone through the Python command completion code,
and added calls to gdbpy_print_stack() or gdbpy_print_stack_or_quit()
in places where we were either clearing the Python error, or, in some
cases, just not handling the error at all.
One thing I have not changed is in cmdpy_completer (py-cmd.c) where we
process the list of completions returned from the Command.complete
method; this routine includes a call to gdbpy_is_string to check a
possible completion is a string, if not the completion is ignored.
I was tempted to remove this check, attempt to complete each result to
a string, and display an error if the conversion fails. After all,
returning anything but a string is surely a mistake by the extension
author.
However, the docs clearly say that only strings within the returned
list will be considered as completions. Anything else is ignored. As
such, and to avoid (what I think is pretty unlikely) breakage of
existing code, I've retained the gdbpy_is_string check.
After the gdbpy_is_string check we call python_string_to_host_string,
if this call fails then I do now print the error, where before we
ignored the error. I think this is OK; if GDB thinks something is a
string, but still can't convert it to a string, then I think it's OK
to display the error in that case.
Another case which I was a little unsure about was in
cmdpy_completer_helper, and the call to PyObject_CallMethodObjArgs,
which is when we actually call Command.complete. Previously, if this
call resulted in an exception then we would ignore this and just
pretend there were no completions.
Of all the changes, this is possibly the one with the biggest
potential for breaking existing scripts, but also, is, I think, the
most useful change. If the user code is wrong in some way, such that
an exception is raised, then previously the user would have no obvious
feedback about this breakage. Now GDB will print the exception for
them, making it, I think, much easier to debug their extension. But,
if there is user code in the wild that relies on raising an exception
as a means to indicate there are no completions .... well, that code
is going to break after this commit. I think we can live with this
though, the exceptions means no completions thing was never documented
behaviour.
I also added a new error() call if the PyObject_CallMethodObjArgs call
raises an exception. This causes the completion mechanism within GDB
to stop. Within GDB the completion code is called twice, the first
time to compute the work break characters, and then a second time to
compute the actual completions.
If PyObject_CallMethodObjArgs raises an exception when computing the
word break character, and we print it by calling
gdbpy_print_stack_or_quit(), but then carry on as if
PyObject_CallMethodObjArgs had returns no completions, GDB will
call the Python completion code again, which results in another call
to PyObject_CallMethodObjArgs, which might raise the same exception
again. This results in the Python exception being printed twice.
By throwing a C++ exception after the failed
PyObject_CallMethodObjArgs call, the completion mechanism is aborted,
and no completions are offered. But importantly, the Python exception
is only printed once. I think this gives a much better user
experience.
I've added some tests to cover this case, as I think this is the most
likely case that a user will run into.
gdb: generate gdb-index identically regardless of work thread count
In this commit I added a new proc in testsuite/lib/gdb.exp called
gdb_get_worker_threads. This proc uses gdb_test_multiple with two
possible patterns. One pattern is anchored with '^', while the other
is missing the '^' which it could use.
Simon Marchi [Tue, 28 Nov 2023 17:25:07 +0000 (12:25 -0500)]
gdb: fix call to breakpoint_inserted_here_p in darwin-nat.c
Fixes this issue, introduced by f9582a22dba7 ("[gdb] Fix segfault in
for_each_block, part 1"):
CXX darwin-nat.o
/Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1169:7: error: no matching function for call to 'breakpoint_inserted_here_p'
if (breakpoint_inserted_here_p (inf->aspace, pc))
^~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Tromey [Fri, 6 Oct 2023 20:30:46 +0000 (14:30 -0600)]
Emit DAP "process" event
DAP specifies a "process" event that is sent when a process is started
or attached to. gdb was not emitting this (several DAP clients appear
to ignore it entirely), but it looked easy and harmless to implement.
Tom de Vries [Tue, 28 Nov 2023 15:31:07 +0000 (16:31 +0100)]
[gdb/tui] Use const std::string for string literals in tui-stack.c
I noticed in gdb/tui/tui-stack.c a source-level micro-optimization where
strlen with a string literal argument:
...
strlen ("bla")
...
is replaced with sizeof:
...
sizeof ("bla") - 1
...
The benefit of this is that the optimization is also done at O0, but the
drawback is that it makes the expression harder to read.
Use const std::string to encapsulate the string literals, and use
std::string::size () instead.
I tried making the string names (PROC_PREFIX, LINE_PREFIX, PC_PREFIX and
SINGLE_KEY) lower-case, but that clashed with a pre-existing pc_prefix, so
I've left them upper-case.
Tested on x86_64-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Jose E. Marchesi [Tue, 28 Nov 2023 13:59:38 +0000 (14:59 +0100)]
sim: bpf: do not use semicolon to begin comments
The BPF assembler has been updated to follow the clang convention in
the interpretation of semicolons: they separate statements and
directives, and do not start line comments.
Jakub Jelinek [Tue, 28 Nov 2023 12:29:58 +0000 (13:29 +0100)]
libiberty, ld: Use x86 HW optimized sha1
The following patch attempts to use x86 SHA ISA if available to speed
up in my testing about 2.5x sha1 build-id processing (in my case on
AMD Ryzen 5 3600) while producing the same result.
I believe AArch64 has similar HW acceleration for SHA1, perhaps it
could be added similarly.
Note, seems lld uses BLAKE3 rather than md5/sha1. I think it would be
a bad idea to lie to users, if they choose --buildid=sha1, we should
be using SHA1, not some other checksum, but perhaps we could add some other
--buildid= styles and perhaps make one of the new the default.
Tested on x86_64-linux, both on Intel i9-7960X (which doesn't have
sha_ni ISA support) without/with the patch and on AMD Ryzen 5 3600
(which does have it) without/with the patch.
2023-11-28 Jakub Jelinek <jakub@redhat.com>
include/
* sha1.h (sha1_process_bytes_fn): New typedef.
(sha1_choose_process_bytes): Declare.
libiberty/
* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): New check.
* sha1.c: If HAVE_X86_SHA1_HW_SUPPORT is defined, include x86intrin.h
and cpuid.h.
(sha1_hw_process_bytes, sha1_hw_process_block,
sha1_choose_process_bytes): New functions.
* config.in: Regenerated.
* configure: Regenerated.
ld/
* ldbuildid.c (generate_build_id): Use sha1_choose_process_bytes ()
instead of &sha1_process_bytes.
Andrew Burgess [Thu, 26 Oct 2023 11:05:06 +0000 (12:05 +0100)]
gdb/testsuite: add a new check-all-boards target
The make-check-all.sh script (gdb/testsuite/make-check-all.sh) is
great, it makes it super easy to run some test(s) using all the
available board files.
This commit aims to make this script even easier to access by adding a
check-all-boards target to the GDB Makefile. This new target checks
for (and requires) a number of environment variables, so the target
should be used like this:
make check-all-boards GDB_TARGET_USERNAME=remote-target \
GDB_HOST_USERNAME=remote-host \
TESTS="gdb.base/break.exp"
Where GDB_TARGET_USERNAME and GDB_HOST_USERNAME are the user names
that should be passed to the make-check-all.sh --target-user and
--host-user command line options respectively.
My personal intention is to set these variables in my environment, so
all I'll need to do is:
make check-all-boards TESTS="gdb.base/break.exp"
The make rule always passes --keep-results to the make-check-all.sh
script, as I find that the most useful. It's super frustrating to run
the tests and realise you forgot that option and the results have been
discarded.
Andrew Burgess [Tue, 7 Nov 2023 18:11:13 +0000 (18:11 +0000)]
gdb/testsuite: log 'make check' command in make-check-all.sh
I have been making more use of the make-check-all.sh script to run
tests against all boards.
But one thing is pretty annoying. When a test fails on some random
board, I have to run make-check-all.sh with --verbose and --dry-run in
order to see what RUNTESTFLAGS I should be using.
I always run with --keep-results on, so, in this commit, I propose
that, when --keep-results is on the 'make check' command will be
written out to a file within the stored results directory, like:
Andrew Burgess [Mon, 27 Nov 2023 13:19:39 +0000 (13:19 +0000)]
gdb: generate dwarf-5 index identically as worker-thread count changes
Similar to the previous commit, this commit ensures that the dwarf-5
index files are generated identically as the number of worker-threads
changes.
Building the dwarf-5 index makes use of a closed hash table, the
bucket_hash local within debug_names::build(). Entries are added to
bucket_hash from m_name_to_value_set, which, in turn, is populated
by calls to debug_names::insert() in write_debug_names. The insert
calls are ordered based on the entries within the cooked_index, and
the ordering within cooked_index depends on the number of worker
threads that GDB is using.
My proposal is to sort each chain within the bucket_hash closed hash
table prior to using this to build the dwarf-5 index.
The buckets within bucket_hash will always have the same ordering (for
a given GDB build with a given executable), and by sorting the chains
within each bucket, we can be sure that GDB will see each entry in a
deterministic order.
I've extended the index creation test to cover this case.
Andrew Burgess [Fri, 24 Nov 2023 12:04:36 +0000 (12:04 +0000)]
gdb: generate gdb-index identically regardless of work thread count
It was observed that changing the number of worker threads that GDB
uses (maintenance set worker-threads NUM) would have an impact on the
layout of the generated gdb-index.
The cause seems to be how the CU are distributed between threads, and
then symbols that appear in multiple CU can be encountered earlier or
later depending on whether a particular CU moves between threads.
I certainly found this behaviour was reproducible when generating an
index for GDB itself, like:
And then setting different values for NUM will change the generated
index.
Now, the question is: does this matter?
I would like to suggest that yes, this does matter. At Red Hat we
generate a gdb-index as part of the build process, and we would
ideally like to have reproducible builds: for the same source,
compiled with the same tool-chain, we should get the exact same output
binary. And we do .... except for the index.
Now we could simply force GDB to only use a single worker thread when
we build the index, but, I don't think the idea of reproducible builds
is that strange, so I think we should ensure that our generated
indexes are always reproducible.
To achieve this, I propose that we add an extra step when building the
gdb-index file. After constructing the initial symbol hash table
contents, we will pull all the symbols out of the hash, sort them,
then re-insert them in sorted order. This will ensure that the
structure of the generated hash will remain consistent (given the same
set of symbols).
I've extended the existing index-file test to check that the generated
index doesn't change if we adjust the number of worker threads used.
Given that this test is already rather slow, I've only made one change
to the worker-thread count. Maybe this test should be changed to use
a smaller binary, which is quicker to load, and for which we could
then try many different worker thread counts.
Andrew Burgess [Sat, 25 Nov 2023 10:35:37 +0000 (10:35 +0000)]
gdb: C++-ify mapped_symtab from dwarf2/index-write.c
Make static the functions add_index_entry, find_slot, and hash_expand,
member functions of the mapped_symtab class.
Fold an additional snippet of code from write_gdbindex into
mapped_symtab::minimize, this code relates to minimisation, so this
seems like a good home for it.
Make the n_elements, data, and m_string_obstack member variables of
mapped_symtab private. Provide a new obstack() member function to
provide access to the obstack when needed, and also add member
functions begin(), end(), cbegin(), and cend() so that the
mapped_symtab class can be treated like a contained and iterated
over.
I've also taken this opportunity to split out the logic for whether
the hash table (m_data) needs expanding, this is the new function
hash_needs_expanding. This will be useful in a later commit.
There should be no user visible changes after this commit.
Andrew Burgess [Fri, 24 Nov 2023 11:50:35 +0000 (11:50 +0000)]
gdb: reduce size of generated gdb-index file
I noticed in passing that out algorithm for generating the gdb-index
file is incorrect. When building the hash table in add_index_entry we
count every incoming entry rehash when the number of entries gets too
large. However, some of the incoming entries will be duplicates,
which don't actually result in new items being added to the hash
table.
As a result, we grow the gdb-index hash table far too often.
With an unmodified GDB, generating a gdb-index for GDB, I see a file
size of 90M, with a hash usage (in the generated index file) of just
2.6%.
With a patched GDB, generating a gdb-index for the _same_ GDB binary,
I now see a gdb-index file size of 30M, with a hash usage of 41.9%.
This is a 67% reduction in gdb-index file size.
Obviously, not every gdb-index file is going to see such big savings,
however, the larger a program, and the more symbols that are
duplicated between compilation units, the more GDB would over count,
and so, over-grow the index.
The gdb-index hash table we create has a minimum size of 1024, and
then we grow the hash when it is 75% full, doubling the hash table at
that time. Given this, then we expect that either:
a. The hash table is size 1024, and less than 75% full, or
b. The hash table is between 37.5% and 75% full.
I've include a test that checks some of these constraints -- I've not
bothered to check the upper limit, and over full hash table isn't
really a problem here, but if the fill percentage is less than 37.5%
then this indicates that we've done something wrong (obviously, I also
check for the 1024 minimum size).
Andrew Burgess [Fri, 24 Nov 2023 11:10:08 +0000 (11:10 +0000)]
gdb/testsuite: small refactor in selftest-support.exp
Split out the code that makes a copy of the GDB executable ready for
self testing into a new proc. A later commit in this series wants to
load the GDB executable into GDB (for creating an on-disk debug
index), but doesn't need to make use of the full do_self_tests proc.
There should be no changes in what is tested after this commit.
Andrew Burgess [Mon, 27 Nov 2023 14:34:57 +0000 (14:34 +0000)]
gdb: option completion for 'save gdb-index' command
Add proper support for option completion to the 'save gdb-index'
command. Update save_gdb_index_command function to make use of the
new option_def data structures for parsing the '-dwarf-5' option.
projects / thirdparty / binutils-gdb.git / log
