This commit adjusts some of the debug output in linux-nat.c, but makes
no other functional changes to GDB.
In resume_lwp I've added the word "sibling" to one of the debug
messages. All the other debug messages in this function talk about
operating on the sibling thread, so I think it makes sense, for
consistency, if the message I've updated also talks about the sibling
thread.
In resume_stopped_resumed_lwps I've reordered the condition checks so
that the vfork-parent check now happens after the checks for whether
the thread is already resumed or not. This makes no functional
difference to GDB, but does, I think, mean we see more helpful debug
messages first.
Consider the situation where a vfork-parent thread is already resumed,
and resume_stopped_resumed_lwps is called. Previously the message
saying that the thread was not being resumed due to being a
vfork-parent, was printed. This might give the impression that the
thread is left in a not resumed state, which is misleading.
After this change we now get a message saying that the thread is not
being resumed due to it not being stopped (i.e. is already resumed).
With this message the already resumed nature of the thread is much
clearer.
I found this change helpful when debugging some vfork related issues.
For *reasons* I was hacking on gdb.base/foll-vfork.exp and wanted to
change the name of the binary that was created. Should be easy, I
adjusted the global $binfile variable .... but that didn't work.
In one place the script uses $testfile instead of $binfile.
Fixed this to use $binfile, now I can easily change the name of the
generated binary, and the test still works.
There's no change in what is tested after this commit.
I noticed in test-case gdb.arch/arm-pthread_cond_timedwait-bt.exp that
prepare_for_testing is used, followed by a clean_restart.
This calls clean_restart twice in a row.
Fix this by using build_executable instead.
Also, I noticed that the test-case requires an SVC instruction, so add a
require to limit the test-case to supported architectures.
While we're at it, run M-x indent-region in emacs to fix indentation.
Tested on x86_64-linux.
Jakub pointed out that using DW_FORM_implicit_const with
DW_AT_bit_size would cause gdb to crash. This happened because
DW_FORM_implicit_const is not an "unsigned" form, causing as_unsigned
to assert. This patch fixes the problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30651
Approved-By: Andrew Burgess <aburgess@redhat.com>
This tiny patch makes the BPF disassembler to emit, e.g.
ldxdw %r1, [%r0+0]
instead of
ldxdw %r1, [%r00]
when the offset is 0, to avoid confusion.
opcodes/
* bpf-dis.c (print_insn_bpf): Print offsets with value 0 as "+0".
gas/
* testsuite/gas/bpf/mem.s: Add tests with offset 0.
* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
* testsuite/gas/bpf/mem.d: Update accordingly.
* testsuite/gas/bpf/mem-be.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
* testsuite/gas/bpf/mem-be-pseudoc.d: Likewise.
This adds a new objfile_for_address method to gdb.Progspace. This
makes it easy to find the objfile for a given address.
There's a related PR; and while this change would have been sufficient
for my original need, it's not clear to me whether I should close the
bug. Nevertheless I think it makes sense to at least mention it here.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19288
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I noticed an unused import in dap/evaluate.py; and also I found out
that my recent changes to use frame filters from DAP left some unused
imports in dap/bt.py.
This commit adds the signed load to register (ldxs*) instructions
introduced in the BPF ISA version 4, including opcodes and assembler
tests.
Tested in bpf-unknown-none.
include/ChangeLog:
2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
* opcode/bpf.h (enum bpf_insn_id): Add entries for signed load
instructions.
(BPF_MODE_SMEM): Define.
opcodes/ChangeLog:
2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf-opc.c (bpf_opcodes): Add entries for LDXS{B,W,H,DW}
instructions.
gas/ChangeLog:
2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
* testsuite/gas/bpf/mem.s: Add signed load instructions.
* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
* testsuite/gas/bpf/mem.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
* testsuite/gas/bpf/mem-be.d: Likewise.
* doc/c-bpf.texi (BPF Instructions): Document the signed load
instructions.
This commit adds the signed register move (movs) instructions
introduced in the BPF ISA version 4, including opcodes and assembler
tests.
Tested in bpf-unknown-none.
include/ChangeLog:
2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
* opcode/bpf.h (BPF_OFFSET16_MOVS8): Define.
(BPF_OFFSET16_MOVS16): Likewise.
(BPF_OFFSET16_MOVS32): Likewise.
(enum bpf_insn_id): Add entries for MOVS{8,16,32}R and
MOVS32{8,16,32}R.
opcodes/ChangeLog:
2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf-opc.c (bpf_opcodes): Add entries for MOVS{8,16,32}R and
MOVS32{8,16,32}R instructions. and MOVS32I instructions.
gas/ChangeLog:
2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
* testsuite/gas/bpf/alu.s: Test movs instructions.
* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu32.s: Likewise for movs32 instruction.
* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu.d: Add expected results.
* testsuite/gas/bpf/alu32.d: Likewise.
* testsuite/gas/bpf/alu-be.d: Likewise.
* testsuite/gas/bpf/alu32-be.d: Likewise.
* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.
In a review, Eli pointed out that @findex is redundant when used with
@defun. This patch removes all such uses from python.texi, plus a
couple uses before @defvar that are also unnecessary.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Ada 2022 adds the "target name symbol", which can be used on the right
hand side of an assignment to refer to the left hand side. This
allows for convenient updates. This patch implements this for gdb's
Ada expression parser.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
The DAP disassemble command lets the client return the underlying
bytes of the instruction in an implementation-defined format. This
patch updates gdb to return this, and simply uses a hex string of the
bytes as the format.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I ran across this very old code in gdb's Ada support. After a bit of
archaeology, we couldn't determine what bug this might have been
working around. It is no longer needed, so this patch removes it.
As this is entirely Ada-specific and was reviewed and tested at
AdaCore, I'm checking it in.
This was breaking --enable-targets=all builds.
opcodes/ChangeLog:
2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
* Makefile.am (TARGET64_LIBOPCODES_CFILES): Add missing bpf-dis.c
* Makefile.in: Regenerate.
The BPF port in binutils has been rewritten (commit
d218e7fedc) in order to not be longer
based on CGEN. Please see that commit log for more information.
This patch updates the BPF simulator accordingly. The new
implementation is much simpler and it is based on the new BPF opcodes.
Tested with target bpf-unknown-none with both 64-bit little-endian
host and 32-bit little-endian host.
Note that I have not tested in a big-endian host yet. I will do so
once this lands upstream so I can use the GCC compiler farm.
CGEN is cool, but the BPF architecture is simply too bizarre for it.
The weird way of BPF to handle endianness in instruction encoding, the
weird C-like alternative assembly syntax, the weird abuse of
multi-byte (or infra-byte) instruction fields as opcodes, the unusual
presence of opcodes beyond the first 32-bits of some instructions, are
all examples of what makes it a PITA to continue using CGEN for this
port. The bpf.cpu file is becoming so complex and so nested with
p-macros that it is very difficult to read, and quite challenging to
update. Also, every time we are forced to change something in CGEN to
accommodate BPF requirements (which is often) we have to do extensive
testing to make sure we do not break any other target using CGEN.
This is getting un-maintenable.
So I have decided to bite the bullet and revamp/rewrite the port so it
no longer uses CGEN. Overall, this involved:
* To remove the cpu/bpf.{cpu,opc} descriptions.
* To remove the CGEN generated files.
* To replace the CGEN generated opcodes table with a new hand-written
opcodes table for BPF.
* To replace the CGEN generated disassembler wih a new disassembler
that uses the new opcodes.
* To replace the CGEN generated assembler with a new assembler that uses the
new opcodes.
* To replace the CGEN generated simulator with a new simulator that uses the
new opcodes. [This is pushed in GDB in another patch.]
* To adapt the build systems to the new situation.
Additionally, this patch introduces some extensions and improvements:
* A new BPF relocation BPF_RELOC_BPF_DISP16 plus corresponding ELF
relocation R_BPF_GNU_64_16 are added to the BPF BFD port. These
relocations are used for section-relative 16-bit offsets used in
load/store instructions.
* The disassembler now has support for the "pseudo-c" assembly syntax of
BPF. What dialect to use when disassembling is controlled by a command
line option.
* The disassembler now has support for dumping instruction immediates in
either octal, hexadecimal or decimal. The used output base is controlled
by a new command-line option.
* The GAS BPF test suite has been re-structured and expanded in order to
test the disassembler pseudoc syntax support. Minor bugs have been also
fixed there. The assembler generic tests that were disabled for bpf-*-*
targets due to the previous implementation of pseudoc syntax are now
re-enabled. Additional tests have been added to test the new features of
the assembler. .dump files are no longer used.
* The linker BPF test suite has been adapted to the command line options
used by the new disassembler.
The result is very satisfactory. This patchs adds 3448 lines of code
and removes 10542 lines of code.
Tested in:
* Target bpf-unknown-none with 64-bit little-endian host and 32-bit
little-endian host.
* Target x86-64-linux-gnu with --enable-targets=all
Note that I have not tested in a big-endian host yet. I will do so
once this lands upstream so I can use the GCC compiler farm.
I have not included ChangeLog entries in this patch: these would be
massive and not very useful, considering this is pretty much a rewrite
of the port. I beg the indulgence of the global maintainers.
ROCm programs can load a high number of compute kernels on GPU devices,
especially if lazy code-object loading have been disabled. Each code
object containing such program is loaded once for each device available,
and each instance is reported by GDB as an individual shared library.
We came across situations where the number of shared libraries opened by
GDB gets higher than the allowed number of opened files for the process.
Increasing the opened files limit works around the problem, but there is a
better way this patch proposes to follow.
Under the hood, the GPU code objects are embedded inside the host
application binary and shared library binaries. GDB currently opens the
underlying file once for each shared library it sees. That means that
the same file is re-opened every time a code object is loaded on a GPU.
This patch proposes to only open each underlying file once. This is
done by implementing a reference counting mechanism so the underlying
file is opened when the underlying file first needs to be opened, and
closed when the last BFD using the underlying file is closed.
On a program where GDB used to open about 1500 files to load all shared
libraries, this patch makes it so only 54 opened file descriptors are
needed.
I have tested this patch on downstream ROCgdb's full testsuite and
upstream GDB testsuite with no regression.
Approved-By: Pedro Alves <pedro@palves.net>
Bring disassembly back in line with what the assembler accepts, thus
also making it self-consistent (with, in particular selector load/store
insns). While there further add D to all affected insns except ARPL
(where S is used, matching LAR/LSL), to also behave correctly in suffix-
always mode.
While there also hook up the Intel variant of the LKGS test.
For whatever reason in c9f5b96bda ("x86: correct handling of LAR and
LSL") I didn't realize that we can easily use Sv instead of going
through mod_table[]. Redo this aspect of that change.
Consider the test-case:
...
$ cat main.c
int main (void) { return 0; }
$ cat static-optimized-out.c
static int aaa;
...
compiled like this:
...
$ gcc-12 static-optimized-out.c main.c -g -O2 -flto
...
There's a difference in behaviour depending on symtab expansion state:
...
$ gdb -q -batch a.out -ex "print aaa"
No symbol "aaa" in current context.
$ gdb -q -batch a.out -ex "maint expand-symtab" -ex "print aaa"
$1 = <optimized out>
...
The reason for the difference is that the optimized out variable aaa:
...
<1><104>: Abbrev Number: 2 (DW_TAG_variable)
<105> DW_AT_name : aaa
<109> DW_AT_decl_file : 1
<10a> DW_AT_decl_line : 18
<10b> DW_AT_decl_column : 12
<10c> DW_AT_type : <0x110>
...
is not added to the cooked index because of this clause in abbrev_table::read:
...
else if (!has_location && !has_specification_or_origin && !has_external
&& cur_abbrev->tag == DW_TAG_variable)
cur_abbrev->interesting = false;
...
Fix this inconsistency by making sure that the optimized out variable is added
to the cooked index.
Regression tested on x86_64-linux.
Add two test-cases, a C test-case gdb.opt/static-optimized-out.exp and a dwarf
assembly test-case gdb.dwarf2/static-optimized-out.exp.
Tested gdb.opt/static-optimized-out.exp with gcc-8 to gcc-12, for which we now
consistently get:
...
(gdb) print aaa^M
$1 = <optimized out>^M
...
and with gcc 7.5.0 and clang 13.0.1, for which we still consistently get:
...
(gdb) print aaa^M
No symbol "aaa" in current context.^M
...
due to missing debug info for the variable.
PR symtab/30656
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30656
Approved-By: Tom Tromey <tom@tromey.com>
In test-case gdb.tui/long-prompt.exp, with a prompt of 40 chars, the same size
as the terminal width, we get a superfluous newline at line 19:
...
16 (gdb) set prompt 123456789A123456789B123
17 456789C123456789>
18 123456789A123456789B123456789C123456789>
19
20 123456789A123456789B123456789C123456789>
21 set prompt (gdb)
22 (gdb)
...
as well as a superfluous repetition of the prompt at line 20 once we type the
's' starting "set prompt".
I traced the superfluous newline back to readline's readline_internal_setup,
that does:
...
/* If we're not echoing, we still want to at least print a prompt, because
rl_redisplay will not do it for us. If the calling application has a
custom redisplay function, though, let that function handle it. */
if (_rl_echoing_p == 0 && rl_redisplay_function == rl_redisplay)
...
else
{
if (rl_prompt && rl_already_prompted)
rl_on_new_line_with_prompt ();
else
rl_on_new_line ();
(*rl_redisplay_function) ();
...
and then we hit the case that calls rl_on_new_line_with_prompt, which does:
...
/* If the prompt length is a multiple of real_screenwidth, we don't know
whether the cursor is at the end of the last line, or already at the
beginning of the next line. Output a newline just to be safe. */
if (l > 0 && (l % real_screenwidth) == 0)
_rl_output_some_chars ("\n", 1);
...
This doesn't look like a readline bug, because the behaviour matches the
comment.
[ And the fact that the output of the newline doesn't happen in the scope of
tui_redisplay_readline means it doesn't get the prompt wrap detection
treatment, causing start_line to be incorrect, which causes the superfluous
repetition of the prompt. ]
I looked at ways to work around this, and managed by switching off
rl_already_prompted, which we set to 1 in tui_rl_startup_hook:
...
/* Readline hook to redisplay ourself the gdb prompt.
In the SingleKey mode, the prompt is not printed so that
the command window is cleaner. It will be displayed if
we temporarily leave the SingleKey mode. */
static int
tui_rl_startup_hook (void)
{
rl_already_prompted = 1;
if (tui_current_key_mode != TUI_COMMAND_MODE
&& !gdb_in_secondary_prompt_p (current_ui))
tui_set_key_mode (TUI_SINGLE_KEY_MODE);
tui_redisplay_readline ();
return 0;
}
...
Then I started looking at why rl_already_prompted is set to 1.
The use case for rl_already_prompted seems to be:
- app (application, the readline user) outputs prompt,
- app sets rl_already_prompted to 1, and
- app calls readline, which calls rl_on_new_line_with_prompt, which figures
out how long the prompt is, and sets a few readline variables accordingly,
which can be used in the following call to rl_redisplay_function.
AFAICT, TUI does not fit this pattern. It does not output an initial prompt,
rather it writes the prompt in every rl_redisplay_function. It doesn't use
the variables set by rl_on_new_line_with_prompt, instead it figures stuff out
by itself.
Fix this by removing the rl_already_prompted setting.
Also remove the call to tui_redisplay_readline, it's not necessary, the
function is called anyway.
Tested on x86_64-linux, no regressions.
In the current code, when a register is fetched, the entire regset
are fetched via ptrace, but only this register status is updated in
regcache, it needs to fetch the same regset through ptrace again if
another register in this regset is fetched later, this is obviously
unnecessary. It is proper to update the status of the entire regset
in regcache when fetching a register via ptrace.
Signed-off-by: Hui Li <lihui@loongson.cn>
Reviewed-By: Tom Tromey <tom@tromey.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Andrew reported that the previous change to gdb.Inferior.read_memory &
friends introducing scoped_restore_current_inferior_for_memory broke
gdb.dap/stop-at-main.exp. This is also reported as PR dap/30644.
The root of the problem is that all the methods that now use
scoped_restore_current_inferior_for_memory cause GDB to crash with a
failed assert if they are run on an inferior that is not yet started.
E.g.:
(gdb) python i = gdb.selected_inferior ()
(gdb) python i.read_memory (4,4)
gdb/thread.c:626: internal-error: any_thread_of_inferior: Assertion `inf->pid != 0' failed.
This patch fixes the problem by removing
scoped_restore_current_inferior_for_memory's ctor ptid parameter and
the any_thread_of_inferior calls completely, and making
scoped_restore_current_inferior_for_memory switch inferior_ptid to a
pid ptid.
I was a little worried that some port might be assuming inferior_ptid
points at a thread in the xfer_partial memory access routines. We
know that anything that supports forks must not assume that, due to
how detach_breakpoints works. I looked at a number of xfer_partial
implementations, and didn't see anything that is looking at
inferior_ptid in a way that would misbehave. I'm thinking that we
could go forward with this and just fix ports if they break.
While on some ports like on AMD GPU we have thread-specific address
spaces, and so when accessing memory for those address spaces, we must
have the right thread context (via inferior_ptid) selected, in
Inferior.read_memory, we only have the inferior to work with, so this
API as is can't be used to access thread-specific address spaces.
IOW, it can only be used to access the global address space that is
visible to both the CPU and the GPUs.
In proc-service.c:ps_xfer_memory, the other spot using
scoped_restore_current_inferior_for_memory, we're always accessing
per-inferior memory.
If we end up using scoped_restore_current_inferior_for_memory later to
set up the context to read memory from a specific thread, then we can
add an alternative ctor that takes a thread_info pointer, and make
inferior_ptid point to the thread, for example.
New test added to gdb.python/py-inferior.exp, exercising
Inferior.read_memory without execution.
No regressions on native and extended-gdbserver x86_64 GNU/Linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30644
Change-Id: I11309c5ddbbb51a4594cf63c21b3858bfd9aed19
Current implementation of amd_dbgapi_target::detach (inferior *, int)
does the following:
remove_breakpoints_inf (current_inferior ());
detach_amd_dbgapi (inf);
beneath ()->detach (inf, from_tty);
I find that using a mix of `current_inferior ()` and `inf` disturbing.
At this point, we know that both are the same (target_detach does assert
that `inf == current_inferior ()` before calling target_ops::detach).
To improve consistency, this patch replaces `current_inferior ()` with
`inf` in amd_dbgapi_target::detach.
Change-Id: I01b7ba2e661c25839438354b509d7abbddb7c5ed
Approved-By: Pedro Alves <pedro@palves.net>
With a gdb build with -O2 -flto=auto using gcc 7.5.0, I run into:
...
(gdb) ptype global_c^M
^M
Thread 1 "xgdb" hit Breakpoint 3, \
_Z12c_print_typeP4typePKcP7ui_fileii8languagePK18type_print_options () at \
gdb/c-typeprint.c:175^M
175 {^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb again
...
This is a problem with the debug info, which marks the CU containing the
function declaration as C rather than C++. This is fixed in gcc 8 and later.
Work around this compiler problem by allowing the mangled name.
Tested on x86_64-linux.
PR testsuite/30648
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30648
It is possible to build huge binaries on powerpc64, where 32-bit
addresses in debug info are insufficient to descibe locations in the
binary. Help out the user, and only warn about debug overflows.
* powerpc.cc (Target_powerpc::Relocate::relocate): Warn on
relocation overflows in debug info.
Only the xcoff and pe extensions were enabled. Build the lot, and fix
some more printf format problems when the host is 32-bit.
* configure.ac (od_vectors): Set up for --enable-targets=all.
* configure: Regenerate.
* od-elf32_avr.c (elf32_avr_dump_mem_usage): Correct format
specifier vs. arg mismatch.
(elf32_avr_dump_avr_prop): Likewise.
This patch support Zcb extension, contains new compressed instructions,
some instructions depend on other existed extension, like 'zba', 'zbb'
and 'zmmul'. Zcb also imply Zca extension to enable the compressing
features.
Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
Co-Authored by: Simon Cook <simon.cook@embecosm.com>
Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): New extension.
(riscv_multi_subset_supports_ext): Ditto.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): New operators.
(riscv_ip): Ditto.
* testsuite/gas/riscv/zcb.d: New test.
* testsuite/gas/riscv/zcb.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h (MATCH_C_LBU): New opcode.
(MASK_C_LBU): New mask.
(MATCH_C_LHU): New opcode.
(MASK_C_LHU): New mask.
(MATCH_C_LH): New opcode.
(MASK_C_LH): New mask.
(MATCH_C_SB): New opcode.
(MASK_C_SB): New mask.
(MATCH_C_SH): New opcode.
(MASK_C_SH): New mask.
(MATCH_C_ZEXT_B): New opcode.
(MASK_C_ZEXT_B): New mask.
(MATCH_C_SEXT_B): New opcode.
(MASK_C_SEXT_B): New mask.
(MATCH_C_ZEXT_H): New opcode.
(MASK_C_ZEXT_H): New mask.
(MATCH_C_SEXT_H): New opcode.
(MASK_C_SEXT_H): New mask.
(MATCH_C_ZEXT_W): New opcode.
(MASK_C_ZEXT_W): New mask.
(MATCH_C_NOT): New opcode.
(MASK_C_NOT): New mask.
(MATCH_C_MUL): New opcode.
(MASK_C_MUL): New mask.
(DECLARE_INSN): New opcode.
* opcode/riscv.h (EXTRACT_ZCB_BYTE_UIMM): New inline func.
(EXTRACT_ZCB_HALFWORD_UIMM): Ditto.
(ENCODE_ZCB_BYTE_UIMM): Ditto.
(ENCODE_ZCB_HALFWORD_UIMM): Ditto.
(VALID_ZCB_BYTE_UIMM): Ditto.
(VALID_ZCB_HALFWORD_UIMM): Ditto.
(enum riscv_insn_class): New extension class.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): New operators.
* riscv-opc.c: New instructions.
This patch add Zca/f/d extensions support, since all ZC*
extensions will imply Zca extension, just enabled compress
feature when Zca extension is available.
Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
Co-Authored by: Simon Cook <simon.cook@embecosm.com>
Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): New extensions.
(riscv_multi_subset_supports_ext): Ditto.
gas/ChangeLog:
* config/tc-riscv.c (riscv_set_arch): Extend compress check.
* testsuite/gas/riscv/zca.d: New test.
* testsuite/gas/riscv/zca.s: New test.
* testsuite/gas/riscv/zcd.d: New test.
* testsuite/gas/riscv/zcd.s: New test.
* testsuite/gas/riscv/zcf.d: New test.
* testsuite/gas/riscv/zcf.s: New test.
While working on some of the recent patches relating to vfork handling
I found this debug output very helpful, I'd like to propose adding
this into GDB.
With debug turned off there should be no user visible changes after
this commit.
While working on gdb.base/foll-vfork.exp I noticed that there are
several random 'sleep' calls throughout the test.
The comment suggests these are to allow for output from a vforked
child to arrive, but in each case the test is about to close and
restart GDB, so I don't see how random output from a child process
could impact testing.
I removed the sleep calls and couldn't reproduce any failures from
this test, I left the test running for a couple of hours, and tried
loading my machine, and the test seems fine with these removed.
I've left this as a separate commit so that if, in the future, someone
can show that these are required, it will be easy to revert this one
patch and bring them back.
There should be no change in what is tested after this commit.
This commit provides tests for all of the bugs fixed in the previous
four commits, this is achieved by expanding gdb.base/foll-vfork.exp to
run with different configurations:
* target-non-stop on/off
* non-stop on/off
* schedule-multiple on/off
We don't test with schedule-multiple on if we are using a remote
target, this is due to bug gdb/30574. I've added a link to that bug
in this commit, but all this commit does is expose that bug, there's
no fixes here.
Some of the bugs fixed in the previous commits are very timing
dependent, as such, they don't always show up. I've had more success
when running this test on a very loaded machine -- I usually run ~8
copies of the test in parallel, then the bugs would normally show up
pretty quickly.
Other than running the test in more configurations, I've not made any
changes to what is actually being tested, other than in one place
where, when testing with non-stop mode, GDB stops in a different
inferior, as such I had to add a new 'inferior 2' call, this can be
found in vfork_relations_in_info_inferiors.
I have cleaned things up a little, for example, making use of
proc_with_prefix to remove some with_test_prefix calls.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30574
Andrew Burgess
GDB Administrator
Tom de Vries
Tom Tromey
David Faust
Tom Tromey
Jose E. Marchesi
Lancelot Six
Jan Beulich
Alan Modra
Hui Li
Pedro Alves
Nick Clifton
Pter Chubb
Jiawei
Michael Matz