| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
kvx_dis_init currently always returns true, but error conditions do so
by "return -1" which converts to true. The return status is ignored
anyway, and it doesn't make much sense to error on unexpected arch or
mach: If print_insn_kvx is called then the atch is known to be kvx,
and it's better to choose some default for a user passing an unknown
mach value rather than segfaulting in decode_insn when env.opc_table
is NULL.
I've chosen the default mach to be bfd_mach_kv3_1, the default in
bfd/cpu-kvx.c, not that it matters very much. In normal objdump/gdb
usage, info->mach won't be an unexpected value.
* kvx-dis.c (kvx_dis_init): Return void. Don't error on
unexpected arch or mach. Default to bfd_mach_kv3_1 for
unknown mach. Don't clear info->disassembler_options.
|
|
A misplaced line, resulting in testsuite errors when attempting to use
as -m32.
* config.bfd (kvx-*-linux*): Add targ_selvecs.
(kvx-*-*): Remove targ_selvecs.
|
|
Add files submitted on the mailing list but somehow not committed.
|
|
|
|
The BPF virtual machine does not support neg instructions operating on
immediates, and these erroneous instructions were recently removed from
gas. Remove them from the simulator as well.
|
|
The neg/neg32 BPF instructions always use BPF_SRC_K (=0) in their header
source bit, despite operating on registers. If BPF_SRC_X (=1) is set,
the instructions are rejected by the kernel.
Because of this there are also no neg/neg32 instructions which operate
on immediates, so remove them.
bd434cc4d94ec3d2f9fc1e7c00c27b074f962bc1 was a similar fix in the old
CGEN-based port, but was not carried forward in the new port.
include/
* opcode/bpf.h (enum bpf_insn_id): Remove spurious entries
BPF_INSN_NEGI and BPF_INSN_NEG32I.
opcodes/
* bpf-opc.c (bpf_opcodes): Remove erroneous NEGI and NEG32I
instructions.
gas/
* doc/c-bpf.texi (BPF Instructions): Remove erroneous neg and
neg32 instructions operating on immediates.
* testsuite/gas/bpf/alu.s: Adapt accordingly.
* testsuite/gas/bpf/alu.d: Likewise.
* testsuite/gas/bpf/alu-be.d: Likewise
* testsuite/gas/bpf/alu32.s: Likewise.
* testsuite/gas/bpf/alu32.d: Likewise.
* testsuite/gas/bpf/alu32-be.d: Likewise.
* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.
|
|
The Scalable Matrix Extension v2 (SME2) defines a new register, ZT0, that
the Linux Kernel handles through a new NT_ARM_ZT register set.
Teach binutils/BFD about it so that gdb can make use of it for reading
and writing core files. This also enables readelf/objdump to show the
correct identification for the NT_ARM_ZT register set.
Validated under Fast Models.
|
|
Add required code to support core file dumps with NT_ARM_ZA and NT_ARM_SSVE
register sets in them.
These new register sets are dumped when SME is supported.
|
|
bfd_close ought to always call iovec->bclose so that cache_bclose is
called. If not, bfd_last_cache will be left pointing at freed memory.
This bug was found by oss-fuzz with the trigger being an old bug in
the ia64-vms support. Given a file of the "wrong" size,
elf64_vms_close_and_cleanup attempted to extend it, leading to an
error since the file was opened read-only by nm. nm bad_file bad_file
then hit the use-after-free when opening the second file.
commit 8219cab3f8 fixed multiple bugs of this type in bfd_close and
bfd_close_all_done, but didn't go quite far enough.
* elf64-ia64-vms.c (elf64_vms_close_and_cleanup): Don't
attempt to extend read-only files.
* opncls.c (bfd_close_all_done): Always call _close_and_cleanup.
An old bug in the ia64-vms support can be used to tickle another bug
in bfd_close_all_done. If _close_and_cleanup returns an error,
|
|
|
|
|
|
|
|
I get a couple of -Wmissing-declarations errors when building the sim.
This happens because an earlier patch added the declarations to a
cgen-generated header, but the recent re-generation then removed them.
This patch fixes the build by adding declarations just before the
definition. This is normally not best practice, but in this
particular situation it at leat un-breaks the build.
|
|
I saw this warning from make:
Makefile:5043: *** mixed implicit and normal rules: deprecated syntax
I believe this snuck in by error with the recent cgen-related changes.
This patch removes the stray '%' and rebuilds the Makefile.in. I'm
checking this in.
|
|
This regenerates sim files.
Tested with the following tools from a recent binutils build in
sim-site-config.exp, plus a few cross compilers.
set AS_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/gas/as-new"
set LD_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_AARCH64 "aarch64-linux-gnu-gcc"
set AS_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/gas/as-new"
set LD_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/ld/ld-new"
set CC_FOR_TARGET_ARM "arm-linux-gnueabi-gcc"
set AS_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/gas/as-new"
set LD_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/ld/ld-new"
set CC_FOR_TARGET_AVR ""
set AS_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/gas/as-new"
set LD_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/ld/ld-new"
set CC_FOR_TARGET_BFIN ""
set AS_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/gas/as-new"
set LD_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/ld/ld-new"
set CC_FOR_TARGET_BPF ""
set AS_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/gas/as-new"
set LD_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/ld/ld-new"
set CC_FOR_TARGET_CR16 ""
set AS_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/gas/as-new"
set LD_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/ld/ld-new"
set CC_FOR_TARGET_CRIS ""
set AS_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/gas/as-new"
set LD_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/ld/ld-new"
set CC_FOR_TARGET_D10V ""
set AS_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/gas/as-new"
set LD_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/ld/ld-new"
set CC_FOR_TARGET_FRV ""
set AS_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/gas/as-new"
set LD_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/ld/ld-new"
set CC_FOR_TARGET_FT32 ""
set AS_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/gas/as-new"
set LD_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/ld/ld-new"
set CC_FOR_TARGET_H8300 ""
set AS_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/gas/as-new"
set LD_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/ld/ld-new"
set CC_FOR_TARGET_IQ2000 ""
set AS_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/gas/as-new"
set LD_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_LM32 ""
set AS_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/gas/as-new"
set LD_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/ld/ld-new"
set CC_FOR_TARGET_M32C ""
set AS_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/gas/as-new"
set LD_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/ld/ld-new"
set CC_FOR_TARGET_M32R ""
set AS_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/gas/as-new"
set LD_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/ld/ld-new"
set CC_FOR_TARGET_M68HC11 ""
set AS_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/gas/as-new"
set LD_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/ld/ld-new"
set CC_FOR_TARGET_MCORE ""
set AS_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/gas/as-new"
set LD_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_MICROBLAZE "microblaze-linux-gnu-gcc"
set AS_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/gas/as-new"
set LD_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_MIPS "mips-linux-gnu-gcc"
set AS_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/gas/as-new"
set LD_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/ld/ld-new"
set CC_FOR_TARGET_MN10300 ""
set AS_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/gas/as-new"
set LD_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/ld/ld-new"
set CC_FOR_TARGET_MOXIE ""
set AS_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/gas/as-new"
set LD_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/ld/ld-new"
set CC_FOR_TARGET_MSP430 ""
set AS_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/gas/as-new"
set LD_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_OR1K ""
set AS_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/gas/as-new"
set LD_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_PPC "powerpc-linux-gnu-gcc"
set AS_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/gas/as-new"
set LD_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/ld/ld-new"
set CC_FOR_TARGET_PRU ""
set AS_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/gas/as-new"
set LD_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/ld/ld-new"
set CC_FOR_TARGET_RISCV ""
set AS_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/gas/as-new"
set LD_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/ld/ld-new"
set CC_FOR_TARGET_RL78 ""
set AS_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/gas/as-new"
set LD_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/ld/ld-new"
set CC_FOR_TARGET_RX ""
set AS_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/gas/as-new"
set LD_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/ld/ld-new"
set CC_FOR_TARGET_SH ""
set AS_FOR_TARGET_ERC32 ""
set LD_FOR_TARGET_ERC32 ""
set CC_FOR_TARGET_ERC32 ""
set AS_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/gas/as-new"
set LD_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/ld/ld-new"
set CC_FOR_TARGET_V850 ""
Results both before and after were:
FAIL: crisv10 mem1.ms (execution)
FAIL: crisv10 mem2.ms (execution)
FAIL: crisv32 mem1.ms (execution)
FAIL: crisv32 mem2.ms (execution)
FAIL: microblaze fail.s (execution)
FAIL: microblaze pass.s (execution)
expected passes 5288
unexpected failures 6
expected failures 3
untested testcases 373
unsupported tests 14
|
|
Regerating sim loses commit 1be79b1ebfad from sim/lm32/cpu.h, a
generated file, so this patch move those declarations to
sim/lm32/sim-main.h.
|
|
I had reason yesterday to want to regenerate configury files which I
do with --enable-maintainer-mode, and added --enable-cgen-maint
accidentally. The first problem I hit is that sim looks for cgen in a
different directory by default than opcodes, and I had my source
layout set up for opcodes rather than sim. Fix that by making both
use ../cgen first, then ../../cgen relative to sim/ and opcodes/. The
next problem was that various sim local.mk files expected generated
sources in the build dir rather than the source dir. Fix that by
adding $(srcdir) to paths. Finally, the generated iq2000 files had a
compile error, fixed by the cpu/iq2000.cpu patch.
cpu/
* iq2000.cpu (syscall): Add pc arg.
opcodes/
* configure.ac (cgendir): Default to ../../cgen, but use ../cgen
if found there.
* configure: Regenerate.
sim/m4/
* sim_ac_option_cgen_maint.m4 (cgendir): Look in ../cgen too.
sim/
* cris/local.mk: Add $(srcdir) to paths for regenerated source.
* frv/local.mk: Likewise.
* iq2000/local.mk: Likewise.
* lm32/local.mk: Likewise.
* m32r/local.mk: Likewise.
* or1k/local.mk: Likewise.
* Makefile.in: Regenerate.
* configure: Regenerate.
|
|
Remove some of the warnings generated by newer versions of ld.
* testsuite/lib/sim-defs.exp (prune_warnings_extra): New.
Arrange to run it from prune_warnings.
|
|
|
|
While looking at a bug, I noticed what I think is an off-by-one
mistake in a call to vector::reserve. This code:
new_args.reserve (args.size ());
new_args.push_back
(value_from_pointer (lookup_pointer_type (values_type), struct_addr));
new_args.insert (new_args.end (), args.begin (), args.end ());
... reserves 'size()' entries, but then proceeds to push one extra
one.
This shouldn't have any really bad effects, as insert will grow the
vector. Still, it seems better to use the correct size if we're going
to bother calling reserve.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30780
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
psympriv.h was intended for use by code that created partial symbols.
Now that no generic code needs psymtab.h any more, psympriv.h can be
merged into psymtab.h.
|
|
I found that most spots including psymtab.h do not need it. This
patch removes these includes, and also one unnecessary include of
psympriv.h.
|
|
The longest register name is 3 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also slightly reduces
the number of base relocations in the final image.
|
|
While they aren't opposites of each other, there also shouldn't be any
symbol for which both return true; both may return false. Therefore
use S_IS_EXTERNAL() in S_IS_LOCAL(), thus subsuming the sanity check
which so far both did alike.
|
|
bfd/
* elfxx-riscv.c (riscv_multi_subset_supports_ext): Return "c or zca"
rather than "c".
|
|
|
|
I noticed minidebug.c was still using explicit malloc and free, where
a vector would be more automatic.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
gp-display-gui (https://savannah.gnu.org/projects/gprofng-gui)
can be installed in a different directory.
In this case, $PATH is used to look up gp-display-text.
execv() does not use $PATH to find the executable.
gprofng/ChangeLog
2023-08-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/gp-display-text.cc (reexec): Use execvp instead of execv.
|
|
This commit extends the breakpoint mechanism to allow for inferior
specific breakpoints (but not watchpoints in this commit).
As GDB gains better support for multiple connections, and so for
running multiple (possibly unrelated) inferiors, then it is not hard
to imagine that a user might wish to create breakpoints that apply to
any thread in a single inferior. To achieve this currently, the user
would need to create a condition possibly making use of the $_inferior
convenience variable, which, though functional, isn't the most user
friendly.
This commit adds a new 'inferior' keyword that allows for the creation
of inferior specific breakpoints.
Inferior specific breakpoints are automatically deleted when the
associated inferior is removed from GDB, this is similar to how
thread-specific breakpoints are deleted when the associated thread is
deleted.
Watchpoints are already per-program-space, which in most cases mean
watchpoints are already inferior specific. There is a small window
where inferior-specific watchpoints might make sense, which is after a
vfork, when two processes are sharing the same address space.
However, I'm leaving that as an exercise for another day. For now,
attempting to use the inferior keyword with a watchpoint will give an
error, like this:
(gdb) watch a8 inferior 1
Cannot use 'inferior' keyword with watchpoints
A final note on the implementation: currently, inferior specific
breakpoints, like thread-specific breakpoints, are inserted into every
inferior, GDB then checks once the inferior stops if we are in the
correct thread or inferior, and resumes automatically if we stopped in
the wrong thread/inferior.
An obvious optimisation here is to only insert breakpoint locations
into the specific program space (which mostly means inferior) that
contains either the inferior or thread we are interested in. This
would reduce the number times GDB has to stop and then resume again in
a multi-inferior setup.
I have a series on the mailing list[1] that implements this
optimisation for thread-specific breakpoints. Once this series has
landed I'll update that series to also handle inferior specific
breakpoints in the same way. For now, inferior specific breakpoints
are just slightly less optimal, but this is no different to
thread-specific breakpoints in a multi-inferior debug session, so I
don't see this as a huge problem.
[1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
|
|
When building gdb with -O2 -flto on openSUSE Tumbleweed (using bison 3.8.2) I
run into:
...
ada-exp.c.tmp:653: warning: type 'yysymbol_kind_t' violates the C++ One \
Definition Rule [-Wodr]
c-exp.c.tmp:398: note: an enum with different value name is defined in \
another translation unit
ada-exp.c.tmp:660: note: name 'YYSYMBOL_NULL_PTR' differs from name \
'YYSYMBOL_COMPLEX_INT' defined in another translation unit
c-exp.c.tmp:405: note: mismatching definition
...
Fix this by renaming to ada_exp_yysymbol_kind_t and likewise for other .y
files.
Tested on x86_64-linux.
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
|
|
The elf32-kvx.c and elf64-kvx.c rules in the bfd makefile are
different to the other similar generated files, and that reminded me
that we need to have $srcdir in the generated #line reference back to
the source for debugging, but don't want it for comments in bfd.pot
(because then bfd.pot will likely reference Nick's source tree).
This patch fixes that by making all the #line use $srcdir by virtue of
using $<, and edits bfd.pot.
I also uniq list of files to remove duplicated elfxx-x86.c, sort lists
of files and regen with our standard automake/autoconf.
* configure: Regenerate.
bfd/
* Makefile.am: Sort various lists of files. Use $< in #line
directive of generated C files.
(po/SRC-POTFILES.in): uniq SRC_POTFILES.
(po/BLD-POTFILES.in): uniq BFD_POTFILES.
* Makefile.in: Regenerate.
* po/Make-in (bfd.pot): Edit out source dir from comments.
* po/SRC-POTFILES.in: Regenerate.
gas/
* Makefile.in: Regenerate.
* configure: Regenerate.
* po/POTFILES.in: Regenerate.
ld/
* Makefile.am (ALL_64_EMULATION_SOURCES): Sort.
* Makefile.in: Regenerate.
|
|
Commit f00b50d057 went the wrong way. As the comment says this
function is only applicable to fr550. If not fr550 return 1,
meaning we don't have acc restrictions.
|
|
When building gdb with -std=c++20, I run into:
...
gdbsupport/default-init-alloc.h:52:12: error: ‘construct’ has not been \
declared in ‘class std::allocator<unsigned char>’
52 | using A::construct;
| ^~~~~~~~~
...
Indeed, std::allocator::construct has been deprecated in c++17 and removed in
c++20.
Fix this by using instead std::pmr::polymorphic_allocator for c++20.
Tested on x86_64-linux.
|
|
In target_read_auxv we return a copy of an object:
...
gdb::optional<gdb::byte_vector>
target_read_auxv ()
{
...
return info->data;
}
...
Return a const reference instead, saving a copy.
This is exposed by using std::pmr::polymorphic_allocator instead of
std::allocator in default_init_allocator.
Tested on x86_64-linux.
|
|
When building gdb with -std=c++20, I run into:
...
gdb/dwarf2/read.c:2709:3: error: invalid conversion from ‘const char8_t*’ to \
‘const char*’ [-fpermissive]
2709 | u8"u8função",
| ^~~~~~~~~~~~
| |
| const char8_t*
...
Fix this by making the conversion explicit.
Tested on x86_64-linux.
|
|
When building gdb with -std=c++20 I run into:
...
gdb/ada-lang.c:10713:16: error: implicit capture of ‘this’ via ‘[=]’ is \
deprecated in C++20 [-Werror=deprecated]
10713 | auto do_op = [=] (LONGEST x, LONGEST y)
| ^
gdb/ada-lang.c:10713:16: note: add explicit ‘this’ or ‘*this’ capture
...
Fix this by using "[this]".
Likewise in two more spots.
Tested on x86_64-linux.
|
|
When building gdb with -std=c++20, I run into:
...
include/ansidecl.h:342:9: error: expected unqualified-id before ‘const’
342 | TYPE (const TYPE&) = delete; \
| ^~~~~
gdb/ui-out.h:412:3: note: in expansion of macro ‘DISABLE_COPY_AND_ASSIGN’
412 | DISABLE_COPY_AND_ASSIGN (ui_out_emit_type<Type>);
| ^~~~~~~~~~~~~~~~~~~~~~~
...
Fix this by using "DISABLE_COPY_AND_ASSIGN (ui_out_emit_type)".
Tested on x86_64-linux.
|
|
When building gdb with clang 15 and -std=c++20, I run into:
...
gdbsupport/poison.h:52:11: error: 'is_pod<timeval>' is deprecated: use \
is_standard_layout && is_trivial instead [-Werror,-Wdeprecated-declarations]
std::is_pod<T>>
^
...
Fix this by following the suggestion.
Likewise in gdb/unittests/ptid-selftests.c.
Tested on x86_64-linux.
|
|
When building gdb with clang 15 and -std=c++20, I run into:
...
gdbsupport/common-exceptions.h:203:32: error: arithmetic between different \
enumeration types ('const enum return_reason' and 'const enum errors') is \
deprecated [-Werror,-Wdeprecated-enum-enum-conversion]
size_t result = exc.reason + exc.error;
~~~~~~~~~~ ^ ~~~~~~~~~
...
Fix this by using to_underlying.
Likewise in a few other places.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/vfork-follow-parent.exp, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.base/vfork-follow-parent.exp.
ERROR: error copying "vforked-prog": no such file or directory
while executing
"file copy -force $fromfile $tofile"
(procedure "gdb_remote_download" line 29)
invoked from within
"gdb_remote_download target $binfile3"
...
Fix this by:
- making the copy-to-remote conditional on is_remote target, and
- allowing gdb_remote_download to find $binfile3 by using
standard_output_file.
Also remove unused variable remote_exec_prog.
Tested on x86_64-linux.
|
|
5be1b787276d2adbe85ae7febc709ca517b62f08
|
|
This commit changes the BPF GAS port in order to handle immediate
overflows the same way than the clang BPF assembler:
- For an immediate field of N bits, any written number (positive or
negative) whose two's complement encoding fit in N its is accepted.
This means that -2 is the same than 0xffffffe. It is up to the
instructions to decide how to interpret the encoded value.
- Immediate fields in jump instructions are no longer relaxed.
Relaxing to jump instructions with wider range is only performed
when expressions are involved.
- The manual is updated to document this, and testsuite adapted
accordingly.
Tested in x86_64-linux-gnu host, bpf-unknown-none target.
gas/ChangeLog:
2023-08-17 Jose E. Marchesi <jose.marchesi@oracle.com>
* config/tc-bpf.c (check_immediate_overflow): New function.
(encode_insn): Use check_immediate_overflow.
(md_assemble): Do not relax instructions with
constant disp16 fields.
* doc/c-bpf.texi (BPF Instructions): Add note about how numerical
literal values are interpreted for instruction immediate operands.
* testsuite/gas/bpf/disp16-overflow.s: Adapt accordingly.
* testsuite/gas/bpf/jump-relax-jump.s: Likewise.
* testsuite/gas/bpf/jump-relax-jump.d: Likewise.
* testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
* testsuite/gas/bpf/jump-relax-ja.s: Likewise.
* testsuite/gas/bpf/jump-relax-ja.d: Likewise.
* testsuite/gas/bpf/jump-relax-ja-be.d: Likewise.
* testsuite/gas/bpf/disp16-overflow-relax.l: Likewise.
* testsuite/gas/bpf/imm32-overflow.s: Likewise.
* testsuite/gas/bpf/disp32-overflow.s: Likewise.
* testsuite/gas/bpf/disp16-overflow.l: Likewise.
* testsuite/gas/bpf/disp32-overflow.l: Likewise.
* testsuite/gas/bpf/imm32-overflow.l: Likewise.
* testsuite/gas/bpf/offset16-overflow.l: Likewise.
|
|
If we're using dump_prog in a test which fails, log the dump.out contents
to ld.log to aid debugging.
This avoids needing to ask reporters to manually run e.g. `objdump` commands
when making bug reports.
PR30722
* ld/testsuite/lib/ld-lib.exp: Log failed dump.out contents to aid
debugging.
Approved-by: Nick Clifton <nickc@redhat.com>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
While working on a dwarf assembly test-case I accidentally created the
following pathological dwarf:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xbe>
...
and noticed gdb segfaulting during cooked index creating due to running out of
stack. This is a regression from gdb-12, where gdb just hung.
Fix this by inhibiting the scan_attributes self-recursion for self-references.
The same test-case with -readnow makes gdb hang, so also fix this in
dwarf2_attr and follow_die_ref.
Note that this doesn't fix the same problems for the more complicated case of:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xc6>
<1><c6>: Abbrev Number: 4 (DW_TAG_class_type)
<c7> DW_AT_name : c2
<ca> DW_AT_specification: <0xbe>
...
but the approach for deciding whether to fix pathological dwarf cases is as
per PR27981 comment 3:
...
yes if it is cheap/obvious, and no if it is something complicated or expensive.
...
and at this point I'm not sure whether fixing this will fall in the first
category.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A bug report pointed out a buffer overflow in ada_decode, which Keith
helpfully analyzed. ada_decode had a logic error when the input was
all digits. While this isn't valid -- and would probably only appear
in fuzzer tests -- it still should be handled properly.
This patch adds a missing bounds check. Tested with the self-tests in
an asan build.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30639
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
I found an obvious bug in Ada aggregate expression handling:
if (vvo != nullptr)
error (_("Invalid record component association."));
name = vvo->get_symbol ()->natural_name ();
Here the code errors when vvo is not null -- and then proceeds to use
vvo.
This hasn't caused a crash because, I believe, there's currently no
way to reach this code in the null case. However, I'm not really
willing to assert this...
Fixing this shows another bug, which is that due to the way the parser
works, a field name in an aggregate expression might erroneously be
fully qualified if some global variable with the same base name
exists.
The included test case triggers both bugs. Note that the test
includes a confounding case for array aggregates as well, but as these
are harder to fix, I've left it as kfail.
As this is Ada-specific, and has already been tested internally at
AdaCore, I am checking it in.
|
|
DAP specifies an event that should be sent when a module is removed.
This patch implements this.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
I ran into a test failure on gdb.python/py-thread-exited.c. The test
creates two threads and then catches the thread exits in Python. The
test expects the threads to exit in a specific order.
As the test is currently written, it is _likely_, but not guaranteed,
that the threads will exit in the same order they are created, which
is what the test expects.
When running on a loaded system I ran into a case where the threads
exited in the reverse creation order, which caused the test to fail.
I could fix this by having the .exp file not care about the thread
order, or by changing the C file to force the order. I chose the
later, and added a pthread_barrier_t to ensure the threads exit in the
correct order.
There should be no change in what is tested after this commit.
|
|
It was pointed out on the mailing list[1] that after this commit:
commit b1e0126ec56e099d753c20e91a9f8623aabd6b46
Date: Wed Jun 21 14:18:54 2023 +0100
gdb: don't resume vfork parent while child is still running
the test gdb.base/vfork-follow-parent.exp now has some failures when
run with the native-gdbserver or native-extended-gdbserver boards:
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2 (timeout)
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1 (timeout)
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: print unblock_parent = 1 (timeout)
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (timeout)
The reason that these failures don't show up when run on the standard
unix board is that the test is only run in the default operating mode,
so for Linux this will be all-stop on top of non-stop.
If we adjust the test script so that it runs in the default mode and
with target-non-stop turned off, then we see the same failures on the
unix board. This commit includes this change.
The way that the test is written means that it is not (currently)
possible to turn on non-stop mode and have the test still work, so
this commit does not do that.
I have also updated the test script so that the vfork child performs
an exec as well as the current exit. Exec and exit are the two ways
in which a vfork child can release the vfork parent, so testing both
of these cases is useful I think.
In this test the inferior performs a vfork and the vfork-child
immediately exits. The vfork-parent will wait for the vfork-child and
then blocks waiting for gdb. Once gdb has released the vfork-parent,
the vfork-parent also exits.
In the test that fails, GDB sets 'detach-on-fork off' and then runs to
the vfork. At this point the test tries to just "continue", but this
fails as the vfork-parent is still selected, and the parent can't
continue until the vfork-child completes. As the vfork-child is
stopped by GDB the parent will never stop once resumed, so GDB refuses
to resume it.
The test script then sets 'schedule-multiple on' and once again
continues. This time GDB, in theory, resumes both the parent and the
child, the parent will be held blocked by the kernel, but the child
will run until it exits, and which point GDB stops again, this time
with inferior 2, the newly exited vfork-child, selected.
What happens after this in the test script is irrelevant as far as
this failure is concerned.
To understand why the test started failing we should consider the
behaviour of four different cases:
1. All-stop-on-non-stop before commit b1e0126ec56e,
2. All-stop-on-non-stop after commit b1e0126ec56e,
3. All-stop-on-all-stop before commit b1e0126ec56e, and
4. All-stop-on-all-stop after commit b1e0126ec56e.
Only case #4 is failing after commit b1e0126ec56e, but I think the
other cases are interesting because, (a) they inform how we might fix
the regression, and (b) it turns out the behaviour of #2 changed too
with the commit, but the change was harmless.
For #1 All-stop-on-non-stop before commit b1e0126ec56e, what happens
is:
1. GDB calls proceed with the vfork-parent selected, as schedule
multiple is on user_visible_resume_ptid returns -1 (everything)
as the resume_ptid (see proceed function),
2. As this is all-stop-on-non-stop, every thread is resumed
individually, so GDB tries to resume both the vfork-parent and the
vfork-child, both of which succeed,
3. The vfork-parent is held stopped by the kernel,
4. The vfork-child completes (exits) at which point the GDB sees the
EXITED event for the vfork-child and the VFORK_DONE event for the
vfork-parent,
5. At this point we might take two paths depending on which event
GDB handles first, if GDB handles the VFORK_DONE first then:
(a) As GDB is controlling both parent and child the VFORK_DONE is
ignored (see handle_vfork_done), the vfork-parent will be
resumed,
(b) GDB processes the EXITED event, selects the (now defunct)
vfork-child, and stops, returning control to the user.
Alternatively, if GDB selects the EXITED event first then:
(c) GDB processes the EXITED event, selects the (now defunct)
vfork-child, and stops, returning control to the user.
(d) At some future time the user resumes the vfork-parent, at
which point the VFORK_DONE is reported to GDB, however, GDB
is ignoring the VFORK_DONE (see handle_vfork_done), so the
parent is resumed.
For case #2, all-stop-on-non-stop after commit b1e0126ec56e, the
important difference is in step (2) above, now, instead of resuming
both the vfork-parent and the vfork-child, only the vfork-child is
resumed. As such, when we get to step (5), only a single event, the
EXITED event is reported.
GDB handles the EXITED just as in (5)(c), then, later, when the user
resumes the vfork-parent, the VFORKED_DONE is immediately delivered
from the kernel, but this is ignored just as in (5)(d), and so,
though the pattern of when the vfork-parent is resumed changes, the
overall pattern of which events are reported and when, doesn't
actually change. In fact, by not resuming the vfork-parent, the order
of events (in this test) is now deterministic, which (maybe?) is a
good thing.
If we now consider case #3, all-stop-on-all-stop before commit
b1e0126ec56e, then what happens is:
1. GDB calls proceed with the vfork-parent selected, as schedule
multiple is on user_visible_resume_ptid returns -1 (everything)
as the resume_ptid (see proceed function),
2. As this is all-stop-on-all-stop, the resume is passed down to the
linux-nat target, the vfork-parent is the event thread, while the
vfork-child is a sibling of the event thread,
3. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
for all threads, this causes the vfork-child to be resumed. Then
in linux_nat_target::resume, the event thread, the vfork-parent,
is also resumed.
4. The vfork-parent is held stopped by the kernel,
5. The vfork-child completes (exits) at which point the GDB sees the
EXITED event for the vfork-child and the VFORK_DONE event for the
vfork-parent,
6. We are now in a situation identical to step (5) as for
all-stop-on-non-stop above, GDB selects one of the events to
handle, and whichever we select the user sees the correct
behaviour.
And so, finally, we can consider #4, all-stop-on-all-stop after commit
b1e0126ec56e, this is the case that started failing.
We start out just like above, in proceed, the resume_ptid is
-1 (resume everything), due to schedule multiple being on. And just
like above, due to the target being all-stop, we call
proceed_resume_thread_checked just once, for the current thread,
which, remember, is the vfork-parent thread.
The change in commit b1e0126ec56e was to avoid resuming a vfork-parent
thread, read the commit message for the justification for this change.
However, this means that GDB now rejects resuming the vfork-parent in
this case, which means that nothing gets resumed! Obviously, if
nothing resumes, then nothing will ever stop, and so GDB appears to
hang.
I considered a couple of solutions which, in the end, I didn't go
with, these were:
1. Move the vfork-parent check out of proceed_resume_thread_checked,
and place it in proceed, but only on the all-stop-on-non-stop
path, this should still address the issue seen in b1e0126ec56e,
but would avoid the issue seen here. I rejected this just
because it didn't feel great to split the checks that exist in
proceed_resume_thread_checked like this,
2. Extend the condition in proceed_resume_thread_checked by adding a
target_is_non_stop_p check. This would have the same effect as
idea 1, but leaves all the checks in the same place, which I
think would be better, but this still just didn't feel right to
me, and so,
What I noticed was that for the all-stop-on-non-stop, after commit
b1e0126ec56e, we only resumed the vfork-child, and this seems fine.
The vfork-parent isn't going to run anyway (the kernel will hold it
back), so if feels like we there's no harm in just waiting for the
child to complete, and then resuming the parent.
So then I started looking at follow_fork, which is called from the top
of proceed. This function already has the task of switching between
the parent and child based on which the user wishes to follow. So, I
wondered, could we use this to switch to the vfork-child in the case
that we are attached to both?
Turns out this is pretty simple to do.
Having done that, now the process is for all-stop-on-all-stop after
commit b1e0126ec56e, and with this new fix is:
1. GDB calls proceed with the vfork-parent selected, but,
2. In follow_fork, and follow_fork_inferior, GDB switches the
selected thread to be that of the vfork-child,
3. Back in proceed user_visible_resume_ptid returns -1 (everything)
as the resume_ptid still, but now,
4. When GDB calls proceed_resume_thread_checked, the vfork-child is
the current selected thread, this is not a vfork-parent, and so
GDB allows the proceed to continue to the linux-nat target,
5. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
for all threads, this does not resume the vfork-parent (because
it is a vfork-parent), and then the vfork-child is resumed as
this is the event thread,
At this point we are back in the same situation as for
all-stop-on-non-stop after commit b1e0126ec56e, that is, the
vfork-child is resumed, while the vfork-parent is held stopped by
GDB.
Eventually the vfork-child will exit or exec, at which point the
vfork-parent will be resumed.
[1] https://inbox.sourceware.org/gdb-patches/3e1e1db0-13d9-dd32-b4bb-051149ae6e76@simark.ca/
|
