Mike Frysinger [Wed, 10 Jan 2024 01:55:43 +0000 (20:55 -0500)]
sim: ppc: rework defines.h to handle HAVE symbols defined to 0
The HAVE_DECL_xxx defines are always defined to 0 or 1. The current
defines.h logic assumes every HAVE_xxx symbol is only defined iff it's
defined to 1 which causes this to break. Tweak the sed logic to only
match defines of 1.
Mike Frysinger [Wed, 10 Jan 2024 01:20:38 +0000 (20:20 -0500)]
gdb: move libiberty.m4 to gdbsupport
This is used by gdb, gdbsupport, and gdbserver. We want to use it
in the sim tree too. Move it to gdbsupport which is meant as the
common sharing space for these projects.
This directory contains example programs for the user to experiment with.
Initially there is one application written in C. The plan is to include
more examples, also in other langauges, over time.
In addition to the sources and a make file, a sample script how to make
a profile is included. There is also a README.md file.
gprofng/ChangeLog
2024-01-08 Ruud van der Pas <ruud.vanderpas@oracle.com>
* examples: Top level directory.
* examples/mxv-pthreads: Example program written in C.
gprofng: 31123 improvements to hardware event implementation
Our hardware counter profiling is based on perf_event_open().
Our HWC tables are absent for new machines.
I have added HWC tables for the following events: PERF_TYPE_HARDWARE,
PERF_TYPE_SOFTWARE, PERF_TYPE_HW_CACHE. Other events require additional fixes.
Did a little cleaning: marked the symbols as static, used Stringbuilder,
created a function to read /proc/cpuinfo.
gprofng/ChangeLog
2024-01-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/31123
* common/core_pcbe.c: Mark the symbols as static. Add events_generic[].
* common/hwc_cpus.h: Declare a new function read_cpuinfo.
* common/hwcdrv.c: Add a new parameter in init_perf_event().
* common/hwcentry.h: Add use_perf_event_type in Hwcentry.
* common/hwcfuncs.c (process_data_descriptor): Read use_perf_event_type,
type, config.
* common/hwctable.c: Add a new HWC table generic_list[].
* common/opteron_pcbe.c (opt_pcbe_init): Accept AMD machines.
* src/collctrl.cc: Use StringBuilder in Coll_Ctrl::build_data_desc().
Add a new function read_cpuinfo.
In AIX we were missing some hooks needed to catch a fork () event
in rs6000-aix-nat.c. Due to their absence we were returning 1 while we
insert the breakpoint/catchpoint location. This patch is a fix to the same.
When I enable cgen rebuilding in the binutils-gdb tree, the default is
to run cgen using 'guile'. However, on my host, guile is guile 2.2,
which doesn't work for me -- I have to use guile3.0.
This patch arranges to pass "GUILE" down to subdirectories, so I can
use 'make GUILE=guile3.0'.
Makefile.tpl: Avoid race condition in generating site.exp from the top level
A command like "make -j 2 check-gcc-c check-gcc-c++" run in the top level of
a fresh build directory does not work reliably. That will spawn two
independent make processes inside the "gcc" directory, and each of those
will attempt to create site.exp if it doesn't exist and will interfere with
each other, producing often a corrupted or empty site.exp. Resolve that by
making these targets depend on a new phony target which makes sure site.exp
is created first before starting the recursive makes.
Config,Darwin: Allow for configuring Darwin to use embedded runpath.
Recent Darwin versions place contraints on the use of run paths
specified in environment variables. This breaks some assumptions
in the GCC build.
This change allows the user to configure a Darwin build to use
'@rpath/libraryname.dylib' in library names and then to add an
embedded runpath to executables (and libraries with dependents).
The embedded runpath is added by default unless the user adds
'-nodefaultrpaths' to the link line.
For an installed compiler, it means that any executable built with
that compiler will reference the runtimes installed with the
compiler (equivalent to hard-coding the library path into the name
of the library).
During build-time configurations any "-B" entries will be added to
the runpath thus the newly-built libraries will be found by exes.
Since the install name is set in libtool, that decision needs to be
available here (but might also cause dependent ones in Makefiles,
so we need to export a conditional).
This facility is not available for Darwin 8 or earlier, however the
existing environment variable runpath does work there.
We default this on for systems where the external DYLD_LIBRARY_PATH
does not work and off for Darwin 8 or earlier. For systems that can
use either method, if the value is unset, we use the default (which
is currently DYLD_LIBRARY_PATH).
Makefile.tpl: disable -Werror for feedback stage [PR111663]
Without the change profiled bootstrap fails for various warnings on
master branch as:
$ ../gcc/configure
$ make profiledbootstrap
...
gcc/genmodes.cc: In function ‘int main(int, char**)’:
gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]
...
gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’:
gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
The change removes -Werror just like autofeedback does today.
Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951]
..., where we need to use it (separate commits) for build-tree testing, similar
to 'gcc/Makefile.in:site.exp':
# TEST_ALWAYS_FLAGS are flags that should be passed to every compilation.
# They are passed first to allow individual tests to override them.
@echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp
Saurabh Jha [Wed, 10 Jan 2024 11:10:07 +0000 (11:10 +0000)]
gas: aarch64: Add system registers for Debug and PMU extensions
This patch adds support for the new AArch64 system registers that are part of the following extensions:
* FEAT_DEBUGv8p9
* FEAT_PMUv3p9
* FEAT_PMUv3_SS
* FEAT_PMUv3_ICNTR
* FEAT_SEBEP
Tom de Vries [Wed, 10 Jan 2024 10:27:34 +0000 (11:27 +0100)]
[gdb] Fix assertion failure for checkpoint delete 0
When doing "checkpoint delete 0" we run into an assertion failure:
...
+delete checkpoint 0
inferior.c:406: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
...
Fix this by handling the "pptid == null_ptid" case in
delete_checkpoint_command.
Tested on x86_64-linux.
Approved-By: Kevin Buettner <kevinb@redhat.com>
PR gdb/31209
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31209
Tom de Vries [Wed, 10 Jan 2024 10:27:34 +0000 (11:27 +0100)]
[gdb] Fix info checkpoints
Consider test-case gdb.base/checkpoint.exp. At some point, it issues an info
checkpoints command:
...
(gdb) info checkpoints^M
* 0 process 30570 (main process) at 0x0^M
1 process 30573 at 0x4008bb, file checkpoint.c, line 49^M
2 process 30574 at 0x4008bb, file checkpoint.c, line 49^M
3 process 30575 at 0x4008bb, file checkpoint.c, line 49^M
4 process 30576 at 0x4008bb, file checkpoint.c, line 49^M
5 process 30577 at 0x4008bb, file checkpoint.c, line 49^M
6 process 30578 at 0x4008bb, file checkpoint.c, line 49^M
7 process 30579 at 0x4008bb, file checkpoint.c, line 49^M
8 process 30580 at 0x4008bb, file checkpoint.c, line 49^M
9 process 30582 at 0x4008bb, file checkpoint.c, line 49^M
10 process 30583 at 0x4008bb, file checkpoint.c, line 49^M
...
According to the docs, each of these (0-10) is a checkpoint.
But the pc address (as well as the file name and line number) is missing for
checkpoint 0.
Fix this by sampling the pc value for the current process in
info_checkpoints_command, such that we have instead:
...
* 0 process 30570 (main process) at 0x4008bb, file checkpoint.c, line 49^M
...
Tested on x86_64-linux.
Approved-By: Kevin Buettner <kevinb@redhat.com>
PR gdb/31211
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31211
Tom de Vries [Wed, 10 Jan 2024 09:06:35 +0000 (10:06 +0100)]
gdb/symtab: Eliminate deferred_entry
Currently cooked_index entry creation is either:
- done immediately if the parent_entry is known, or
- deferred if the parent_entry is not yet known, and done later while
resolving the deferred entries.
Instead, create all cooked_index entries immediately, and keep track of which
entries have a parent_entry that needs resolving later using the new
IS_PARENT_DEFERRED flag.
Tom Tromey [Tue, 9 Jan 2024 19:49:16 +0000 (12:49 -0700)]
Fix ASAN failure in DWO code
Simon pointed out that my recent change to the DWO code caused a
failure in ASAN testing.
The bug here was I updated the code to use a different search type in
the hash table; but then did not change the search code to use
htab_find_slot_with_hash.
Note that this bug would not be possible with my type-safe hash table
series, hint, hint.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Tue, 9 Jan 2024 20:21:12 +0000 (13:21 -0700)]
Fix thread-less build
A user pointed out that the recent background DWARF reader series
broke the build when --disable-threading is in use. This patch fixes
the problem. I am checking it in.
Tom Tromey [Thu, 28 Dec 2023 21:08:39 +0000 (14:08 -0700)]
Pass GUILE down to subdirectories
When I enable cgen rebuilding in the binutils-gdb tree, the default is
to run cgen using 'guile'. However, on my host, guile is guile 2.2,
which doesn't work for me -- I have to use guile3.0.
This patch arranges to pass "GUILE" down to subdirectories, so I can
use 'make GUILE=guile3.0'.
H.J. Lu [Fri, 19 May 2023 22:11:51 +0000 (15:11 -0700)]
elf: Add elf_backend_add_glibc_version_dependency
When -z mark-plt is used to add DT_X86_64_PLT, DT_X86_64_PLTSZ and
DT_X86_64_PLTENT, the r_addend field of the R_X86_64_JUMP_SLOT relocation
stores the offset of the indirect branch instruction. However, glibc
versions which don't have this commit in glibc 2.36:
x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT
According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT
and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to 0, we
can ignore their r_addends.
Reviewed-by: Fangrui Song <maskray@google.com>
won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation.
Although this commit has been backported to glibc 2.33/2.34/2.35 release
branches, it is safer to require glibc 2.36 for such binaries.
Extend the glibc version dependency of GLIBC_ABI_DT_RELR for DT_RELR to
also add GLIBC_2.36 version dependency for -z mark-plt on the shared C
library if it provides a GLIBC_2.XX symbol version.
* elflink.c (elf_find_verdep_info): Moved to ...
* elf-bfd.h (elf_find_verdep_info): Here.
(elf_backend_data): Add elf_backend_add_glibc_version_dependency.
(_bfd_elf_link_add_glibc_version_dependency): New function.
(_bfd_elf_link_add_dt_relr_dependency): Likewise.
* elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency):
Likewise.
(elf_backend_add_glibc_version_dependency): New.
* elflink.c (elf_link_add_dt_relr_dependency): Renamed to ...
(elf_link_add_glibc_verneed): This. Modified to support other
glibc dependencies.
(_bfd_elf_link_add_glibc_version_dependency): Likewise.
(_bfd_elf_link_add_dt_relr_dependency): Likewise.
(bfd_elf_size_dynamic_sections): Call
elf_backend_add_glibc_version_dependency instead of
elf_link_add_dt_relr_dependency.
* elfxx-target.h (elf_backend_add_glibc_version_dependency): New.
(elfNN_bed): Add elf_backend_add_glibc_version_dependency.
ld/
* testsuite/ld-x86-64/mark-plt-1a.rd: New file.
* testsuite/ld-x86-64/mark-plt-1b.rd: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt test for
GLIBC_2.36 dependency.
Tom Tromey [Thu, 14 Dec 2023 20:13:59 +0000 (13:13 -0700)]
Use unrelocated_addr in dwarf2_base_index_functions::find_per_cu
dwarf2_base_index_functions::find_per_cu is documented as using an
unrelocated address. This patch changes the interface to use the
unrelocated_addr type, just to be a bit more type-safe.
Jan Beulich [Tue, 9 Jan 2024 12:50:27 +0000 (13:50 +0100)]
x86: add missing APX logic to cpu_flags_match()
As already indicated during review, we can't get away without certain
adjustments here: Without these, respective {evex}-prefixed insns are
assembled to APX encodings even when APX_F is turned off.
While there also extend the respective comment in the opcode table, to
explain why this construct is used.
Jan Beulich [Tue, 9 Jan 2024 12:49:48 +0000 (13:49 +0100)]
x86: FMA insns aren't eligible to VEX2 encoding
PR gas/31178
In da0784f961d8 ("x86: fold FMA VEX and EVEX templates") I overlooked
that C aliases StaticRounding, and hence build_vex_prefix() now needs to
be aware of that aliasing. Disambiguation is easy, as StaticRounding is
only ever used together with SAE (hence why the overlaying works in the
first place).
Jan Beulich [Tue, 9 Jan 2024 12:49:13 +0000 (13:49 +0100)]
PPC64/ELF: adjust comment wrt ABI versions
While having been moved a couple of times since its introduction in f6c7c3e8b742 ("Referencing a function's address on PowerPC64 ELFv2"),
the wording has always remained the same. In particular ELFv1 and ELFv2
have always been the wrong way round.
Tobias reported on IRC that the linker fails to build with GCC 4.8.5.
In configure I've tried to use everything actually used in the sha1.c
x86 hw implementation, but unfortunately I forgot about implicit function
declarations. GCC before 7 did have <cpuid.h> header and bit_SHA define
and __get_cpuid function defined inline, but it didn't define
__get_cpuid_count, which compiled fine (and the configure test is
intentionally compile time only) due to implicit function declaration,
but then failed to link when linking the linker, because
__get_cpuid_count wasn't defined anywhere.
The following patch fixes that by using what autoconf uses in AC_CHECK_DECL
to make sure the functions are declared.
The recent warning patches broke Solaris bootstrap:
/vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} [-Wincompatible-pointer-types]
326 | pex_unix_wait,
| ^~~~~~~~~~~~~
/vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait')
While pex_funcs.wait expects a function returning pid_t, pex_unix_wait
currently returns int. However, on Solaris pid_t is long for 32-bit,
but int for 64-bit.
This patches fixes this by having pex_unix_wait return pid_t as
expected, and like every other variant already does.
Bootstrapped without regressions on i386-pc-solaris2.11,
sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and
x86_64-apple-darwin23.1.0.
Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and
https://github.com/itanium-cxx-abi/cxx-abi/pull/166
We need to mangle constraints to be able to distinguish between function
templates that only differ in constraints. From the latter link, we want to
use the template parameter mangling previously specified for lambdas to also
make explicit the form of a template parameter where the argument is not a
"natural" fit for it, such as when the parameter is constrained or deduced.
I'm concerned about how the latter link changes the mangling for some C++98
and C++11 patterns, so I've limited template_parm_natural_p to avoid two
cases found by running the testsuite with -Wabi forced on:
template <class T, T V> T f() { return V; }
int main() { return f<int,42>(); }
template <int i> int max() { return i; }
template <int i, int j, int... rest> int max()
{
int sub = max<j, rest...>();
return i > sub ? i : sub;
}
int main() { return max<1,2,3>(); }
A third C++11 pattern is changed by this patch:
template <template <typename...> class TT, typename... Ts> TT<Ts...> f();
template <typename> struct A { };
int main() { f<A,int>(); }
I aim to resolve these with the ABI committee before GCC 14.1.
We also need to resolve https://github.com/itanium-cxx-abi/cxx-abi/issues/38
(mangling references to dependent template-ids where the name is fully
resolved) as references to concepts in std:: will consistently run into this
area. This is why mangle-concepts1.C only refers to concepts in the global
namespace so far.
The library changes are to avoid trying to mangle builtins, which fails.
Demangler support and test coverage is not complete yet.
Nick has approved this patch (+ small ld change to use it for --build-id=),
so I'm commiting it to GCC as master as well.
If anyone from ARM would be willing to implement it similarly with
vsha1{cq,mq,pq,h,su0q,su1q}_u32 intrinsics, it could be a useful linker
speedup on those hosts as well, the intent in sha1.c was that
sha1_hw_process_bytes, sha1_hw_process_block functions
would be defined whenever
defined (HAVE_X86_SHA1_HW_SUPPORT) || defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT)
but the body of sha1_hw_process_block and sha1_choose_process_bytes
would then have #elif defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) for
the other arch support, similarly for any target attributes on
sha1_hw_process_block if needed.
Regenerate libiberty/aclocal.m4 with aclocal 1.15.1
There is a new buildbot check that all autotool files are generated
with the correct versions (automake 1.15.1 and autoconf 2.69).
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
Correct one file that was generated with the wrong version.
[PATCH v3] libiberty: Use posix_spawn in pex-unix when available.
Hi,
This patch implements pex_unix_exec_child using posix_spawn when
available.
This should especially benefit recent macOS (where vfork just calls
fork), but should have equivalent or faster performance on all
platforms.
In addition, the implementation is substantially simpler than the
vfork+exec code path.
Tested on x86_64-linux.
v2: Fix error handling (previously the function would be run twice in
case of error), and don't use a macro that changes control flow.
v3: Match file style for error-handling blocks, don't close
in/out/errdes on error, and check close() for errors.
r13-4035 avoided a problem with overloading of constrained hidden friends by
checking satisfaction, but checking satisfaction early is inconsistent with
the usual late checking and can lead to hard errors, so let's not do that
after all.
We were wrongly treating the different instantiations of the same friend
template as the same function because maybe_substitute_reqs_for was failing
to actually substitute in the case of a non-template friend. But we don't
actually need to do the substitution anyway, because [temp.friend] says that
such a friend can't be the same as any other declaration.
After fixing that, instead of a redefinition error we got an ambiguous
overload error, fixed by allowing constrained hidden friends to coexist
until overload resolution, at which point they probably won't be in the same
ADL overload set anyway.
And we avoid mangling collisions by following the proposed mangling for
these friends as a member function with an extra 'F' before the name. I
demangle this by just adding [friend] to the name of the function because
it's not feasible to reconstruct the actual scope of the function since the
mangling ABI doesn't distinguish between class and namespace scopes.
This patch adds support for FEAT_THE doubleword and quadword instructions.
doubleword insturctions are enabled by "+the" flag whereas quadword
instructions are enabled on passing both "+the and +d128" flags.
Support for following sets of instructions is added in this patch.
Read check write compare and swap doubleword:
(rcwcas, rcwcasa, rcwcasal, rcwcasl)
Read check write compare and swap quadword:
(rcwcasp,rcwcaspa, rcwcaspal, rcwcaspl)
Read check write software compare and swap doubleword:
(rcwscas, rcwscasa, rcwscasal, rcwscasl)
Read check write software compare and swap quadword:
(rcwscasp, rcwscaspa, rcwscaspal, rcwscaspl)
Read check write atomic bit clear on doubleword:
(rcwclr, rcwclra, rcwclral, rcwclrl)
Read check write atomic bit clear on quadword:
(rcwclrp, rcwclrpa, rcwclrpal, rcwclrpl)
Read check write software atomic bit clear on doubleword:
(rcwsclr, rcwsclra, rcwsclral, rcwsclrl)
Read check write software atomic bit clear on quadword:
(rcwsclrp,rcwsclrpa, rcwsclrpal,rcwsclrpl)
Read check write atomic bit set on doubleword:
(rcwset,rcwseta, rcwsetal,rcwsetl)
Read check write atomic bit set on quadword:
(rcwsetp,rcwsetpa,rcwsetpal,rcwsetpl)
Read check write software atomic bit set on doubleword:
(rcwsset,rcwsseta,rcwssetal,rcwssetl)
Read check write software atomic bit set on quadword:
(rcwssetp,rcwssetpa,rcwssetpal,rcwssetpl)
Read check write swap doubleword:
(rcwswp,rcwswpa,rcwswpal,rcwswpl)
Read check write swap quadword:
(rcwswpp,rcwswppa, rcwswppal,rcwswppl)
Read check write software swap doubleword:
(rcwsswp,rcwsswpa,rcwsswpal,rcwsswpl)
Read check write software swap quadword:
(rcwsswpp,rcwsswppa,rcwsswppal,rcwsswppl)
arch64: Add optional operand register pair support tests
Add tests to cover the full range of behaviors observed around
optional register operands for the `tlbip' and `sysp' instructions,
namely:
* Not all `tlbip' operations take GPR operands. When this is the
case, we should check that neither optional operand was supplied.
* When a `tlbip' operation is labeled with the `F_HASXT' flag, xzr
is not a valid optional operand. In such case, at least the fist
optional register needs to be specified with a non-xzr value.
* The first operand for both insns should be either xzr or an
even-numbered register (n % 2 == 0). In the former scenario, the
second operand should default to xzr too, while in the latter, it
should default to n + 1.
aarch64: Add support for 128-bit system register mrrs and msrr insns
With the addition of 128-bit system registers to the Arm architecture
starting with Armv9.4-a, a mechanism for manipulating their contents
is introduced with the `msrr' and `mrrs' instruction pair.
These move values from one such 128-bit system register into a pair of
contiguous general-purpose registers and vice-versa, as for example:
msrr ttlb0_el1, x0, x1
mrrs x0, x1, ttlb0_el1
This patch adds the necessary support for these instructions, adding
checks for system-register width by defining a new operand type in the
form of `AARCH64_OPND_SYSREG128' and the `aarch64_sys_reg_128bit_p'
predicate, responsible for checking whether the requested system
register table entry is marked as implemented in the 128-bit mode via
the F_REG_128 flag.
The 2020 Architecture Extensions to the Arm A-profile architecture
added FEAT_XS, the XS attribute feature, giving cores the ability to
identify devices which can be subject to long response delays. TLB
invalidate (TLBI) operations and barriers can also be annotated with
this attribute[1].
With the introduction of the 128-bit translation tables with the
Armv8.9-a/Armv9.4-a Translation Hardening Extension, a series of new
TLB invalidate operations are introduced which make use of this
extension. These are added to aarch64_sys_regs_tlbi[] for use
with the `tlbip' insn.
The addition of 128-bit page table descriptors and, with it, the
addition of 128-bit system registers for these means that special
"invalidate translation table entry" instructions are needed to cope
with the new 128-bit model. This is introduced with the `tlbpi'
instruction, implemented here.
aarch64: Create QL_SRC_X2 and QL_DEST_X2 qualifier macros
Some 128-bit system operations (mrrs, msrr, tlbip, and sysp) take two
qualified operands and one of unqualified type (e.g. system register
name, tlbip operation). This creates the need for adequate qualifiers
to handle this.
This patch therefore introduces the `QL_SRC_X2' and `QL_DST_X2' qualifier
specifiers, which expand to `QLF3(NIL,X,X)' and `QLF3(X,X,NIL)',
respectively.
aarch64: Apply narrowing of allowed immediate values for SYSP
While CRn and CRm fields in the SYSP instruction are 4-bit wide and
are thus able to accommodate values in the range 0-15, the
specifications for the SYSP instructions limit their ranges to 8-9 for
CRm and 0-7 in the case of CRn.
This led to the need to signal in some way to the operand parser that
a given operand is under special restrictions regarding its use. This
is done via the new `F_OPD_NARROW' flag, indicating a narrowing in the
range of operand values for fields in the instruction tagged with the
flag.
The flag is then used in `parse_operands' when the instruction is
assembled, but needs not be taken into consideration during
disassembly.
aarch64: Add support for the SYSP 128-bit system instruction
Mirroring the use of the `sys' - System Instruction assembly
instruction, this implements its 128-bit counterpart, `sysp'.
This optionally takes two contiguous general-purpose registers
starting at an even number or, when these are omitted, by default
sets both of these to xzr.
Two of the instructions added by the `+d128' architectural extension
add the flexibility to have two optional operands. Prior to the
addition of the `tlbip' and `sysp' instructions, no mnemonic allowed
more than one such optional operand.
With `tlbip' as an example, some TLBIP instruction names do not allow
for any optional operands, while others allow for both to be optional.
In the latter case, it is possible that either the second operand
alone is omitted or both operands are omitted.
Therefore, a considerable degree of flexibility needed to be added to
the way operands were parsed. It was, however, possible to achieve
this with relatively few changes to existing code.
it is noteworthy that opcode flags specifying the optional operand
number are non-orthogonal. For example, we have:
it is impossible to mark both operands 1 and 2 as optional for an
instruction and it is assumed that a maximum of 1 operand can ever be
optional. This is not overly-problematic given that, for optional
pairs, the second optional operand is always found immediately after
the first. Thus, it suffices for us to flag that there is a second
optional operand. With this fact, we can infer its position in the
mnemonic from the position of the first (e.g. if the second operand in
the mnemonic is optional, we know the third is too). We therefore
define the `F_OPD_PAIR_OPT' flag and calculate its position in the
mnemonic from the value encoded by the `F_OPD<n>_OPT' flag.
Another observation is that there is a tight coupling between default
values assigned to the two registers when one (or both) are omitted
from the mnemonic. Namely, if Xt1 has a value of 0x1f (the zero
register is specified), Xt2 defaults to the same value, otherwise Xt2
will be assigned Xt + 1. This meant that where you have default value
validation, in checking the second optional operand's value, it is
also necessary to look at the value assigned to the
previously-processed operand value before deciding its validity. Thus
`process_omitted_operand' needs not only access to its `operand'
argument, but also to the global `inst' struct.
aarch64: Add support for xzr register in register pair operands
Analysis of the allowed operand values for `sysp' and `tlbip' reveals
a significant departure from the allowed behavior for operand register
pairs (hitherto labeled AARCH64_OPND_PAIRREG) observed for other
insns in this category.
For instructions `casp', `mrrs' and `msrr' the register pair must
always start at an even index and the second register in the pair is
the index + 1. This precludes the use of xzr as the first register,
given it corresponds to register number 31.
This is different in the case of `sysp' and `tlbip', however. These
allow the use of xzr and, where the first operand in the pair is
omitted, this is the default value assigned to it. When this
operand is assigned xzr, it is expected that the second operand will
likewise take on a value of xzr.
These two instructions therefore "break" two rules of register pairs:
* The first of the two registers is odd-numbered.
* The index of the second register is equal to that of the first,
and not n+1.
To allow for this departure from hitherto standard behavior, we
extend the functionality of the assembler by defining an extension of
the AARCH64_OPND_PAIRREG, called AARCH64_OPND_PAIRREG_OR_XZR.
It is used in defining `sysp' and `tlbip' and allows
`operand_general_constraint_met_p' to allow the pair to both take on
the value of xzr.
Indicating the presence of the Armv9.4-a features concerning 128-bit
Page Table Descriptors, 128-bit System Registers and Instructions,
the "+d128" architectural extension flag is added to the list of
possible -march options in Binutils, together with the necessary macro
for encoding d128 instructions.
Mike Frysinger [Wed, 30 Jun 2021 00:16:38 +0000 (20:16 -0400)]
sim: warnings: compile build tools with -Werror too
Add support for compiling build tools with various -Werror settings.
Since the tools don't compile cleanly with the same set of flags as
the rest of the sim code, we need to maintain & test a separate list.
Only bother when not cross-compiling so we don't have to test all the
flags against the build compiler. This should be good enough for our
actual development flows.
Tom Tromey [Sun, 1 Jan 2023 19:31:24 +0000 (12:31 -0700)]
Back out some parallel_for_each features
Now that the DWARF reader does not use parallel_for_each, we can
remove some of the features that were added just for it: return values
and task sizing.
The thread_pool typed tasks feature could also be removed, but I
haven't done so here. This one seemed less intrusive and perhaps more
likely to be needed at some point.
Tom Tromey [Sat, 21 Oct 2023 22:38:44 +0000 (16:38 -0600)]
Avoid language-based lookups in startup path
The previous patches are nearly enough to enable background DWARF
reading. However, this hack in language_defn::get_symbol_name_matcher
causes an early computation of current_language:
/* If currently in Ada mode, and the lookup name is wrapped in
'<...>', hijack all symbol name comparisons using the Ada
matcher, which handles the verbatim matching. */
if (current_language->la_language == language_ada
&& lookup_name.ada ().verbatim_p ())
return current_language->get_symbol_name_matcher_inner (lookup_name);
I considered various options here -- reversing the order of the
checks, or promoting the verbatim mode to not be a purely Ada feature
-- but in the end found that the few calls to this during startup
could be handled more directly.
In the JIT code, and in create_exception_master_breakpoint_hook, gdb
is really looking for a certain kind of symbol (text or data) using a
linkage name. Changing the lookup here is clearer and probably more
efficient as well.
In create_std_terminate_master_breakpoint, the lookup can't really be
done by linkage name (it would require relying on a certain mangling
scheme, and also may trip over versioned symbols) -- but we know that
this spot is C++-specific, and so the language ought to be temporarily
set to C++ here.
Tom Tromey [Sat, 21 Oct 2023 22:38:23 +0000 (16:38 -0600)]
Optimize lookup_minimal_symbol_text
lookup_minimal_symbol_text always loops over all objfiles, even when
an objfile is passed in as an argument. This patch changes the
function to loop over the minimal number of objfiles in the latter
situation.
Tom Tromey [Wed, 29 Mar 2023 16:55:13 +0000 (10:55 -0600)]
Lazy language setting
When gdb starts up with a symbol file, it uses the program's "main" to
decide the "static context" and the initial language. With background
DWARF reading, this means that gdb has to wait for a significant
amount of DWARF to be read synchronously.
This patch introduces lazy language setting. The idea here is that in
many cases, the prompt can show up early, making gdb feel more
responsive.
Tom Tromey [Wed, 29 Mar 2023 02:30:01 +0000 (20:30 -0600)]
Change current_language to be a macro
This changes the 'current_language' global to be a macro that wraps a
function call. This change will let a subsequent patch introduce lazy
language setting.
Tom Tromey [Sun, 1 Jan 2023 19:14:21 +0000 (12:14 -0700)]
Remove two quick_symbol_functions methods
quick_symbol_functions::read_partial_symbols is no longer implemented,
so both it and quick_symbol_functions::can_lazily_read_symbols can be
removed. This allows for other functions to be removed as well.
Note that SYMFILE_NO_READ is now pretty much dead. I haven't removed
it here -- but could if that's desirable. I tend to think that this
functionality would be better implemented in the core; but whenever I
dive into the non-DWARF readers it is pretty depressing.
Tom Tromey [Sun, 1 Jan 2023 16:51:04 +0000 (09:51 -0700)]
Simplify the public DWARF API
dwarf2_has_info and dwarf2_initialize_objfile are only separate
because the DWARF reader implemented lazy psymtab reading. However,
now that this is gone, we can simplify the public DWARF API again.
Tom Tromey [Sat, 25 Mar 2023 05:35:02 +0000 (23:35 -0600)]
Do more DWARF reading in the background
This patch rearranges the DWARF reader so that more work is done in
the background. This is PR symtab/29942.
The idea here is that there is only a small amount of work that must
be done on the main thread when scanning DWARF -- before the main
scan, the only part is mapping the section data.
Currently, the DWARF reader uses the quick_symbol_functions "lazy"
functionality to defer even starting to read. This patch instead
changes the reader to start reading immediately, but doing more in
worker tasks.
I think this could be further sped up by using the shared library load
map to avoid objfile loops like the one in expand_symtab_containing_pc
-- it seems like the correct objfile could be chosen more directly.
Tom Tromey [Tue, 27 Dec 2022 15:58:38 +0000 (08:58 -0700)]
Change how cooked index waits for threads
This changes the cooked index code to wait for threads in its
public-facing API. That is, the waits are done in cooked_index now,
and never in the cooked_index_shard. Centralizing this decision makes
it easier to wait for other events here as well.
Tom Tromey [Sat, 21 Oct 2023 21:22:09 +0000 (15:22 -0600)]
Add "maint set dwarf synchronous"
For testing, it's sometimes convenient to be able to request that
DWARF reading be done synchronously. This patch adds a new "maint"
setting for this purpose.
Tom Tromey [Fri, 30 Dec 2022 18:29:12 +0000 (11:29 -0700)]
Add quick_symbol_functions::compute_main_name
This adds a new compute_main_name method to quick_symbol_functions.
Currently there are no implementations of this, but a subsequent patch
will add one.
Tom Tromey [Sun, 10 Dec 2023 21:16:06 +0000 (14:16 -0700)]
Add deferred_warnings parameter to read_addrmap_from_aranges
When DWARF reading is done in the background,
read_addrmap_from_aranges will be called from a worker thread.
Because warnings can't be emitted from these threads, this patch adds
a new deferred_warnings parameter to the function, letting the caller
control exactly how the warnings are emitted.
Tom Tromey [Sat, 24 Dec 2022 15:40:48 +0000 (08:40 -0700)]
Refactor complaint thread-safety approach
This patch changes the way complaint works in a background thread.
The new approach requires installing a complaint interceptor in each
worker, and then the resulting complaints are treated as one of the
results of the computation. This change is needed for a subsequent
patch, where installing a complaint interceptor around a parallel-for
is no longer a viable approach.
Tom Tromey [Sat, 18 Feb 2023 16:27:58 +0000 (09:27 -0700)]
Add thread-safety to gdb's BFD wrappers
This changes gdb to ensure that gdb's BFD cache is guarded by a lock.
This avoids any races when multiple threads might open a BFD (and thus
use the BFD cache) at the same time.
Currently, this change is not needed because the the main thread waits
for some DWARF scanning to be completed before returning. The only
locking that's required is when opening DWO files, and there's a local
lock to this end in dwarf2/read.c.
However, in the coming patches, the DWARF reader will begin its work
earlier, in the background. This means there is the potential for the
DWARF reader and other code on the main thread to both attempt to open
BFDs at the same time.
Tom Tromey [Sat, 11 Nov 2023 16:46:44 +0000 (09:46 -0700)]
Add a couple of bfd_cache_close calls
This adds a couple of calls to bfd_cache_close at points where a BFD
isn't actively needed by gdb. Normally at these points, all the
needed section data is already mapped, so we can simply close the file
descriptor. This is harmless at worst, because if this is needed
after all, the BFD file descriptor cache will reopen it.
Tom Tromey [Fri, 10 Nov 2023 22:52:19 +0000 (15:52 -0700)]
Pre-read DWZ section data
This changes the DWZ code to pre-read the section data and somewhat
simplify the DWZ API. This makes it easier to add the bfd_cache_close
call to the new dwarf2_read_dwz_file function -- after this is done,
there shouldn't be a reason to keep the BFD's file descriptor open.
Tom Tromey [Sun, 12 Nov 2023 16:23:49 +0000 (09:23 -0700)]
Don't use objfile::intern in DWO code
The DWO code in the DWARF reader currently uses objfile::intern. This
accesses a shared data structure and so would be racy when used from
multiple threads. I don't believe this can happen right now, but
background reading could provoke this, and in any case it's better to
avoid this, just to be sure.
This patch changes this code to just use a std::string. A new type is
introduced to do hash table lookups, to avoid unnecessary copies.
Mike Frysinger [Tue, 9 Jan 2024 01:15:50 +0000 (20:15 -0500)]
sim: mips: drop old clean workaround
This logic dates back to the original import, and seems to be for
handling systems where `rm -f` (i.e. no files) would error out.
None of that is relevant for us with current automake, so drop it.
Some compilers don't understand the semctl API and think it's an input
argument even when it's used as an output, and then complains that it
is being used uninitialized. Zero it out explicitly to workaround it.
This adds some runtime overhead, but should be fairly minor as it's a
small stack buffer, and shouldn't be that relevant relative to all the
other logic in these functions.
Mike Frysinger [Sun, 7 Jan 2024 04:16:41 +0000 (23:16 -0500)]
sim: cgen: rework DI macros to avoid signed left shifts
The cgen code uses DI as int64_t and UDI as uint64_t. The DI macros
are used to construct 64-bit values from 32-bit values (for the low
and high parts). The MAKEDI macro casts the high 32-bit value to a
signed 32-bit value before shifting. If this created a negative
value, this would be undefined behavior according to the C standard.
All we care about is shifting the 32-bits as they are to the high
32-bits, not caring about sign extension (since there's nothing left
to shift into), and the low 32-bits being empty. This is what we
get from shifting an unsigned value, so cast it to unsigned 32-bit
to avoid undefined behavior.
While we're here, change the SETLODI macro to truncate the lower
value to 32-bits before we set it. If it was passing in a 64-bit
value, those high bits would get included too, and that's not what
we want.
Similarly, tweak the SETHIDI macro to cast the value to an unsigned
64-bit instead of a signed 64-bit. If the value was only 32-bits,
the behavior would be the same. If it happened to be signed 64-bit,
it would trigger the undefined behavior too.
This patch adds linker support to patch R_BPF_64_NODYLD32 relocations.
The implementation was based on comments and code in LLVM, as the GNU
toolchain does not uses this relocation type.
YunQiang Su [Fri, 24 Nov 2023 08:55:12 +0000 (16:55 +0800)]
MIPS/GAS: mips.exp, mark all mipsisa32*-linux as addr32
Currently, only mipsisa32-linux and mipsisa32el-linux is marked
as addr32, which make mipsisa32rN(el) not marked.
This change can fix 2 test failures on mipsisa32rN(el)-linux:
FAIL: MIPS MIPS64 MIPS-3D ASE instructions (-mips3d flag)
FAIL: MIPS MIPS64 MDMX ASE instructions (-mdmx flag)
These failures don't happen for mipsisa32rN-mti-elf etc,
due to that, the output is set as NO_ABI instead of O32, then
gas won't warn:
`fp=64' used with a 32-bit ABI
Maybe, we should change this behaivour in future.
srinath [Mon, 8 Jan 2024 14:13:28 +0000 (14:13 +0000)]
arm: Add support for Armv8.9-A and Armv9.4-A
This patch adds AArch32 support for -march=armv8.9-a and
-march=armv9.4-a. The behaviour of the new options can be
expressed using a combination of existing feature flags
and tables.
The cpu_arch_ver entries for ARM_ARCH_V9_4A and ARM_ARCH_V8_9A
are technically redundant but it including them for macro code
consistency across architectures.
Tom de Vries [Mon, 8 Jan 2024 12:01:50 +0000 (13:01 +0100)]
[gdb/testsuite] Add missing -no-prompt-anchor in gdb.base/vfork-follow-parent.exp
When running test-case gdb.base/vfork-follow-parent.exp it passes fine, but
when running it with "taskset -c 0" I run into:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 26606] (vfork-follow-parent-exit)]^M
[Switching to thread 1.1 (process 26606)]^M
(gdb) Reading symbols from vfork-follow-parent-exit...^M
FAIL: $exp: exec_file=vfork-follow-parent-exit: target-non-stop=on: \
non-stop=off: resolution_method=schedule-multiple: inferior 1 (timeout)
...
Sergey Bugaev [Mon, 1 Jan 2024 11:53:09 +0000 (14:53 +0300)]
Add support for the aarch64-gnu target (GNU/Hurd on AArch64)
Also recognized are aarch64-*-gnu tagrets, e.g. aarch64-pc-gnu or
aarch64-unknown-gnu.
The ld/emulparams/aarch64gnu.sh file is (for now) identical to aarch64fbsd.sh,
or to aarch64linux.sh with Linux-specific logic removed; and mainly different
from the generic aarch64elf.sh in that it does not set EMBEDDED=yes.
Coupled with a corresponding GCC patch, this produces a toolchain that can
sucessfully build working binaries targeting aarch64-gnu.
Tom de Vries [Mon, 8 Jan 2024 09:37:44 +0000 (10:37 +0100)]
[gdb/testsuite] Make gdb.base/solib-search.exp more robust
On aarch64-linux, with gcc 13.2.1, I run into:
...
(gdb) backtrace^M
#0 break_here () at solib-search.c:30^M
#1 0x0000fffff7f20194 in lib2_func4 () at solib-search-lib2.c:50^M
#2 0x0000fffff7f70194 in lib1_func3 () at solib-search-lib1.c:50^M
#3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
#4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
#5 0x00000000004101b4 in main () at solib-search.c:23^M
(gdb) PASS: gdb.base/solib-search.exp: \
backtrace (with wrong libs) (data collection)
FAIL: gdb.base/solib-search.exp: backtrace (with wrong libs)
...
The FAIL is generated by this code in the test-case:
...
if { $expect_fail } {
# If the backtrace output is correct the test isn't sufficiently
# testing what it should.
if { $count == $total_expected } {
set fail 1
}
...
The test-case:
- builds two versions of two shared libs, a "right" and "wrong" version, the
difference being an additional dummy function (called spacer function),
- uses the "right" version to generate a core file,
- uses the "wrong" version to interpret the core file, and
- generates a backtrace.
The intent is that the backtrace is incorrect due to using the "wrong"
version, but actually it's correct. This is because the spacer functions
aren't large enough.
Fix this by increasing the size of the spacer functions by adding a dummy
loop, after which we have, as expected, an incorrect backtrace:
...
(gdb) backtrace^M
#0 break_here () at solib-search.c:30^M
#1 0x0000fffff7f201c0 in ?? ()^M
#2 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
#3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
#4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
#5 0x00000000004101b4 in main () at solib-search.c:23^M
(gdb) PASS: gdb.base/solib-search.exp: \
backtrace (with wrong libs) (data collection)
PASS: gdb.base/solib-search.exp: backtrace (with wrong libs)
...
Mike Frysinger [Fri, 22 Dec 2023 00:41:17 +0000 (19:41 -0500)]
sim: cris: change temp var name slightly to avoid shadowing
Rename the temp var to avoid shadowing another one:
.../sim/cris/semcrisv10f-switch.c:11032:22: error: declaration of ‘tmp_tmpb’ shadows a previous local [-Werror=shadow=compatible-local]
11032 | tmp_tmpb = ({ SI tmp_tmpb;
| ^~~~~~~~
.../sim/cris/semcrisv10f-switch.c:11031:24: note: shadowed declaration is here
11031 | tmp_tmpres = ({ SI tmp_tmpb;
| ^~~~~~~~
The condition & swap code decoder only checks known bits and sets
based on that. If the variable is out of range, it ends up returning
uninitialized data. Turn that case into a hard error.
This fixes build warnings like:
sim/cris/semcrisv10f-switch.c:13115:11: error:
variable 'tmp_condres' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
H.J. Lu [Sat, 6 Jan 2024 14:43:04 +0000 (06:43 -0800)]
ld: Adjust x86 and x86-64 tests for -z mark-plt
To support -z mark-plt enabled by default, adjust x86 tests to accept
non-zero r_addend for JUMP_SLOT relocation and pass -z nomark-plt to
x86-64 tests if -z mark-plt changes the expected outputs.
Jan Beulich [Fri, 5 Jan 2024 07:20:23 +0000 (08:20 +0100)]
x86: corrections to CPU attribute/flags splitting
There are a number of issues with 734dfd1cc966 ("x86: pack CPU flags in
opcode table"):
- the condition when two array slots need writing wasn't correct (with
enough new Cpu* added an out of bounds array access would validly have
been complained about by the compiler),
- table generation didn't take into account CpuAttrUnused and CpuUnused
being independent, and hence there not always (not) being an "unused"
bitfield member in both structures,
- cpu_flags_from_attr() wasn't ready for use on big-endian hosts,
- there were two style violations.
projects / thirdparty / binutils-gdb.git / log
