I came across this problem when testing gdb.base/gdb-sigterm.exp
on a machine with a pre-release version of glib-2.34 installed:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
Resyncing due to internal error.
ERROR: : spawn id exp11 not open
while executing
"expect {
-i exp11 -timeout 10
-re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
}
-re "Create..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp11 not open
ERROR: Could not resync from internal error (timeout)
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
I don't have a problem with the latter ERROR nor the UNRESOLVED
messages. However the first ERROR regarding the exp11 spawn id
not being open is not especially useful.
This commit handles the "Recursive internal problem" case, avoiding
the problematic ERROR shown above.
With this commit in place, the log messages look like this instead:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
Resyncing due to internal error.
ERROR: Could not resync from internal error (recursive internal problem)
gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive
internal problem".
gdb-add-index may trigger debuginfod's first-use notice. The notice
is misleading in this case. It instructs the user to modify .gdbinit
in order to permanently enable/disable debuginfod but gdb-add-index
invokes gdb with -nx which ignores .gdbinit.
Additionally debuginfod is not needed for gdb-add-index since the
symbol file is given as an argument and should already be present
locally.
Fix this by disabling debuginfod when gdb-add-index invokes gdb.
This commit adds operator+= and operator+ overloads for adding
gdb::unique_xmalloc_ptr<char> to a std::string. I could only find 3
places in GDB where this was useful right now, and these all make use
of operator+=.
I've also added a self test for gdb::unique_xmalloc_ptr<char>, which
makes use of both operator+= and operator+, so they are both getting
used/tested.
There should be no user visible changes after this commit, except when
running 'maint selftest', where the new self test is visible.
Joel noticed that if the remote dies unexpectedly during a command --
you can simulate this by using "continue" and then killing gdbserver
-- then the CLI will print a new prompt, but MI will not. Later, we
found out that this was also filed in bugzilla as PR mi/23820.
The output looks something like this:
| (gdb)
| cont
| &"cont\n"
| ~"Continuing.\n"
| ^running
| *running,thread-id="all"
| (gdb)
| [... some output from GDB during program startup...]
| =thread-exited,id="1",group-id="i1"
| =thread-group-exited,id="i1"
| &"Remote connection closed\n"
Now, what about that "(gdb)" in the middle?
That prompt comes from this questionable code in
mi-interp.c:mi_on_resume_1:
/* This is what gdb used to do historically -- printing prompt
even if it cannot actually accept any input. This will be
surely removed for MI3, and may be removed even earlier. */
if (current_ui->prompt_state == PROMPT_BLOCKED)
fputs_unfiltered ("(gdb) \n", mi->raw_stdout);
... which seems like something to remove. But maybe the intent here
is that this prompt is sufficient, and MI clients must be ready to
handle output coming after a prompt. On the other hand, if this code
*is* removed, then nothing would print a prompt in this scenario.
Anyway, the CLI and the TUI handle emitting the prompt here by hooking
into gdb::observers::command_error, but MI doesn't install an observer
here.
This patch adds the missing observer and arranges to show the MI
prompt. Regression tested on x86-64 Fedora 34.
It seems like this area could be improved a bit, by having
start_event_loop call the prompt-displaying code directly, rather than
indirecting through an observer. However, I haven't done this.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23820
PR testsuite/7142 -- old enough to have been converted from Gnats --
points out that test_list_filename_and_function in gdb.base/list.exp
has "fails" that are unmatched with passes. This patch cleans this up
a little.
Co-authored-by: Tom Tromey <tromey@adacore.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7142
Since commit e601909a32 ("RISC-V: Support
to parse the multi-letter prefix in the architecture string.") changed
so that all prefixed extensions are parsed in single
riscv_parse_prefixed_ext call, a "while" loop on riscv_parse_subset
is no longer required.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_subset): Remove unnecessary loop.
This patch adds support for wild template parameter list matches, similar
to how ABI tags or function overloads are now handled.
With this patch, users will be able to "gloss over" the details of matching
template parameter lists. This is accomplished by adding (yet more) logic
to strncmp_iw_with_mode to skip parameter lists if none is explicitly given
by the user.
Here's a simple example using gdb.linespec/cpls-ops.exp:
Before
------
(gdb) ptype test_op_call
type = struct test_op_call {
public:
void operator()(void);
void operator()(int);
void operator()(long);
void operator()<int>(int *);
}
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (3 locations)
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x400583 in test_op_call::operator()(int)
at cpls-ops.cc:43
1.2 y 0x40058e in test_op_call::operator()()
at cpls-ops.cc:47
1.3 y 0x40059e in test_op_call::operator()(long)
at cpls-ops.cc:51
The breakpoint at test_op_call::operator()<int> was never set.
After
-----
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (4 locations)
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x400583 in test_op_call::operator()(int)
at cpls-ops.cc:43
1.2 y 0x40058e in test_op_call::operator()()
at cpls-ops.cc:47
1.3 y 0x40059e in test_op_call::operator()(long)
at cpls-ops.cc:51
1.4 y 0x4008d0 in test_op_call::operator()<int>(int*)
at cpls-ops.cc:57
Similar to how scope lookups work, passing "-qualified" to the break command
will cause a literal lookup of the symbol. In the example immediately above,
this will cause GDB to only find the three non-template functions.
This patch attempts to make a start at adding unit tests for
strncmp_iw_with_mode. While there is quite a bit of testing
of this function in other tests, these are currently end-to-end
tests.
This patch attempts to cover the basics of string matching, white
space, C++ ABI tags, and several other topics. However, one area
that is ostensibly missing is testing the `match_for_lcd' feature.
This is otherwise tested as part of our end-to-end DejaGNU-based
testing.
PR fortran/28801 points out a gdb crash that can be provoked by
certain Fortran code. The bug is that f77_get_upperbound assumes the
property is either a constant or undefined, but in this case it is
PROP_LOCEXPR.
This patch fixes the crash by making this function (and the
lower-bound one as well) do the correct check before calling
'const_val'.
Thanks to Andrew for writing the test case.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28801
Commit 14b3360508 ("do_target_wait_1: Clear
TARGET_WNOHANG if the target isn't async.") broke some multi-target
tests, such as gdb.multi/multi-target-info-inferiors.exp. The symptom
is that execution just hangs at some point. What happens is:
1. One remote inferior is started, and now sits stopped at a breakpoint.
It is not "async" at this point (but it "can async").
2. We run a native inferior, the event loop gets woken up by the native
target's fd.
3. In do_target_wait, we randomly choose an inferior to call target_wait
on first, it happens to be the remote inferior.
4. Because the target is currently not "async", we clear
TARGET_WNOHANG, resulting in synchronous wait. We therefore block
here:
#0 0x00007fe9540dbb4d in select () from /usr/lib/libc.so.6
#1 0x000055fc7e821da7 in gdb_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31
#2 0x000055fc7ddef905 in interruptible_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/event-top.c:1134
#3 0x000055fc7eda58e4 in ser_base_wait_for (scb=0x6250002e4100, timeout=1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:240
#4 0x000055fc7eda66ba in do_ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:365
#5 0x000055fc7eda6ff6 in generic_readchar (scb=0x6250002e4100, timeout=-1, do_readchar=0x55fc7eda663c <do_ser_base_readchar(serial*, int)>) at /home/simark/src/binutils-gdb/gdb/ser-base.c:444
#6 0x000055fc7eda718a in ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:471
#7 0x000055fc7edb1ecd in serial_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/serial.c:393
#8 0x000055fc7ec48b8f in remote_target::readchar (this=0x617000038780, timeout=-1) at /home/simark/src/binutils-gdb/gdb/remote.c:9446
#9 0x000055fc7ec4da82 in remote_target::getpkt_or_notif_sane_1 (this=0x617000038780, buf=0x6170000387a8, forever=1, expecting_notif=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:9928
#10 0x000055fc7ec4f045 in remote_target::getpkt_or_notif_sane (this=0x617000038780, buf=0x6170000387a8, forever=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:10037
#11 0x000055fc7ec354d4 in remote_target::wait_ns (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8147
#12 0x000055fc7ec38aa1 in remote_target::wait (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8337
#13 0x000055fc7f1409ce in target_wait (ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2612
#14 0x000055fc7e19da98 in do_target_wait_1 (inf=0x617000038080, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3636
#15 0x000055fc7e19e26b in operator() (__closure=0x7ffdb77c2f90, inf=0x617000038080) at /home/simark/src/binutils-gdb/gdb/infrun.c:3697
#16 0x000055fc7e19f0c4 in do_target_wait (ecs=0x7ffdb77c33a0, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3716
#17 0x000055fc7e1a31f7 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4061
Before the aforementioned commit, we would not have cleared
TARGET_WNOHANG, the remote target's wait would have returned nothing,
and we would have consumed the native target's event.
After applying this revert, the testsuite state looks as good as before
for me on Ubuntu 20.04 amd64.
Change-Id: Ic17a1642935cabcc16c25cb6899d52e12c2f5c3f
Make use of a range based for loop to iterate over a static global
array, removing the need to have a null entry at the end of the
array.
There should be no user visible changes after this commit.
On modern Darwin's, there appears to be a new circumstance in which a
MACH_NOTIFY_DEAD_NAME message can be received, and which was not
previously accounted for: to signal the WIFSTOPPED condition in the
debuggee. In that case the debuggee is not dead yet (and in fact,
counting it as dead would cause a zombie leak - A process in such a
state reparents to PID 1, but cannot be killed).
- Read and ignore such messages (counting on the next exception message
to let us know of the inferior's new state again)
- Refactor logging so as to clearly distinguish between the
MACH_NOTIFY_DEAD_NAME cases (WIFEXITED, WIFSTOPPED, signal, or
something else), and warn in the last case
Co-authored-by: Louis-He <1726110778@qq.com>
Co-authored-by: Philippe Blain <levraiphilippeblain@gmail.com>
Change-Id: Ie86904a894e9bd154e6b674b1bfbfbaee7fde3e1
Commit 29ef4c0699 ("gdb/linux-tdep.c: Add Perms to the 'info proc
mappings' output") has broken test gdb.base/info-proc.exp on Linux,
because it changes the output of "info proc mappings" in a way that the
test does not expect (my bad for not testing before pushing).
I looked at how FreeBSD handles this, since I remembered it did show
permission flags. It looks like this:
Start Addr End Addr Size Offset Flags File
0x200000 0x243000 0x43000 0x0 r-- CN-- /usr/local/bin/tmux
(I think that `Flags` and the flags not being aligned is not
intentional)
The test passes on FreeBSD, because the test looks for four hex numbers
in a row and ignores the rest:
".*Mapped address spaces:.*${hex}${ws}${hex}${ws}${hex}${ws}${hex}.*"
I suggest fixing it on Linux by moving the flags column to the same
place as in the FreeBSD output. It makes things a bit more consistent
between OSes, and we don't have to touch the test.
At the same time, make use of the actual length of the permission's
string to specify the number of characters to print.
Before this patch, the output looks like:
Start Addr End Addr Perms Size Offset objfile
0x55dd4b544000 0x55dd4b546000 r--p 0x2000 0x0 /usr/bin/sleep
and after, it looks like:
Start Addr End Addr Size Offset Perms objfile
0x5622ae662000 0x5622ae664000 0x2000 0x0 r--p /usr/bin/sleep
Change-Id: If0fc167b010b25f97a3c54e2f491df4973ccde8f
Change read_mapping to return a structure instead of taking many output
parameters. Change the string + length output parameters (permissions
and device) to be gdb::string_view, since that's what string_view is
for (a non-NULL terminated view on a string). No changes in behavior
expected.
Change-Id: I86e627d84d3dda8c9b835592b0f4de8d90d12112
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.
