PR c++/28901 points out a bug in C++ overload resolution. When
comparing two overloads, one might be better than the other for
certain parameters -- but, if that one also has some invalid
conversion, then it should never be considered the better choice.
Instead, a valid-but-not-apparently-quite-as-good overload should be
preferred.
This patch fixes this problem by changing how overload comparisons are
done. I don't believe it should affect any currently valid overload
resolution; nor should it affect resolutions where all the choices are
equally invalid.
Currently we report errors as "unrecognized opcode `fence.i'" when the
opcode isn't part of the selected extensions.
This patch expands that error message to include the missing extension
information. For example, now the error message would be "unrecognized
opcode `fence.i', extension `zifencei' required".
If the opcode is not a part of any extension, the error message reverts
to "unrecognized opcode `<op statement>'".
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
bfd/
pr 28733
* elfxx-riscv.c (riscv_multi_subset_supports_ext): New function,
used to return the extension string for each INSN_CLASS_*.
* elfxx-riscv.h: Added extern riscv_multi_subset_supports_ext.
gas/
pr 28733
* config/tc-riscv.c (struct riscv_ip_error): New structure,
contains information about errors that occur within the riscv_ip.
(riscv_ip): Use struct riscv_ip_error to report more detailed errors.
* testsuite/gas/riscv/c-fld-fsd-fail.l: Updated.
* testsuite/gas/riscv/march-imply-i2p1-01.: Likewise.
Currently we report errors as "invalid CSR 'fscr' for the current ISA"
when the instruction isn't valid.
This patch expands that error message to include the missing extension
information. For example, now the error message would be "invalid CSR
'fscr' for the current ISA, CSR 'fscr' needs 'f' extension".
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
gas/
pr 28733
* config/tc-riscv.c (riscv_csr_address): Report more details
when the CSR is invalid.
* testsuite/gas/riscv/csr-version-1p10.l: Updated detailed errors.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
Commit b25f942e18 made .machine more strict. Weaken it again.
* config/tc-ppc.c (ppc_machine): Treat an early .machine specially,
keeping sticky options to work around gcc bugs.
* Removed N extension CSRs,
ustatus, uie, utvec, uscratch, uepc, ucause, utval and uip.
* Removed two supervisor CSRs,
sedeleg and sideleg.
* Changed debug CSR address of scontext from 0x7aa to 0x5a8. We cannot support
different versions of debug specs for now, so only supporting the latest one is
the only way to move forward.
* Added debug CSRs,
mscontext (0x7aa), mcontrol6 (0x7a1, tdata1) and tmexttrigger ((0x7a1, tdata1).
* Regarded hcontext as a debug CSR.
include/
* opcode/riscv-opc.h: Updated CSRs to privileged spec v1.12 and
debug spec v1.0.
gas/
* testsuite/gas/riscv/csr.s: Updated CSRs to privileged spec v1.12
and debug spec v1.0.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
This commit reorganizes and adds some CSRs to csr-dw-regnums.[sd] to
make it test the same CSRs as csr.s.
gas/ChangeLog:
* testsuite/gas/riscv/csr-dw-regnums.s: Reorganize and add
defined CSRs tested in csr.s.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
Subclasses of inf_ptrace_target have to opt-in to using the event_pipe
by implementing the can_async_p and async methods. For subclasses
which do this, inf_ptrace_target provides is_async_p, async_wait_fd
and closes the pipe in the close target method.
inf_ptrace_target also provides wrapper routines around the event pipe
(async_file_open, async_file_close, async_file_flush, and
async_file_mark) for use in target methods such as async.
inf_ptrace_target also exports a static async_file_mark_if_open
function which can be used in SIGCHLD signal handlers.
ptrace on FreeBSD cannot be used against running processes and instead
fails with EBUSY. This meant that 'info threads' would fail if any of
the threads were running (for example when using schedule-multiple=on
in gdb.base/fork-running-state.exp). Instead of throwing errors, just
return nullptr as no thread name is better than causing info threads to
fail completely.
Move the message from 'show debug fbsd-lwp' to 'show debug fbsd-nat'
since it is helpful for debugging async target support and not just
LWP support.
Use target_pid_to_str to format the ptid and log the step and signo
arguments.
This is a fairly simple version of async target support.
Synchronous mode still uses blocking waitpid() calls in
inf_ptrace::wait() unlike the Linux native target which always uses
WNOHANG and uses sigsuspend() for synchronous operation.
Asynchronous mode registers an event pipe with the core as a file
handle and writes to the pipe when SIGCHLD is raised. TARGET_WNOHANG
is handled by inf_ptrace::wait().
- Handle TARGET_WNOHANG by passing WNOHANG to waitpid and returning
TARGET_WAITKIND_IGNORE if there are no events to report.
- Handle a race in async mode where SIGCHLD might signal the event
pipe for an event that has already been reported. If the event was
the exit of the last child process, waitpid() will fail with ECHILD
rather than returning a pid of 0. For this case, return
TARGET_WAITKIND_NO_RESUMED.
Previously this returned a TARGET_WAITKIND_SIGNALLED event for
inferior_ptid. However, inferior_ptid is invalid during ::wait()
methods after the multi-target changes, so this was triggering an
assertion further up the stack.
Previously, TARGET_WNOHANG was cleared if a target supported async
mode even if async mode wasn't currently enabled. This change only
permits TARGET_WNOHANG if async mode is enabled.
Now that target_resume always enables async mode after target::resume
returns, these calls are redundant.
The other place that target resume methods are invoked outside of
target_resume are as the beneath target in record_full_wait_1. In
this case, async mode should already be enabled when supported by the
target before the resume method is invoked due to the following:
In general, targets which support async mode run as async until
::wait returns TARGET_WAITKIND_NO_RESUMED to indicate that there are
no unwaited for children (either they have exited or are stopped).
When that occurs, the loop in wait_one disables async mode. Later
if a stopped child is resumed, async mode is re-enabled in
do_target_resume before waiting for the next event.
In the case of record_full_wait_1, this function is invoked from the
::wait target method when fetching an event. If the underlying
target supports async mode, then an earlier call to do_target_resume
to resume the child reporting an event in the loop in
record_full_wait_1 would have already enabled async mode before
::wait was invoked. In addition, nothing in the code executed in
the loop in record_full_wait_1 disables async mode. Async mode is
only disabled higher in the call stack in wait_one after ::wait
returns.
It is also true that async mode can be disabled by an
INF_EXEC_COMPLETE event passed to inferior_event_handle, but all of
the places that invoke that are in the gdb core which is "above" a
target ::wait method.
Note that there is an earlier call to enable async mode in
linux_nat_target::resume. That call also marks the async event pipe
to report an existing event after enabling async mode, so it needs to
stay.
Enabling async mode above the target layer removes duplicate code in
::resume methods of async-capable targets. Commit 5b6d1e4fa4
("Multi-target support") enabled async mode in do_target_resume after
target_resume returns which is a step in this direction. However,
other callers of target_resume such as target_continue do not enable
async mode. Rather than enabling async mode in each of the callers
after target_resume returns, enable async mode at the end of
target_resume.
This pulls out the implementation of an event pipe used to implement
target async support in both linux-low.cc (gdbserver) and linux-nat.c
(gdb).
This will be used to replace the existing event pipe in linux-low.cc
and linux-nat.c in future commits.
Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>
Currently there are two problems with the detection of
source-highlight via pkg-config in GDB's configure script:
1. The LDFLAGS variable is used to pass the 'pkg-config --libs' output
to AC_LINK_IFELSE, which results in the "-L/some/path
-lsource-highlight" preceding the conftest.cpp, which can result in a
failure to find symbols referenced in conftest.cpp, if the linker is
using --as-needed by default.
2. The CFLAGS variable is used to pass the 'pkg-config --cflags'
output to AC_LINK_IFELSE. However, as the current language is C++,
AC_LINK_IFELSE will actuall use CXXFLAGS, not CFLAGS, so any flags
returned from pkg-config will not be seen.
This patch fixes both of these mistakes, allowing GDB to correctly
configure and build using source-highlight installed into a custom
prefix, e.g. ~/opt/gdb-git (because the system version of
source-highlight is too old).
The INTERNAL_GDBFLAGS runtest variable was updated in 55c3ad8801
([gdb/testsuite] Prevent pagination in GDB_INTERNALFLAGS, 2020-10-26) to
disable pagination, and in aae1c79a03 (PR python/12227..., 2010-12-07)
to point to the data directory, but its default value mentioned in the
testsuite's README was not kept up to date.
To avoid it getting out of sync even more, point the reader to the
definition of the variable in lib/gdb.exp, and move the explanation of
the different flags there. Also adjust the example in the README
so it follows the flags added in 55c3ad8801.
Change-Id: I3533608a7d6ae5198af09c7dc7743bde24c19ed7
Using dummy entry in riscv_supported_std_ext cause confusing and wrongly
support `b` and `k` extensions.
bfd/
* elfxx-riscv.c (riscv_supported_std_ext): Drop unsupported
extensions.
(riscv_ext_canonical_order): New.
(riscv_init_ext_order): Use riscv_ext_canonical_order rather
than riscv_supported_std_ext to compute canonical order.
V2 Changes:
- Use `*ext` rather than `*ext != NULL` for checking is reach end of
string.
"DO NOT EDIT!" says the comment at the top of bfd-in2.h. Move the new
type field where it belongs.
PR ld/28841
* section.c (struct bfd_section): Add type. Formatting.
(BFD_FAKE_SECTION): Formatting.
* bfd-in2.h: Regenerate.
This was left in subdirs because of the dynamic cgen usage. However,
we can move this breakpoint call to runtime and let gdb detect whether
the symbol exists.
I saw some failures in the test gdb.mi/mi-multi-commands.exp that I
added recently. This test was added in commit:
commit d08cbc5d32
Date: Wed Dec 22 12:57:44 2021 +0000
gdb: unbuffer all input streams when not using readline
The failures I see only occurred when my machine was very heavily
loaded.
In this test I send multiple commands from dejagnu to gdb with a
single send_gdb call. In a well behaving world what I want to happen
is that the gdb console sees both commands arrive and echos the text
of those commands. Then gdb starts processing the first command,
prints the result, and then processes the second command, and prints
the result.
However, what I saw in my loaded environment was that only after
sending the two commands, only the first command was echoed to gdb's
terminal. Then gdb started processing the first command, and started
to write the output. Now, mixed in with the first command output, the
second command was echoed to gdb's terminal. Finally, gdb would
finish printing the first command output, and would read and handle
the second command.
This mixing of command echoing with the first command output was
causing the test matching patterns to fail.
In this commit I change the command I use in the test from a CLI
command to an MI command, this reduces the number of lines of output
that come from the test, CLI commands sent through the MI interpreter
are echoed back like this:
(gdb)
set $a = "FIRST COMMAND"
&"set $a = \"FIRST COMMAND\"\n"
^done
(gdb)
While this is not the case for true MI command:
(gdb)
-data-evaluate-expression $a
^done,value="\"FIRST COMMAND\""
(gdb)
Less output makes for simpler patterns to match against.
Next, when sending two command to gdb I was previously trying to spot
the output of the first command followed by the prompt with nothing
between. This is not really needed, for the first command I can look
for just the ^done,value="\"FIRST COMMAND\"" string, then I can start
looking for the output of the second command.
So long as the second pattern matches up to the gdb prompt, then I can
be sure than nothing is left over in the expect buffer to muck up
later matches.
As to see the second command output gdb must have read in the second
command, the second command output never suffers from the corruption
that the first command output does.
Since making this change, I've not seen a failure in this test.
This fixes a GDB crash reported in bug pr/28900, related to reading in
some stabs debug information.
In this commit my goal is to stop GDB crashing. I am not trying to
ensure that GDB makes the best possible use of the available stabs
debug information. At this point I consider stabs a legacy debug
format, with only limited support in GDB.
So, the problem appears to be that, when reading in the stabs data, we
need to find a N_SO entry, this is the entry that defines the start of
a compilation unit (or at least the location of a corresponding source
file).
It is while handling an N_SO that GDB creates a psymtab to hold the
incoming debug information (symbols, etc).
The problem we hit in the bug is that we encounter some symbol
information (an N_PC entry) outside of an N_SO entry - that is we find
some symbol information that is not associated with any source file.
We already have some protection for this case, look (in
read_dbx_symtab) at the handling of N_PC entries of type 'F' and 'f',
if we have no psymtab (the pst variable is nullptr) then we issue a
complaint. However, for whatever reason, in both 'f' and 'F'
handling, there is one place where we assume that the pst
variable (the psymtab) is not nullptr. This is a mistake.
In this commit, I guard these two locations (in 'f' and 'F' handling)
so we no longer assume pst is not nullptr.
While I was at it, I audited all the other uses of pst in
read_dbx_symtab, and in every potentially dangerous case I added a
nullptr check, and issue a suitable complaint if pst is found to be
nullptr.
It might well be true that we could/should do something smarter if we
see a debug symbol outside of an N_SO entry, and if anyone wanted to
do that work, they're welcome too. But this commit is just about
preventing the nullptr access, and the subsequent GDB crash.
I don't have any tests for this change, I have no idea how to generate
weird stabs data for testing. The original binary from the bug report
now loads just fine without GDB crashing.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28900
While taking a look through dbxread.c I spotted a couple of places
where making use of std::string would remove the need for manual
memory allocation and memcpy.
During review Simon pointed out that the same code exists in
xcoffread.c, so I've applied the same fix there too.
There should be no user visible changes after this commit.
A have had situation where a unfiltered output (done using
fputs_unfiltered) ended up triggering pagination. The backtrace for this was:
...
#24 0x000055839377ee4e in check_async_event_handlers () at ../../gdb/async-event.c:335
#25 0x0000558394b67b57 in gdb_do_one_event () at ../../gdbsupport/event-loop.cc:216
#26 0x0000558394587454 in gdb_readline_wrapper (prompt=0x7ffd907712d0 "--Type <RET> for more, q to quit, c to continue without paging--") at ../../gdb/top.c:1148
#27 0x0000558394707270 in prompt_for_continue () at ../../gdb/utils.c:1438
#28 0x00005583947088b3 in fputs_maybe_filtered (linebuffer=0x60c0000f4000 " [...quite big message...]", stream=0x60300028e9d0, filter=0) at ../../gdb/utils.c:1752
#29 0x0000558394708e57 in fputs_unfiltered (linebuffer=0x60c0000f4000 " [...quite big message...]", stream=0x60300028e9d0) at ../../gdb/utils.c:1811
...
This comes from what appears to be a oversight in fputs_maybe_filtered. This
function has a FILTER parameter which if true makes the function pause after
every screenful (i.e. triggers pagination).
The filter parameter is correctly used to guard the first place where
prompt_for_continue. There is a second place in the function which can call
prompt_for_continue, but is currently unguarded. I believe that this is an
oversight, this patch fixes that.
Tested on Linux-x86_64, no regression observed.
Change-Id: Iad8ffd50a87cf20077500878e2564b5a7dc81ece
As seen in https://sourceware.org/bugzilla/show_bug.cgi?id=24069 this
code will typically wait4() a second time on the same process that was
already wait4()'d a few lines above. While this used to be
harmless/idempotent (when we assumed that the process already exited),
this now causes a deadlock in the WIFSTOPPED case.
The early (~2019) history of bug #24069 cautiously suggests to use
WNOHANG instead of outright deleting the call. However, tests on the
current version of Darwin (Big Sur) demonstrate that gdb runs just fine
without a redundant call to wait4(), as would be expected.
Notwithstanding the debatable value of conserving bug compatibility with
an OS release that is more than a decade old, there is scant evidence of
what that double-wait4() was supposed to achieve in the first place - A
cursory investigation with `git blame` pinpoints commits bb00b29d78
and a80b95ba67 from the 2008-2009 era, but fails to answer the
"why" question conclusively.
Co-Authored-By: Philippe Blain <levraiphilippeblain@gmail.com>
Change-Id: Id4e4415d66d6ff6b3552b60d761693f17015e4a0
This adds a constructor to bound_minimal_symbol, to avoid a build
failure with clang that Simon pointed out.
I also took the opportunity to remove some redundant initializations,
and to change one use of push_back to emplace_back, as suggested by
Simon.
Much of the gas source and older BFD source use "long" for function
parameters and variables, when other types would be more appropriate.
This patch fixes one of those cases. Dollar labels and numeric local
labels do not need large numbers. Small positive itegers are usually
all that is required. Due to allowing longs, it was possible for
fb_label_name and dollar_label_name to overflow their buffers.
* symbols.c: Delete unnecessary forward declarations.
(dollar_labels, dollar_label_instances): Use unsigned int.
(dollar_label_defined, dollar_label_instance): Likewise.
(define_dollar_label): Likewise.
(fb_low_counter, fb_labels, fb_label_instances): Likewise.
(fb_label_instance_inc, fb_label_instance): Likewise.
(fb_label_count, fb_label_max): Make them size_t.
(dollar_label_name, fb_label_name): Rewrite using sprintf.
* symbols.h (dollar_label_defined): Update prototype.
(define_dollar_label, dollar_label_name): Likewise.
(fb_label_instance_inc, fb_label_name): Likewise.
* config/bfin-lex.l (yylex): Remove unnecessary casts.
* expr.c (integer_constant): Likewise.
* read.c (read_a_source_file): Limit numeric label range to int.
There are quite a few ubsan warnings in gas. This one disappears with
a code tidy.
* read.c (s_app_line): Rename 'l' to 'linenum'. Avoid ubsan
warning.
