This commit follows on from the following two commits:
commit 80dc83fd0e
Date: Fri Jun 11 11:30:47 2021 +0100
gdb/remote: handle target dying just before a stepi
And:
commit 079f190d4c
Date: Thu Mar 9 10:45:03 2023 +0100
[gdb/testsuite] Fix gdb.server/server-kill.exp for remote target
The first of these commits fixed an issue in GDB and tried to extend
the gdb.server/server-kill.exp test to cover the GDB fix.
Unfortunately, the changes to gdb.server/server-kill.exp were not
correct, and were causing problems when trying to run with the
remote-gdbserver-on-localhost board file.
The second commit reverts some of the gdb.server/server-kill.exp
changes introduced in the first commit so that the test will now work
correctly with the remote-gdbserver-on-localhost board file.
The second commit is just about GDB's testing infrastructure -- it's
not about the original fix to GDB from the first commit, the actual
GDB change was fine.
While reviewing the second commit I wanted to check that the problem
fixed in the first commit is still being tested by the
gdb.server/server-kill.exp script, so I reverted the change to
breakpoint.c that is the core of the first commit and ran the test
script ..... and saw no failures.
The first commit is about GDB discovering that gdbserver has died
while trying to insert a breakpoint. As soon as GDB spots that
gdbserver is gone we mourn the remote inferior, which ends up deleting
all the breakpoints associated with the remote inferiors. We then
throw an exception which is caught in the insert breakpoints code, and
we try to display an error that includes the breakpoint number
.... but the breakpoint has already been deleted ... and so GDB
crashes.
After digging a little, what I found is that today, when the test does
'stepi' the first thing we end up doing is calculating the frame-id as
part of the stepi logic, it is during this frame-id calculation that
we mourn the remote inferior, delete the breakpoints, and throw an
exception. The exception is caught by the top level interpreter loop,
and so we never try to print the breakpoint number which is what
caused the original crash.
If I add an 'info frame' command to the test script, prior to killing
gdbserver, then now when we 'stepi' GDB already has the frame-id
calculated, and the first thing we do is try to insert the
breakpoints, this will trigger the original bug.
In order to reproduce this experiment you'll need to change a function
in breakpoint.c, like this:
static void
rethrow_on_target_close_error (const gdb_exception &e)
{
return;
}
Then run gdb.server/server-kill.exp with and without this patch. You
should find that without this patch there are zero test failures,
while with this patch there will be one failure like this:
(gdb) PASS: gdb.server/server-kill.exp: test_stepi: info frame
Executing on target: kill -9 4513 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 4513
stepi
../../src/gdb/breakpoint.c:2863: internal-error: insert_bp_location: Assertion `bl->owner != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
...
A potential test failure was introduced with commit:
commit 6bf5f25bb1
Date: Wed Mar 8 16:11:30 2023 +0000
gdb/python: make the gdb.unwinder.Unwinder class more robust
In this commit a new test was added, however the expected output
pattern varies depending on which Python version GDB is linked
against.
Older versions of Python result in output like this:
(gdb) python global_test_unwinder.name = "foo"
Traceback (most recent call last):
File "<string>", line 1, in <module>
AttributeError: can't set attribute
Error while executing Python code.
(gdb)
While more recent versions of Python give a similar, but slightly more
verbose error message, like this:
(gdb) python global_test_unwinder.name = "foo"
Traceback (most recent call last):
File "<string>", line 1, in <module>
AttributeError: can't set attribute 'name'
Error while executing Python code.
(gdb)
The test was only accepting the first version of the output. This
commit extends the test pattern so that either version will be
accepted.
The detection logic for TPIDR2 was implemented incorrectly. Originally
the detection was supposed to be through a ptrace error code, but in reality,
for backwards compatibility, the detection should be based on the size of
the returned iovec.
For instance, if a target supports both TPIDR and TPIDR2, ptrace will return a
iovec size of 16. If a target only supports TPIDR and not TPIDR2, it will
return a iovec size of 8, even if we asked for 16 bytes.
This patch fixes this issue in code that is shared between gdb and gdbserver,
therefore both gdb and gdbserver are fixed.
Tested on AArch64/Linux Ubuntu 20.04.
A case of a string section ending with an unterminated string. Fix it
by allocating one more byte and making it zero. Also make functions
reading the data return void* so that casts are not needed.
* ecoff.c (READ): Delete type param. Allocate one extra byte
to terminate string sections with a NUL. Adjust invocation.
* elfxx-mips.c (READ): Likewise.
* libbfd-in.h (_bfd_alloc_and_read): Return a void*.
(_bfd_malloc_and_read): Likewise.
* libbfd.h: Regenerate.
tc-aarch64.c:1473:27: runtime error: left shift of 7 by 30 places
cannot be represented in type 'int'.
* config/tc-aarch64.c (parse_vector_reg_list): Avoid UB left
shift.
This should sort out some very old FIXMEs in code handling stabs
debug info. Necessary if we are to fuss over freeing up memory before
objdump and objcopy exit. It is of course better from a user
viewpoint to *not* free memory, which takes some time, and leave that
to process exit. The only reason to do so is that having many memory
leaks in binutils/ code tends to hide leaks in bfd/ or opcodes/, which
we should care about.
* budbg.h (parse_stab): Update prototype.
* debug.h (debug_start_source): Update prototype.
* debug.c (debug_start_source): Add name_used. Set if stashed.
* rddbg.c (read_symbol_stabs_debugging_info): Always malloc
stab string passed to parse_stab. Free stab string when
unreferenced.
(read_section_stabs_debugging_info): Likewise, and strings
section contents.
* stabs.c (parse_stab): Add string_used param. Set if string
stashed. Pass to debug_start_source. Realloc file_types
array rather that using malloc. Clarify comment about
debug_make_indirect_type.
We may have added some abbrevs to the list before hitting an error.
Free the list elements too. free_abbrev_list returns list->next so we
need to init it earlier to avoid an uninitialised memory access.
* dwarf.c (process_abbrev_set): Call free_abbrev_list on errors.
Set list->next earlier.
I noticed the prefix parameter was unused in print_doc_of_command. And
when removing it, it becomes unused in apropos_cmd.
Change-Id: Id72980b03fe091b22931e6b85945f412b274ed5e
GDB expected PC should point right after the SVC instruction when the
syscall is active. But some active syscalls keep PC pointing to the SVC
instruction itself.
This leads to a broken backtrace like:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
#0 0xb6f8681c in pthread_cond_timedwait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1 0xb6e21f80 in ?? ()
The reason is that .ARM.exidx unwinder gives up if PC does not point
right after the SVC (syscall) instruction. I did not investigate why but
some syscalls will point PC to the SVC instruction itself. This happens
for the "futex" syscall used by pthread_cond_timedwait.
That normally does not matter as ARM prologue unwinder gets called
instead of the .ARM.exidx one. Unfortunately some glibc calls have more
complicated prologue where the GDB unwinder fails to properly determine
the return address (that is in fact an orthogonal GDB bug). I expect it
is due to the "vpush" there in this case but I did not investigate it more:
Dump of assembler code for function pthread_cond_timedwait@@GLIBC_2.4:
0xb6f8757c <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr}
0xb6f87580 <+4>: mov r10, r2
0xb6f87584 <+8>: vpush {d8}
Regression tested on armv7l kernel 5.15.32-v7l+ (Raspbian 11).
Approved-By: Luis Machado <luis.machado@arm.com>
Linker adds indirect symbols for versioned symbol aliases, which are
created by ".symver foo, foo@FOO", by checking symbol type, value and
section so that references to foo will be replaced by references to
foo@FOO if foo and foo@FOO have the same symbol type, value and section.
But in IR, since all symbols of the same type have the same value and
section, we can't tell if a symbol is an alias of another symbol by
their types, values and sections. We shouldn't add indirect symbols
for versioned symbol aliases in IR.
bfd/
PR ld/30281
* elflink.c (elf_link_add_object_symbols): Don't add indirect
symbols for ".symver foo, foo@FOO" aliases in IR.
ld/
PR ld/30281
* testsuite/ld-plugin/lto.exp: Add PR ld/30281 test.
* testsuite/ld-plugin/pr30281.t: New file.
* testsuite/ld-plugin/pr30281.c: Likewise.
A recent patch caused my system gcc (Fedora 36, so gcc 12.2.1) to warn
about sym_addr being possibly uninitialized in frame.c. It isn't, but
the compiler can't tell. So, this patch initializes the variable. I
also fixed a formatting buglet that I missed in review.
With test-case gdb.base/trace-commands.exp and editing off, I run into fails
because multi-line commands are issued using gdb_test_sequence, which
doesn't handle them correctly.
Fix this by using gdb_test instead.
Tested on x86_64-linux.
PR testsuite/30288
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288
With test-case gdb.threads/threadapply.exp and editing set to on, we have:
...
(gdb) define remove^M
Type commands for definition of "remove".^M
End with a line saying just "end".^M
>remove-inferiors 3^M
>end^M
(gdb)
...
but with editing set to off, we run into:
...
(gdb) define remove^M
Type commands for definition of "remove".^M
End with a line saying just "end".^M
>remove-inferiors 3^M
end^M
>(gdb) FAIL: gdb.threads/threadapply.exp: thread_set=all: try remove: \
define remove (timeout)
...
The commands are issued by this test:
...
gdb_define_cmd "remove" {
"remove-inferiors 3"
}
...
which does:
- gdb_test_multiple "define remove", followed by
- gdb_test_multiple "remove-inferiors 3\nend".
Proc gdb_test_multiple has special handling for multi-line commands, which
splits it up into subcommands, and for each subcommand issues it and then
waits for the resulting prompt (the secondary prompt ">" for all but the last
subcommand).
However, that doesn't work as expected in this case because the initial
gdb_test_multiple "define remove" fails to match all resulting output, and
consequently the secondary prompt resulting from "define remove" is counted as
if it was the one resulting from "remove-inferiors 3".
Fix this by matching the entire output of "define remove", including the
secondary prompt.
Tested on x86_64-linux.
PR testsuite/30288
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288
I noticed that language_demangle shadows the global
"current_language". When I went to fix this, though, I then saw that
language_demangle is only called in two places, and has a comment
saying it should be removed. This patch removes it. Note that the
NULL check in language_demangle is not needed by either of the
existing callers.
Regression tested on x86-64 Fedora 36.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries pointed out a bug in the index-cache background writer --
sometimes it will fail. He also noted that it fails when the number
of worker threads is set to zero. These turn out to be the same
problem -- the cache can't be written to until the per-BFD's
"index_table" member is set.
This patch avoids the race by rearranging the code slightly, to ensure
the cache cannot possibly be written before the member is set.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30261
Allow consumers of GDB to extract the name of the main method. This is
most useful for Fortran programs which have a variable main method.
Used by both MAP and DDT e.g. it is used to detect the presence of debug
information.
Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
Fix a functional regression and restore the handling of DW_CC_program
code of DW_AT_calling_convention attribute for determining the name of
the starting function of the program where the DW_AT_main_subprogram
attribute has not been provided, such as with Fortran code compiled with
GCC versions 4.5.4 and below, or where DWARF version 3 or below has been
requested. Without it "main" is considered the starting function. Cf.
GCC PR fortran/43414.
Original code was removed with commit 6209cde4dd ("Delete DWARF
psymtab code"), and then an update to complement commit 81873cc81e
("[gdb/symtab] Support DW_AT_main_subprogram with -readnow.") has also
been included here.
In the case where a Fortran program has a program name of "main" and
there is also a minimal symbol called main, such as with programs built
with GCC version 4.4.7 or below, the backtrace will erroneously stop at
the minimal symbol rather than the user specified main, e.g.:
(gdb) bt
#0 bar () at .../gdb/testsuite/gdb.fortran/backtrace.f90:17
#1 0x0000000000402556 in foo () at .../gdb/testsuite/gdb.fortran/backtrace.f90:21
#2 0x0000000000402575 in main () at .../gdb/testsuite/gdb.fortran/backtrace.f90:31
#3 0x00000000004025aa in main ()
(gdb)
This patch fixes this issue by increasing the precedence of the full
symbol when the language of the current frame is Fortran.
Newer versions of GCC transform the program name to "MAIN__" in this
case, avoiding the problem.
Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
This commit intends to move operands that require very special handling or
operand types that are so minor (e.g. only useful on a few instructions)
under "W". I also intend this "W" to be "temporary" operand storage until
we can find good two character (or less) operand type.
In this commit, prefetch offset operand "f" for 'Zicbop' extension is moved
to "Wif" because of its special handling (and allocating single character
"f" for this operand type seemed too much).
Current expected allocation guideline is as follows:
1. 'W'
2. The most closely related single-letter extension in lowercase
(strongly recommended but not mandatory)
3. Identify operand type
The author currently plans to allocate following three-character operand
types (for operands including instructions from unratified extensions).
1. "Wif" ('Zicbop': fetch offset)
2. "Wfv" (unratified 'Zfa': value operand from FLI.[HSDQ] instructions)
3. "Wfm" / "WfM"
'Zfh', 'F', 'D', 'Q': rounding modes "m" with special handling
solely for widening conversion instructions.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn, riscv_ip): Move from
"f" to "Wif".
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Move from "f" to "Wif".
* riscv-opc.c (riscv_opcodes): Reflect new operand type.
This can't be done for all insns currently encoded with .byte. For one
outside of 64-bit mode unused (typically ignored) register encoding bits
in VEX/XOP/EVEX prefixes can't be set to their non-default values, since
the necessary registers cannot be specified (and some of these bits
can't even be used outside of 64-bit mode). And then there are odd tests
like the first one in bad-bcast.s: Its purpose is to illegaly set EVEX.b
together with EVEX.W (which could be expressed; note though EVEX.W set
is invalid on its own), but then it also clears EVEX.B and EVEX.R' plus
it sets EVEX.vvvv to other than 0xf (rendering the test ambiguous,
because that's another #UD reason).
In {,x86-64-}disassem.s many bogus encodings exist - some with ModR/M
byte but insufficient displacement bytes, some using SIB encoding with
the SIB byte actually being the supposed immediate. Some of these could
be expressed by .insn, but I don't want to introduce bogus examples.
These will all need adjustment anyway once the disassembler is improved
in the way it deals with unrecognized encodings.
Generally generated code is meant to remain the same. {,x86-64-}nops.d
are exceptions because insn prefixes are emitted in a different order.
opcode{,-intel,-suffix}.d are also adjusted (along with an according
correction to opcode.s) to cover an apparent typo in the original tests
(xor when or was meant).
Where necessary --divide is added as gas option, to allow for the use
of the extension opcode functionality.
Comments are being adjusted where obviously wrong/misleading.
Since we have no insn suffix and it's also not realistic to infer
immediate size from the size of other (typically register) operands
(like optimize_imm() does), and since we also don't have a template
telling us permitted size(s), a new syntax construct is introduced to
allow size (and signedness) specification. In the absence of such, the
size is inferred from significant bits (which obviously may yield
inconsistent results at least for effectively negative values, depending
on whether BFD64 is enabled), and only if supplied expressions can be
evaluated at parsing time. Being explicit is generally recommended to
users.
Size specification is permitted at bit granularity, but of course the
eventually emitted immediate values will be padded up to 8-, 16-, 32-,
or 64-bit fields.
In particular the scaling factor cannot always be determined from pre-
existing operand attributes. Introduce a new {:d<N>} vector operand
syntax extension, restricted to .insn only, to allow specifying this in
(at least) otherwise ambiguous cases.
Deal with register and memory operands; immediate operands will follow
later, as will the handling of EVEX embedded broadcast and EVEX Disp8
scaling.
Note that because we can't really know how to encode their use, %cr8 and
up cannot be used with .insn outside of 64-bit mode. Users would need to
specify an explicit LOCK prefix in combination with %cr0 etc.
So called "short form" encoding is specified by a trailing "+r", whereas
a possible extension opcode is specified by the usual "/<digit>". Take
these off the expression before handing it to get_absolute_expression().
Note that on targets where / starts a comment, --divide needs passing to
gas in order to make use of the extension opcode functionality.
All encoding spaces can be used this way; there's a certain risk that
the bits presently reserved could be used for other purposes down the
road, but people using .insn are expected to know what they're doing
anyway. Plus this way there's at least _some_ way to have those bits
set.
For now this will only allow operand-less insns to be encoded this way.
While only a secondary issue there, the testcase of PR gas/27212 exposes
an oversight in relocation handling: Just like e.g. Arm32, which has a
similar comment and a similar check, relocations against STN_UNDEF have
to be permitted to satisfy the ELF spec.
PR 30219 shows an internal error due to a "Bad switch" in
print_exception() in gdb/exceptions.c. The switch in question
contains cases for RETURN_QUIT and RETURN_ERROR, but is missing a case
for the recently added RETURN_FORCED_QUIT. This commit adds that case.
Making the above change allows the errant test case to pass, but does
not fix the underlying problem, which I'll describe shortly. Even
though the addition of a case for RETURN_FORCED_QUIT isn't the actual
fix, I still think it's important to add this case so that other
situations which lead to print_exeption() being called won't generate
that "Bad switch" internal error.
In order to understand the underlying problem, please examine
this portion of the backtrace from the bug report:
0x5576e4ff5780 print_exception
/home/smarchi/src/binutils-gdb/gdb/exceptions.c:100
0x5576e4ff5930 exception_print(ui_file*, gdb_exception const&)
/home/smarchi/src/binutils-gdb/gdb/exceptions.c:110
0x5576e6a896dd quit_force(int*, int)
/home/smarchi/src/binutils-gdb/gdb/top.c:1849
The real problem is in quit_force; here's the try/catch which
eventually leads to the internal error:
/* Get out of tfind mode, and kill or detach all inferiors. */
try
{
disconnect_tracing ();
for (inferior *inf : all_inferiors ())
kill_or_detach (inf, from_tty);
}
catch (const gdb_exception &ex)
{
exception_print (gdb_stderr, ex);
}
While running the calls in the try-block, a QUIT check is being
performed. This check finds that sync_quit_force_run is (still) set,
causing a gdb_exception_forced_quit to be thrown. The exception
gdb_exception_forced_quit is derived from gdb_exception, causing
exception_print to be called. As shown by the backtrace,
print_exception is then called, leading to the internal error.
The actual fix, also implemented by this commit, is to clear
sync_quit_force_run along with the quit flag. This will allow the
various cleanup code, called by quit_force, to run without triggering
a gdb_exception_forced_quit. (Though, if another SIGTERM is sent to
the gdb process, these flags will be set again and a QUIT check in the
cleanup code will detect it and throw the exception.)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30219
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This patch adds the RPRFM (range prefetch) instruction.
It was introduced as part of SME2, but it belongs to the
prefetch hint space and so doesn't require any specific
ISA flags.
The aarch64_rprfmop_array initialiser (deliberately) only
fills in the leading non-null elements.
This patch adds the SVE FDOT, SDOT and UDOT instructions,
which are available when FEAT_SME2 is implemented. The patch
also reorders the existing SVE_Zm3_22_INDEX to keep the
operands numerically sorted.
This patch adds SUNPK and UUNPK, which unpack one register's
worth of elements to two registers' worth, or two registers'
worth to four registers' worth.
There are two instruction formats here:
- SQRSHR, SQRSHRU and UQRSHR, which operate on lists of two
or four registers.
- SQRSHRN, SQRSHRUN and UQRSHRN, which operate on lists of
four registers.
These are the first SME2 instructions to have immediate operands.
The patch makes sure that, when parsing SME2 instructions with
immediate operands, the new predicate-as-counter registers are
parsed as registers rather than as #-less immediates.
There are two instruction formats here:
- SQCVT, SQCVTU and UQCVT, which operate on lists of two or
four registers.
- SQCVTN, SQCVTUN and UQCVTN, which operate on lists of
four registers.
This patch adds the SME2 versions of the FP<->integer conversion
instructions FCVT* and *CVTF. It also adds FP rounding instructions
FRINT*, which share the same format.
