Tom Tromey [Sun, 13 Aug 2023 16:37:00 +0000 (10:37 -0600)]
Remove alloca from osabi.c
I noticed that the call to alloca in osabi.c can be replaced with a
statically-sized buffer, because some code just before the declaration
ensures that the length is bounded.
Tom de Vries [Mon, 14 Aug 2023 16:32:29 +0000 (18:32 +0200)]
[gdb/build] Fix struct token odr violation
When building gdb with -O2 -flto I run into:
...
/data/vries/gdb/src/gdb/c-exp.y:2450:8: warning: type 'struct token' \
violates the C++ One Definition Rule [-Wodr]
struct token
^
/data/vries/gdb/src/gdb/d-exp.y:939:8: note: a different type is defined in \
another translation unit
struct token
^
...
Fix this by renaming to c_token and d_token.
Likewise in:
- fortran-exp.y, renaming to f_token,
- go-exp.y, renaming to go_token, and
- p-exp.y, renaming to p_token.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
When build gdb with -O2 -flto I run into:
...
gdb/c-exp.y:3003:8: warning: type 'struct token_and_value' violates the C++ \
One Definition Rule [-Wodr]
struct token_and_value
^
gdb/d-exp.y:1310:8: note: a different type is defined in another translation \
unit
struct token_and_value
^
...
Fix this by renaming to c_token_and_value and d_token_and_value.
Likewise in gdb/go-exp.y, renaming to go_token_and_value.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
Tom de Vries [Mon, 14 Aug 2023 16:32:29 +0000 (18:32 +0200)]
[gdb/build] Fix enum param_types odr violation
When building gdb with -O2 -flto, I run into:
...
gdb/guile/scm-param.c:121:6: warning: type 'param_types' violates the C++ \
One Definition Rule [-Wodr]
enum param_types
^
gdb/python/py-param.c:33:6: note: an enum with different value name is \
defined in another translation unit
enum param_types
^
...
Fix this by renaming to enum scm_param_types and py_param_types.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
Tom de Vries [Mon, 14 Aug 2023 16:32:29 +0000 (18:32 +0200)]
[gdb/build] Remove superfluous variable param_types in gdb/python/py-param.c
In gdb/python/py-param.c we have:
...
enum param_types
{
...
}
param_types;
...
which declares both an enum param_types, and an unused variable param_types.
Tom de Vries [Mon, 14 Aug 2023 16:27:02 +0000 (18:27 +0200)]
[gdb] Fix maint print symbols/psymbols help text
Consider the help text of "maint print symbols":
...
(gdb) help maint print symbols
Print dump of current symbol definitions.
Usage: mt print symbols [-pc ADDRESS] [--] [OUTFILE]
mt print symbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
Entries in the full symbol table are dumped to file OUTFILE,
or the terminal if OUTFILE is unspecified.
If ADDRESS is provided, dump only the file for that address.
If SOURCE is provided, dump only that file's symbols.
If OBJFILE is provided, dump only that file's minimal symbols.
...
and "maint print psymbols":
...
(gdb) help maint print psymbols
Print dump of current partial symbol definitions.
Usage: mt print psymbols [-objfile OBJFILE] [-pc ADDRESS] [--] [OUTFILE]
mt print psymbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
Entries in the partial symbol table are dumped to file OUTFILE,
or the terminal if OUTFILE is unspecified.
If ADDRESS is provided, dump only the file for that address.
If SOURCE is provided, dump only that file's symbols.
If OBJFILE is provided, dump only that file's minimal symbols.
...
The OBJFILE lines mistakingly mention minimal symbols.
Fix this by reformulating as "dump only that object file's symbols".
Also make the ADDRESS lines more clear by using the formulation: "dump only
the symbols for the file with code at that address".
Tested on x86_64-linux.
Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
PR gdb/30742
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30742
Sam James [Mon, 14 Aug 2023 03:28:35 +0000 (04:28 +0100)]
ld: fix relocatable, retain7a target pattens for HPPA
Fix issue reported by Dave and Alan.
Put back the old pattern for hppa-*-linux* and add hppa[12]*-*-linux* to cover
Gentoo's hppa1.1 and hppa2.0 without including hppa64 inadvertently like I did
before.
ld/
PR 30733
PR 30734
* ld/testsuite/ld-elf/relocatable.d: Use better pattern to exclude hppa64
but include hppa1.1, hppa2.0.
* ld/testsuite/ld-elf/retain7a.d: Ditto.
Fixes: 0e339f6b4f2df25ed351cb94dc7fe16868626f49 Fixes: e3b66187192ce6840df283c00f6395bb0ff15cf5 Signed-off-by: Sam James <sam@gentoo.org>
Tom de Vries [Sun, 13 Aug 2023 12:08:06 +0000 (14:08 +0200)]
[gdb/symtab] Don't deduplicate variables in gdb-index
When running test-case gdb.python/py-symbol.exp with target board
cc-with-gdb-index, we run into:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
1^M
(gdb) FAIL: gdb.python/py-symbol.exp: print (len (gdb.lookup_static_symbols ('rr')))
...
[ Note that the test-case contains rr in both py-symtab.c:
...
static int __attribute__ ((used)) rr = 42; /* line of rr */
...
and py-symtab-2.c:
...
static int __attribute__ ((used)) rr = 99; /* line of other rr */
... ]
This passes with gdb-12-branch, and fails with gdb-13-branch.
AFAIU the current code in symtab_index_entry::minimize makes the assumption
that it's fine to store only one copy of rr in the gdb-index, because
"print rr" will only ever print one, and always the same.
But that fails to recognize that gdb supports gdb.lookup_static_symbols, which
returns a list of variables rather than the first one.
In other words, the current approach breaks feature parity between cooked
index and gdb-index.
Note btw that also debug-names has both instances:
...
[ 5] #00597969 rr:
<4> DW_TAG_variable DW_IDX_compile_unit=3 DW_IDX_GNU_internal=1
<4> DW_TAG_variable DW_IDX_compile_unit=4 DW_IDX_GNU_internal=1
...
Fix this in symtab_index_entry::minimize, by not deduplicating variables.
Tested on x86_64-linux, with target boards unix and cc-with-gdb-index.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
PR symtab/30720
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30720
gprofng GUI can be installed to the other directory.
In this case, $PATH is used to find gp-display-gui from gprofng
and option --gprofngdir is passed to gp-display-gui.
gprofng/ChangeLog
2023-08-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR 30715
* config/tc-vax.c (md_create_long_jump): Use pc-relative addressing.
* testsuite/gas/vax/broken_word.d,
* testsuite/gas/vax/broken_word.s: New test.
* testsuite/gas/vax/vax.exp: Run it.
Kevin Buettner [Tue, 1 Aug 2023 20:33:24 +0000 (13:33 -0700)]
gdbserver: Reinstall software single-step breakpoints in resume_stopped_resumed_lwps
At the moment, while performing a software single-step, gdbserver fails
to reinsert software single-step breakpoints for a LWP when
interrupted by a signal in another thread. This commit fixes this
problem by reinstalling software single-step breakpoints in
linux_process_target::resume_stopped_resumed_lwps in
gdbserver/linux-low.cc.
This bug was discovered due to a failing assert in maybe_hw_step()
in gdbserver/linux-low.cc. Looking at the backtrace revealed
that the caller was linux_process_target::resume_stopped_resumed_lwps.
I was uncertain whether the assert should still be valid when called
from that method, so I tried hoisting the assert from maybe_hw_step
to all callers except resume_stopped_resumed_lwps. But running the
new test case, described below, showed that merely eliminating the
assert for this case was NOT a good fix - a study of the log file for
the test showed that the single-step operation failed to occur.
Instead GDB (via gdbserver) stopped at the next breakpoint that was
hit.
Zhiyong Yan had proposed a fix which resinserted software single-step
breakpoints, albeit at a different location in linux-low.cc. Testing
revealed that, while running gdb.threads/pending-fork-event-detach,
the executable associated with that test would die due to a SIGTRAP
after the test program was detached. Examination of the core file(s)
showed that a breakpoint instruction had been left in program memory.
Test results were otherwise very good, so Zhiyong was definitely on
the right track!
This commit causes software single-step breakpoint(s) to be inserted
before the call to maybe_hw_step in resume_stopped_resumed_lwps. This
will cause 'has_single_step_breakpoints (thread)' to be true, so that
the assert in maybe_hw_step...
/* GDBserver must insert single-step breakpoint for software
single step. */
gdb_assert (has_single_step_breakpoints (thread));
...will no longer fail. And better still, the single-step breakpoints
are reinstalled, so that stepping will actually work, even when
interrupted.
The C code for the test case was loosely adapted from the reproducer
provided in Zhiyong's bug report for this problem. The .exp file was
copied from next-fork-other-thread.exp and then tweaked slightly. As
noted in a comment in next-fork-exec-other-thread.exp, I had to remove
"on" from the loop for non-stop as it was failing on all architectures
(including x86-64) that I tested. I have a feeling that it ought to
work, but this can be investigated separately and (re)enabled once it
works. I also increased the number of iterations for the loop running
the "next" commands. I've had some test runs which don't show the bug
until the loop counter exceeded 100 iterations. The C file for the
new test uses shorter delays than next-fork-other-thread.c though, so
it doesn't take overly long (IMO) to run this new test.
Running the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and
userland using a gdbserver build without the fix in this commit shows
the following results:
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=12: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=9: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=18: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=3: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=11: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=3: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=47: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=57: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=10: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to break here
=== gdb Summary ===
# of unexpected core files 12
# of expected passes 3011
# of unexpected failures 14
Each of the 12 core files were caused by the failed assertion in
maybe_hw_step in linux-low.c. These correspond to 12 of the
unexpected failures.
When the tests are run using a gdbserver build which includes the fix
in this commit, the results are significantly better, but not perfect:
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=143: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=25: next to other line
=== gdb Summary ===
# of expected passes 10178
# of unexpected failures 2
I think that the two remaining failures are due to some different
problem. They are also racy - I've seen runs with no failures or only
one failure, but never more than two. Also, those runs were conducted
with the loop count in next-fork-exec-other-thread.exp set to 200.
During his testing of this fix and the new test case, Luis Machado
found that this test was taking a long time and asked about ways to
speed it up. I then conducted additional tests in which I gradually
reduced the loop count, timing each one, also noting the number of
failures. With the loop count set to 30, I found that I could still
reliably reproduce the failures that Zhiyong reported (in which, with
the proper settings, core files are created). But, with the loop
count set to 30, the other failures noted above were much less likely
to show up. Anyone wishing to investigate those other failures should
set the loop count back up to 200.
Running the new test on x86-64 and aarch64, both native and
native-gdbserver shows no failures.
Also, I see no regressions when running the entire test suite for
armv7l-unknown-linux-gnueabihf (i.e. the Raspberry Pi w/ 32-bit
kernel+userland) with --target_board=native-gdbserver. Additionally,
using --target_board=native-gdbserver, I also see no regressions for
the entire test suite for x86-64 and aarch64 running Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30387 Co-Authored-By: Zhiyong Yan <zhiyong.yan@windriver.com> Tested-By: Zhiyong Yan <zhiyong.yan@windriver.com> Tested-By: Luis Machado <luis.machado@arm.com>
Alan Modra [Fri, 11 Aug 2023 23:51:31 +0000 (09:21 +0930)]
regen config
This regenerates config files changed by the previous 44 commits.
Note that subject lines in these commits mostly match the gcc git
originating commit.
Arsen Arsenović [Mon, 7 Aug 2023 11:07:48 +0000 (13:07 +0200)]
toplevel: Substitute GDCFLAGS instead of using CFLAGS
r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already
implemented this change, but only on the generated file rather than in
the template it is generated from.
* Makefile.tpl: Substitute @GDCFLAGS@ instead of using
$(CFLAGS).
Roger Sayle [Mon, 7 Aug 2023 11:07:45 +0000 (13:07 +0200)]
PR bootstrap/106472: Add libgo depends on libbacktrace to Makefile.def
This patch fixes PR bootstrap/106472 by adding a missing dependency
to Makefile.def to allow make bootstrap when configured using
"--enable-languages=go" (and not using make with multiple threads).
2022-07-31 Roger Sayle <roger@nextmovesoftware.com>
PR bootstrap/106472
* Makefile.def (dependencies): Make configure-target-libgo depend
upon all-target-libbacktrace.
Fix collection and processing of autoprofile data for target libs
cc1, cc1plus, and lto built during STAGEautoprofile need to be built with
debug info since they are used to build target libs. -gtoggle was
turning off debug info for this stage.
create_gcov should be passed prev-gcc/cc1, prev-gcc/cc1plus, and prev-gcc/lto
instead of stage1-gcc/cc1, stage1-gcc/cc1plus, and stage1-gcc/lto when
processing profile data collected while building target libraries.
Tested on x86_64-pc-linux-gnu.
* Makefile.tpl: Remove -gtoggle for STAGEautoprofile
Collect both user and kernel events for autofdo tests and autoprofiledbootstrap
When we collect just user events for autofdo with lbr we get some events where branch
sources are kernel addresses and branch targets are user addresses. Without kernel MMAP
events create_gcov can't make sense of kernel addresses. Currently create_gcov fails if
it can't map at least 95% of events. We sometimes get below this threshold with just
user events. The change is to collect both user events and kernel events.
Tested on x86_64-pc-linux-gnu.
* Makefile.tpl: Collect both kernel and user events for autofdo
The D front-end is now itself written in D, in order to build GDC, you
will need a working GDC compiler (GCC version 9.1 or later).
GCC changes:
- Add support for bootstrapping the D front-end.
These add the required components in order to have a D front-end written
in D itself. Because the compiler front-end only depends on the core
runtime modules, only libdruntime is built for the bootstrap stages.
D front-end changes:
- Import dmd v2.098.0-beta.1.
Druntime changes:
- Import druntime v2.098.0-beta.1.
Phobos changes:
- Import phobos v2.098.0-beta.1.
The jump from v2.076.1 to v2.098.0 covers nearly 4 years worth of
development on the D programming language and run-time libraries.
* Makefile.def: Add bootstrap to libbacktrace, libphobos, zlib, and
libatomic.
* Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Fix command for GDC.
(STAGE1_CONFIGURE_FLAGS): Add --with-libphobos-druntime-only if
target-libphobos-bootstrap.
(STAGE2_CONFIGURE_FLAGS): Likewise.
Olivier Hainque [Mon, 7 Aug 2023 11:07:33 +0000 (13:07 +0200)]
Generic configury support for shared libs on VxWorks
This change adds the configury bits to activate the build of
shared libs on VxWorks ports configured with --enable-shared,
for libraries variants where this is generally supported (rtp,
code model !large - currently not compatible with -fPIC).
Set lt_cv_deplibs_check_method in libtool.m4, so the build of
libraries know how to establish dependencies. This is useful in
configurations such as aarch64 where proper support of LSE relies
on accurate dependency information between libstdc++ and libgcc_s
to begin with.
* libtool.m4 (*vxworks*): When enable_shared, set dynamic_linker
and friends for rtp !large. Assume the linker has the required
abilities and set lt_cv_deplibs_check_method.
Martin Storsjö [Mon, 7 Aug 2023 11:07:25 +0000 (13:07 +0200)]
mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables
This is similar to what was done in eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to
STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and
BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and
BOOT_CFLAGS).
2021-04-09 Martin Storsjö <martin@martin.st>
config/
* mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags
variables
Iain Sandoe [Mon, 7 Aug 2023 11:07:24 +0000 (13:07 +0200)]
configure: Allow host fragments to react to --enable-host-shared.
This makes the host_shared value available to host makefile
fragments.
It uses this to adjust Darwin's mdynamic-no-pic in the case that
shared host resources are required.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
config/
* mh-darwin: Require a non-shared host configuration to
enable mdynamic-no-pic where that is supported.
Iain Sandoe [Mon, 7 Aug 2023 11:07:23 +0000 (13:07 +0200)]
Darwin, config: Revise host config fragment.
There were two uses for the Darwin host config fragment:
The first is to arrange for targets that support mdynamic-no-pic
to be built with that enabled (since it makes a significant
difference to the compiler performance). We can be more specific
in the application of this, since it only applies to 32b hosts
plus powerpc64-darwin9.
The second was to work around a tool bug where -fno-PIE was not
propagated to the link stage. This second use is redundant,
since the buggy toolchain cannot bootstrap current GCC sources
anyway.
This makes the host fragment more specific and reduces the number
of toolchains for which it is included which reduces clutter in
configure lines.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
config/
* mh-darwin: Make this specific to handling the
mdynamic-no-pic case.
Alexandre Oliva [Mon, 7 Aug 2023 11:07:18 +0000 (13:07 +0200)]
Add TFLAGS to gcc's GCC_FOR_TARGET
When the GCC build runs GCC_FOR_TARGET, e.g. for selftests or for
dumping specs, it doesn't use TFLAGS in non-bootstrap scenarios. This
patch arranges for TFLAGS to be passed from the top level down to gcc
in GCC_FOR_TARGET in this case.
* Makefile.tpl (HOST_EXPORTS): Add TFLAGS to GCC_FOR_TARGET.
(EXTRA_GCC_FLAGS): Likewise.
David Seifert [Mon, 7 Aug 2023 11:07:16 +0000 (13:07 +0200)]
configure: use OBJDUMP determined by libtool [PR95648]
$ac_cv_prog_OBJDUMP contains the --host OBJDUMP that
libtool has inferred. Current config/gcc-plugin.m4 does
not respect the user's choice for OBJDUMP.
config/
* gcc-plugin.m4: Use libtool's $ac_cv_prog_OBJDUMP.
Iain Sandoe [Mon, 7 Aug 2023 11:07:14 +0000 (13:07 +0200)]
configure, Darwin: Ensure overrides to host-pie are passed to gcc configure.
The latest versions of Darwin on the Aarch64 platform mandate PIE executables.
On x86_64 it remains optional, but produces tool warnings after Darwin20, so
we default to PIE executables there too.
All (non-PowerPC) 64b Darwin platforms mandate PIC code and therefore force
host_shared on (we issue a diagnostic if the user tries to configure them
non-shared).
However, this also means we cannot test the host_shared setting independently
of the host_pie setting so that the logic for setting PICFLAG must be amended
for Darwin.
For Darwin versions required to have PIE executables, in the event that the
user tries to configure these as --disable-host-pie, we issue a warning and
override the setting. These versions must also switch host_pie on even if it
is not given in the configure line. To cater for this we pass the current
value of host_pie, as determined by top-level configure, to the GCC configure.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
* Makefile.def: Pass the enable-host-pie value to GCC configure.
* configure.ac: Adjust the logic for shared and PIE host flags to
ensure that PIE is passed for hosts that require it.
Marek Polacek [Mon, 7 Aug 2023 11:07:12 +0000 (13:07 +0200)]
configure: Implement --enable-host-pie
This patch implements the --enable-host-pie configure option which
makes the compiler executables PIE. This can be used to enhance
protection against ROP attacks, and can be viewed as part of a wider
trend to harden binaries.
Co-Authored by: Iain Sandoe <iain@sandoe.co.uk>
* configure.ac (--enable-host-pie): New check. Set PICFLAG after this
check.
intl/
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check. Set PICFLAG after this check.
libdecnumber/
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check. Set PICFLAG after this check.
zlib/
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check. Set PICFLAG after this check.
Iain Sandoe [Mon, 7 Aug 2023 11:07:11 +0000 (13:07 +0200)]
configure: When host-shared, pass --with-pic to in-tree lib configs.
If we are building PIC/PIE host executables, and we are building dependent
libs (e.g. GMP) in-tree those libs need to be configured to generate PIC code.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
* Makefile.def: Pass host_libs_picflag to host dependent library
configures.
* configure.ac (host_libs_picflag): New configure variable set to
'--with-pic' when building 'host_shared'.
Iain Sandoe [Mon, 7 Aug 2023 11:07:10 +0000 (13:07 +0200)]
configure: Do not build the ununsed libffi shared library.
We do not use the shared libffi libraray, nor do we install it.
However, on at least Darwin, the shared version will be picked
up for testing, so it is preferrable not to build it.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
* Makefile.def: Do not build shared libffi.
Iain Sandoe [Mon, 7 Aug 2023 11:07:09 +0000 (13:07 +0200)]
Darwin : Update libtool and dependencies for Darwin20 [PR97865]
The change in major version (and the increment from Darwin19 to 20)
caused libtool tests to fail which resulted in incorrect build settings
for shared libraries.
PR target/97865
* libtool.m4: Update handling of Darwin platform link flags
for Darwin20.
LoongArch always support clz and ctz instructions, so we can always use
__builtin_{clz,ctz} for count_{leading,trailing}_zeros. This improves
the code of libgcc, and also benefits Glibc once we merge longlong.h
there.
Bootstrapped and regtested on loongarch64-linux-gnu.
Lulu Cheng [Mon, 7 Aug 2023 11:07:05 +0000 (13:07 +0200)]
Libvtv: Add loongarch support.
The loongarch64 specification permits page sizes of 4KiB, 16KiB and 64KiB,
but only 16KiB pages are supported for now.
Co-Authored-By: qijingwen <qijingwen@loongson.cn>
include/
* vtv-change-permission.h (defined): Determines whether the macro
__loongarch_lp64 is defined
(VTV_PAGE_SIZE): Set VTV_PAGE_SIZE to 16KiB for loongarch64.
Carl Love [Fri, 11 Aug 2023 21:08:37 +0000 (17:08 -0400)]
gdb.ada/mi_var_access.exp
The NUMCHILD value for the "A_String_Access" test differs for X86 and
PowerPC. The patch substitutes $decimal instead of "1" to match the value
of NUMCHILD.
The test "-var-update A_String_Access" generates different output depending
on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED. If the value is true,
the strings "new_type" and "new_num_children" are printed along with their
values.
The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which
produces the output:
Tom Tromey [Fri, 11 Aug 2023 16:04:49 +0000 (10:04 -0600)]
Test GNAT encodings in arr_acc_idx_w_gap.exp
While working on a GNAT bug, I wanted to also test
arr_acc_idx_w_gap.exp using GNAT encodings. When the GNAT change is
ready, I plan to add a new case here.
Tested on x86-64 Fedora 36. I am checking this in.
Tsukasa OI [Fri, 11 Aug 2023 03:12:52 +0000 (03:12 +0000)]
RISC-V: Reflect actual range of vlen for hashing
Before actual vlen handling, fix the riscv_gdbarch_features hashing
function based on the actual valid range of vlen. In bytes, vlen is 0,
or 4 <= xlen <= 8192.
Tsukasa OI [Fri, 11 Aug 2023 03:09:58 +0000 (03:09 +0000)]
RISC-V: Add reference to Zve32*
Before actual vlen handling, this commit fixes its description to allow vlen
less than 16 (but 4 or greater), to support vector subset extensions for
embedded environment ('Zve32*').
Alan Modra [Wed, 9 Aug 2023 00:28:36 +0000 (09:58 +0930)]
gdb: warn unused result for bfd IO functions
This fixes the compilation warnings introduced by my bfdio.c patch.
The removed bfd_seeks in coff_symfile_read date back to 1994, commit 7f4c859520, prior to which the file used stdio rather than bfd to read
symbols. Since it now uses bfd to read the file there should be no
need to synchronise to bfd's idea of the file position. I also fixed
a potential uninitialised memory access.
Jan Beulich [Fri, 11 Aug 2023 08:05:32 +0000 (10:05 +0200)]
gas: purge md_elf_section_word()
It's not documented anyway, and having it makes no sense anymore with
obj_elf_section_word() now being TC_SPARC-only. In any event the x86
backing function was dead code.
Jan Beulich [Fri, 11 Aug 2023 08:04:49 +0000 (10:04 +0200)]
x86: pack CPU flags in opcode table
The table constantly growing in two dimensions (number of table entries
times number of ISA extension flags) doesn't scale very well. Use a more
compact representation: Only identifiers which need to combine with
other identifiers retain individual flag bits. All others are combined
into an enum, with a new helper added to transform the table entries
into the original i386_cpu_flags layout. This way the table in the final
binary shrinks by almost a third (the generated source code shrinks by
about half), and isn't likely to grow again in that dimension any time
soon.
While moving the 3DNow! fields, drop the stray inner 'a' from their
names.
Alan Modra [Mon, 7 Aug 2023 11:29:08 +0000 (20:59 +0930)]
warn unused result for bfd IO functions
This patch fixes all the warnings I found in bfd, binutils and ld,
plus some bitrotted COFF_GO32 code that tried to allocate -168ul
bytes. When the malloc fail was reported these testsuite fails
resulted:
i386-go32 +FAIL: go32 stub
i386-go32 +ERROR: tcl error sourcing /home/alan/src/binutils-gdb/ld/testsuite/ld-i386/i386.exp.
i386-go32 +ERROR: couldn't open "tmpdir/go32stub": no such file or directory
i386-go32 +FAIL: ld-scripts/sane1
i386-go32 +FAIL: ld-scripts/assign-loc
i386-go32 +FAIL: ld-scripts/pr18963
This does result in some warnings in gdb which are fixed in a followup
patch.
bfd/
* bfdio.c (bfd_read, bfd_write): Add ATTRIBUTE_WARN_UNUSED_RESULT.
(bfd_tell, bfd_stat, bfd_seek, bfd_mmap): Likewise.
* bfd-in2.h: Regenerate.
* coff-rs6000.c (xcoff_write_armap_big) Don't ignore bfd_write
return value.
(xcoff_generate_rtinit): Likewise. Also free data_buffer and
string_table before returning.
* coff64-rs6000.c (xcoff64_generate_rtinit): Likewise.
* coff-stgo32.c (go32exe_check_format): Don't ignore bfd_seek
return value.
* coffcode.h (coff_apply_checksum): Don't ignore bfd_write return.
(coff_write_object_contents <COFF_GO32>): Likewise, and bfd_malloc.
Fix bitrotted code to look for first section with non-zero filepos.
* elf64-ia64-vms.c (elf64_vms_write_shdrs_and_ehdr): Don't ignore
bfd_seek or bfd_write return values.
* pef.c (bfd_pef_scan_section): Likewise.
(bfd_pef_read_header, bfd_pef_xlib_read_header): Likewise.
* vms-misc.c (_bfd_vms_output_end): Likewise. Return status.
* vms.h (_bfd_vms_output_end): Update prototype.
* vms-alpha.c: Pass _bfd_vms_output_end status up call chains.
* wasm-module.c (wasm_compute_custom_section_file_position): Don't
ignore bfd_seek or bfd_write return values.
(wasm_compute_section_file_positions): Likewise.
* xsym.c (bfd_sym_scan): Don't ignore bfd_seek return value.
(bfd_sym_read_name_table): Likewise.
binutils/
* ar.c (print_contents, extract_file): Don't ignore bfd_seek
return value.
ld/
* pdb.c (create_section_contrib_substream): Don't ignore bfd_seek
return value.
(create_section_header_stream): Likewise.
* pe-dll.c (pe_get16, pe_get32): Add fail param to return results
from bfd_seek and bfd_read.
(pe_implied_import_dll): Handle these fails, and other bfd_seek
and bfd_read return values.
Tsukasa OI [Sun, 6 Aug 2023 01:37:05 +0000 (01:37 +0000)]
RISC-V: Fix opcode entries of "vmsge{,u}.vx"
Their check_func should be "match_never", not "match_opcode". The reasons
this error did not cause any disassembler errors are:
1. The problem will not reproduce if "no-aliases" is specified
(because macro instructions are handled as aliases).
2. If not, all affected compressed instructions or their aliases
precede before "vmsge{,u}.vx" macro instructions.
However, it'll easily break if we reorder opcode entries. This commit
fixes this issue before the *accident* occurs.
opcodes/ChangeLog:
* riscv-opc.c (riscv_opcodes): Make sure that we never match to
vmsge{,u}.vx instructions unless specified in the assembler.
Tsukasa OI [Thu, 3 Aug 2023 01:01:23 +0000 (01:01 +0000)]
RISC-V: Remove support for non-existing 'Zve32d'
Since this "extension" does not exist (on the other hand, 'Zve64d' exists)
and it's not useful if we keep it (as other code portions just ignore
"zve32d"), this commit just removes it.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_supported_std_z_ext): Remove 'Zve32d'
extension from the list.
Notice that 0x2a is the parent of 0x25, and that this is why the qualified
name of 0x25 is "foo::foo", which is incorrect, it's supposed to be "foo".
The parent is set here in cooked_indexer::make_index:
...
for (const auto &entry : m_deferred_entries)
{
void *obj = m_die_range_map.find (entry.spec_offset);
cooked_index_entry *parent = static_cast<cooked_index_entry *> (obj);
m_index_storage->add (entry.die_offset, entry.tag, entry.flags,
entry.name, parent, m_per_cu);
}
...
and AFAICT, we store in m_die_range_map the parent of the respective
spec_offset DIE (though that's not clear from the comment describing it).
So, the root cause of this is that when we lookup the parent for DIE 0x25, we get
m_die_range_map.find (0x2a) == 0x2a.
This is an off-by-one error, fixed in cooked_indexer::recurse by:
...
- CORE_ADDR start = form_addr (parent_entry->die_offset,
+ CORE_ADDR start = form_addr (parent_entry->die_offset + 1,
...
which gives us:
...
[12] ((cooked_index_entry *) 0x41e21f0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0)
By following the parent links in the text, we can conclude that the qualified
name of DIE 0x25 is foo::foo (which is incorrect, that's PR symtab/30739).
But it's not evident, and also hard to verify in a test-case.
Add dumping of the qualified name, such that we have:
...
[25] ((cooked_index_entry *) 0x333b5d0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
Carl Love [Thu, 3 Aug 2023 17:55:51 +0000 (13:55 -0400)]
Fix gdb.ada/O2_float_param.exp for PowerPC
The frame command on Power pc prints the address in hex between the
#0 and in calle.increment. For example
(gdb) frame
#0 0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19
19 procedure Increment (Val : in out Float; Msg: String) is
The printing of the address for the frame is done by function
print_frame in gdb/stack.c. If SAL.IS_stmt is false for the frame,
function frame_show_address returns true and print_frame prints the
address. Currently, SAL.IS is false on PowerPC and true on X86-64.
Update the set re string to accept the hex address if it exits.
This behavior is a bit unfortunate -- I would think that it would be
better to arrange for such notification if something on the gdb side
is interested.
Meanwhile, this patch fixes py-thread-exited.exp to work around this
problem.
Tom de Vries [Thu, 10 Aug 2023 13:46:30 +0000 (15:46 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp with cc-with-gnu-debuglink
When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-gnu-debuglink, I run into:
...
(gdb) PASS: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo
maint print symbols -objfile enqueued-cu-base-addr^M
(gdb) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
...
The problem is that the CU we're trying to print is in objfile
enqueued-cu-base-addr.debug instead of enqueued-cu-base-addr.
Fix this by replacing "-objfile enqueued-cu-base-addr" with "-source cu2".
Tom de Vries [Thu, 10 Aug 2023 13:46:30 +0000 (15:46 +0200)]
[gdb/testsuite] Improve failure mode in gdb.dwarf2/enqueued-cu-base-addr.exp
I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-debug-names, and ran into:
...
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error)
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
...
The first FAIL is a known issue, PR symtab/29572.
The following FAIL is a consequence of the first FAIL, so require for the
second test that the first test passes.
Tested on x86_64-linux, with target boards unix and cc-with-debug-names.
Tom de Vries [Thu, 10 Aug 2023 13:46:30 +0000 (15:46 +0200)]
[gdb/symtab] Fix assertion in write_debug_names
When running test-case gdb.dwarf2/pr13961.exp with target-board
cc-with-debug-names, I run into:
...
Running gdb.dwarf2/pr13961.exp ...
gdb compile failed, gdb/dwarf2/index-write.c:1305: internal-error: \
write_debug_names: Assertion `counter == per_bfd->all_units.size ()' failed.
...
This is a regression since commit 542a33e348a ("Only use the per-BFD object to
write a DWARF index"), which did:
...
- gdb_assert (counter == per_objfile->per_bfd->all_comp_units.size ());
+ gdb_assert (counter == per_bfd->all_units.size ());
...
Fix this by reverting to using all_comp_units:
...
gdb_assert (counter == per_bfd->all_comp_units.size ());
...
Tested on x86_64-linux, using target boards unix and cc-with-debug-names.
David Faust [Wed, 9 Aug 2023 18:44:38 +0000 (11:44 -0700)]
bpf: use w regs in 32-bit non-fetch atomic pseudo-c
The 32-bit non-fetching atomic instructions treat the source register as
32-bits, which means in the pseudo-c syntax the "w" registers should be
used rather than the "r" registers.
opcodes/
* bpf-opc-c (bpf_opcodes): Use %sw for AAD32, AOR32, AAND32
and AXOR32 pseudo-c dialect asm templates.
gas/
* testsuite/gas/bpf/atomic-be-pseudoc.d: Use "w" for source reg
in non-fetching 32-bit atomic instructions.
* testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
* testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
This patch introduces new debugging information that prints
breakpoint location insertion and removal flow.
The debug output looks like:
~~~
(gdb) set debug breakpoint on
(gdb) disassemble main
Dump of assembler code for function main:
0x0000555555555129 <+0>: endbr64
0x000055555555512d <+4>: push %rbp
0x000055555555512e <+5>: mov %rsp,%rbp
=> 0x0000555555555131 <+8>: mov $0x0,%eax
0x0000555555555136 <+13>: pop %rbp
0x0000555555555137 <+14>: ret
End of assembler dump.
(gdb) break *0x0000555555555137
Breakpoint 2 at 0x555555555137: file main.c, line 4.
[breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
(gdb) c
Continuing.
[breakpoint] update_global_location_list: insert_mode = UGLL_INSERT
[breakpoint] insert_bp_location: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4
[breakpoint] insert_bp_location: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5
[breakpoint] insert_bp_location: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e
[breakpoint] insert_bp_location: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4
[breakpoint] remove_breakpoint_1: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 due to regular remove
[breakpoint] remove_breakpoint_1: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 due to regular remove
[breakpoint] remove_breakpoint_1: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e due to regular remove
[breakpoint] remove_breakpoint_1: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 due to regular remove
Breakpoint 2, 0x0000555555555137 in main () at main.c:4
4 }
~~~
Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
Alan Modra [Mon, 7 Aug 2023 05:10:35 +0000 (14:40 +0930)]
Rename bfd_bread and bfd_bwrite
These were renamed from bfd_read and bfd_write back in 2001 when they
lost an unnecessary parameter. Rename them back, and get rid of a few
casts that are only needed without prototyped functions (K&R C).
Alan Modra [Sun, 6 Aug 2023 22:58:55 +0000 (08:28 +0930)]
PR30724, cygwin ld performance regression since 014a602b86
According to the reporter of this bug the newlib fseek implementation
is likely slowed down by locking and fflush, only attempting to
optimise seeks when the file is opened read-only. Thus when writing
the output we get a dramatic slowdown due to commit 014a602b86.
PR 30724
* bfd.c (enum bfd_last_io): New.
(struct bfd): Add last_io field.
* bfd-in2.h: Regenerate.
* bfd-io.c (bfd_bread, bfd_bwrite): Force seek if last_io is
opposite direction.
(bfd_seek): Reinstate optimisation for seek to same position.
Rainer Orth [Tue, 8 Aug 2023 08:13:58 +0000 (10:13 +0200)]
Guard against killing unrelated processes in amd64-disp-step.exp
When testing current gdb trunk on Solaris/amd64, the whole session was
reliably terminated by make check. I could trace this to the following
entry in gdb.arch/amd64-disp-step/gdb.log:
FAIL: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=on: get
inferior pid
Executing on target: kill -ALRM -1 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -ALRM -1
If $inferior_pid doesn't refer to a single process for some reason, this
kill would terminate either a process group or the whole session.
This patch avoids this by ensuring that the pid arg is positive.
Tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Tue, 8 Aug 2023 08:08:04 +0000 (10:08 +0200)]
[gdb/build] Fix build breaker with -std=c++11
When building with -std=c++11 I run into:
...
gdb/dwarf2/cooked-index.c: In member function \
‘void cooked_index::start_writing_index(dwarf2_per_bfd*)’:
gdb/dwarf2/cooked-index.c:469:10: error: lambda capture initializers only \
available with -std=c++14 or -std=gnu++14 [-Werror]
ctx = std::move (ctx)] ()
^~~
...
Fix this by capturing a copy instead when using -std=c++11:
...
= gdb::thread_pool::g_thread_pool->post_task ([this, per_bfd, ctx] ()
...
Tested by building with and without -stdc=++11 on x86_64-linux.
Reported-By: Tom Tromey <tom@tromey.com> Reviewed-by: John Baldwin <jhb@FreeBSD.org>