linux_handle_extended_wait calls target_post_attach if we're handling
a PTRACE_EVENT_CLONE, and libthread_db.so isn't active.
target_post_attach just calls linux_init_ptrace_procfs to set the
lwp's ptrace options. However, this is completely unnecessary,
because, as man ptrace [1] says, options are inherited:
"Flags are inherited by new tracees created and "auto-attached" via
active PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE
options."
This removes the unnecessary call.
[1] - https://man7.org/linux/man-pages/man2/ptrace.2.html
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I533eaa60b700f7e40760311fc0d344d0b3f19a78
The install code was using $SUBDIRS to track all enabled arches. This
works, but isn't great if we want to add a subdir that isn't an arch
port, or as we merge the subdirs into the top-level. Create a new var
explicitly to track the list of enabled arches instead.
gas uses ZSTD_compressStream2 which is only available with libzstd >=
1.4.0, leading to build errors when an older version is installed.
This patch updates the check libzstd presence to check its version is
>= 1.4.0. However, since gas seems to be the only component requiring
such a recent version this may imply that we disable ZSTD support for
all components although some would still benefit from an older
version.
I ran 'autoreconf -f' in all directories containing a configure.ac
file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed
several errors from autoheader in readline, as well as warnings in
intl, but they are unrelated to this patch.
This should fix some of the buildbots.
OK for trunk?
Thanks,
Christophe
Call the helper function "check_shared_lib_support" to ensure -shared
is enabled before launching ld-shared, ld-elfweak and ld-elfvers.
This allows to catch custom targets explicitly disabling it.
ld/ChangeLog:
* testsuite/ld-elfvers/vers.exp: Call check_shared_lib_support.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
Despite that the RISC-V ISA Manual version 2.2 prohibited "RV32EF", later
versions beginning with the version 20190608-Base-Ratified removed this
restriction. Because the 'E' extension is still a draft, the author chose
to *just* remove the conflict (not checking the ISA version).
Note that, because RV32E is only used with a soft-float calling convention,
there's no valid official ABI for RV32EF. It means, even if we can assemble
a program with -march=rv32ef -mabi=ilp32e, floating-point registers are kept
in an unmanaged state (outside ABI management).
The purpose of this commit is to suppress unnecessary errors while parsing
an ISA string and/or disassembling, not to allow hard-float with RVE.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts): Accept RV32EF
because only older specifications disallowed it.
gas/ChangeLog:
* testsuite/gas/riscv/march-fail-rv32ef.d: Remove as not directly
prohibited.
* testsuite/gas/riscv/march-fail-rv32ef.l: Likewise.
This was needed when the install step was run in subdirs, but now
that we process that entirely in the top-level, we don't need to
pass this down, so drop it.
MI version 1 is long since obsolete. Rather than remove it
immediately (though I did send a patch for that), instead let's
deprecate it in GDB 13 and then remove it for GDB 14.
This version of the patch incorporates Simon's warning change, and
Luis' recommendation to mention the gdb versions here.
Automake will run each subdir individually before moving on to the next
one. This means that the linking phase, a single threaded process, will
not run in parallel with anything else. When we have to link ~32 ports,
that's 32 link steps that don't take advantage of parallel systems. On
my really old 4-core system, this cuts a multi-target build from ~60 sec
to ~30 sec. We eventually want to move all compile+link steps to this
common dir anyways, so might as well move linking now for a nice speedup.
We use noinst_PROGRAMS instead of bin_PROGRAMS because we're taking care
of the install ourselves rather than letting automake process it.
We still have to maintain custom install rules due to how we rename
arch-specific files with an arch prefix in their name, but we can at
least unify the logic in the common dir.
Nothing in the tree checks this option, or has checked for decades.
The pre-cvs-import ChangeLog suggests this was added & removed back
then, but can't be sure as that history doesn't exist in the VCS.
Nothing checks this define anywhere, so drop all the logic. We don't
want this to be a configure option in the first place as all such usage
should be automatic & following proper types.
This has only ever had a single option that's enabled by default.
The objects it adds are pretty small and don't add overhead at
runtime if it isn't used, so just enable it all the time to make
the build code simpler.
Update expected PR binutils/26160 test output for readelf out change
and run PR binutils/26160 test.
PR binutils/26160
* testsuite/binutils-all/pr26160.r: Updated.
* testsuite/binutils-all/readelf.exp: Run PR binutils/26160 test.
One test name in gdb.base/dlmopen.exp changes from run to run
since it includes a process id:
PASS: gdb.base/dlmopen.exp: attach 3442682
This is not convenient do diff gdb.sum files to compare test runs.
Fix by using gdb_attach helper function to handle attaching to the
process as it produce a constant test name.
While at it also check gdb_attach's return value to only run the
rest of the test if the attach was successful.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, and pmxvi16ger2* instructions were officially changed to
pmdmxbf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively. The old mnemonics are still supported by the
assembler as extended mnemonics. The disassembler generates the new
mnemonics. The name changes occurred in commit:
commit bb98553cad
Author: Peter Bergner <bergner@linux.ibm.com>
Date: Sat Oct 8 16:19:51 2022 -0500
PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
gas/
* config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
* testsuite/gas/ppc/rfc02658.s: New test.
* testsuite/gas/ppc/rfc02658.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
opcodes/
* ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
(powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
This patch updates the comments in the various gdb files to reflect the
name changes. There are no functional changes made by this patch.
The older instruction names are still used in the test
gdb.reverse/ppc_record_test_isa_3_1.exp for backwards compatibility.
Patch has been tested on Power 10 with no regressions.
The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, pmxvi16ger2* instructions were officially changed to
pmdmxvf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively. The old mnemonics are still supported by the
assembler as extended mnemonics. The disassembler generates the new
mnemonics. The name changes occurred in commit:
commit bb98553cad
Author: Peter Bergner <bergner@linux.ibm.com>
Date: Sat Oct 8 16:19:51 2022 -0500
PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
gas/
* config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
* testsuite/gas/ppc/rfc02658.s: New test.
* testsuite/gas/ppc/rfc02658.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
opcodes/
* ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
(powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
The above commit results in about 224 failures on Power 10 since the
disassembled names do not match the expected names in the test. This
patch updates the expected names in the test to match the values produced
by the disassembler.
This patch updates file gdb.arch/powerpc-power10.exp with the new expected
values to the instructions. The comment giving the name of the instruction
for each binary value in the file gdb.arch/powerpc-power10.c is updated
with the new name. There are no functional changes in file
gdb.arch/powerpc-power10.c.
The test disassembles function foo and searches for the line
"End of assembler dump" to determing the last address in the function. The
assumption is the last instruction will be given right before the line
"End of assembler dump". This assumption fails on PowerPC.
The PowerPC disassembly of the function foo looks like:
Dump of assembler code for function foo:
# => 0x00000000100006dc <+0>: std r31,-8(r1)
# 0x00000000100006e0 <+4>: stdu r1,-48(r1)
# 0x00000000100006e4 <+8>: mr r31,r1
# 0x00000000100006e8 <+12>: nop
# 0x00000000100006ec <+16>: addi r1,r31,48
# 0x00000000100006f0 <+20>: ld r31,-8(r1)
# 0x00000000100006f4 <+24>: blr
# 0x00000000100006f8 <+28>: .long 0x0
# 0x00000000100006fc <+32>: .long 0x0
# 0x0000000010000700 <+36>: .long 0x1000180
# End of assembler dump.
The blr instruction is the last instruction in function foo. The lines
with .long following the blr instruction need to be ignored.
This patch adds a new condition to the gdb_test_multiple "disassemble foo"
test to ignore the lines with the .long.
The patch has been tested on PowerPC and Intel X86-64.
Recent changes to gdb.reverse/step-reverse.exp revealed the latent bug
PR record/29745, where we can't skip one funcion forward if we're using
native-gdbserver. This commit just adds kfails to the test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29745
Approved-By: Simon Marchi <simon.marchi@efficios.com>
After this commit:
commit 6576bffe6c
Date: Thu Jul 7 13:43:45 2022 +0100
opcodes/arm: add disassembler styling for arm
Some people were seeing their builds failing with complaints about a
possible uninitialized variable usage. I previously fixed an instance
of this issue in this commit:
commit 2df82cd4b4
Date: Tue Nov 1 10:36:59 2022 +0000
opcodes/arm: silence compiler warning about uninitialized variable use
which did fix the build problems that the sourceware buildbot was
hitting, however, an additional instance of the same problem was
brought to my attention, and that is fixed in this commit.
Where commit 2df82cd4b4 fixed the uninitialized variable problem in
print_mve_unpredictable, this commit fixes the same problem in
print_mve_undefined.
As with the previous commit, I don't believe we could really ever get
an uninitialized variable usage, based on the current usage of the
function, so I have just initialized the reason variable to "??".
These manual settings were necessary when we weren't doing automatic
header dependency tracking. That was changed a while ago, and we use
automake now to do it all for us. As a result, many of these vars
aren't even referenced anymore.
Further, some of the source file generation (e.g. .c files, or igen,
or cgen outputs) were moved to the common automake build, and it takes
care of dependency tracking for us with the object files.
This patch is based on MULTIPLE_FRAME_SECTIONS and EH_FRAME_LINKONCE,
it allows backend to enable this feature and use '--gc-sections' simply.
* gas/dw2gencfi.h (TARGET_MULTIPLE_EH_FRAME_SECTIONS): New.
(MULTIPLE_FRAME_SECTIONS): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS.
* gas/dw2gencfi.c (EH_FRAME_LINKONCE): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS.
(is_now_linkonce_segment): Likewise.
(get_cfi_seg): Create relocation info between .eh_frame.* and .text.* section.
* bfd/elf-bfd.h (elf_backend_can_make_multiple_eh_frame): New.
* bfd/elfxx-target.h (elf_backend_can_make_multiple_eh_frame): Likewise.
* bfd/elflink.c (_bfd_elf_default_action_discarded): Add checking for
elf_backend_can_make_multiple_eh_frame.
We have configure tests for this in the top-level configure script
to link this when necessary, so we don't need to explicitly list it
for specific ports.
With more C libraries moving functions entirely into the main -lc,
change the AC_CHECK_LIB calls to AC_SEARCH_LIBS so we look in there
first and avoid extra linkage when possible.
COMMON_LIBS is set to $(LIBS), and CONFIG_LIBS is set to that plus
@LIBS@. This leds to the values being used twice. Inline the
CONFIG_LIBS variable without @LIBS@ since it's used only once.
The top-level already sets up a libtool script for the host, so use
that when linking rather than invoking CC directly. This will also
happen when we (someday) move the building to pure automake.
This test uses the test itself as an input to stating regular files.
This gets funky though: when we run check in parallel, the output
object dir is the subdir that matches the .exp file. When we run
with -j1, the output object dir is the sim builddir itself.
The old test would append argv[0] to find the file, while the new
test uses basename on it. Each method works in only one of the
aforementioned build scenarios. Rather than complicate this any
more, switch to a different file that we know will always exist:
the Makefile.
This test assumes that /bin/sh will never be a CRIS ELF by way of
assuming that the current bfd cannot load it (since a basic cris
cross-compiler only understands CRIS ELFs). In a multi-target
build though, bfd understands just about every ELF out there, so
we're able to read the /bin/sh format before failing at a diff
point in the cris code.
Let's switch to using / instead since it'll fail for a similar
reason (at least similar enough for what this test is testing).
