This commit adds a new InferiorThread.ptid_string attribute. This
read-only attribute contains the string returned by target_pid_to_str,
which actually converts a ptid (not pid) to a string.
This is the string that appears (at least in part) in the output of
'info threads' in the 'Target Id' column, but also in the thread
exited message that GDB prints.
Having access to this string from Python is useful for allowing
extensions identify threads in a similar way to how GDB core would
identify the thread.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
In test-case gdb.dwarf2/assign-variable-value-to-register.exp a return is
missing here after the unsupported:
...
if { ![is_x86_64_m64_target] } {
unsupported "unsupported architecture"
}
...
and consequently on aarch64-linux I ran into an UNSUPPORTED followed by 3
FAILs.
Fix this by simply using require:
...
require is_x86_64_m64_target
...
Tested on x86_64-linux and aarch64-linux.
Fix PR gas/31213.
gas/
PR gas/31213
* gen-sframe.c (sframe_do_cfi_insn): Add new warning.
gas/testsuite/
* gas/cfi-sframe/common-empty-1.d: Test the new warning as well.
* gas/cfi-sframe/common-empty-2.d: Likewise.
When deleting NOP instructions addend by .align at second pass, this may cause
the PC decrease but the symbol address to remain unchanged due to section
alignment.
To solve this question, we subtract a maximux alignment of all sections like
RISC-V.
Commit 78f2fd84e8 ("gdb: remove VALUE_REGNUM, add value::regnum")
introduced an unexpected change in value_assign. It replaced
`get_prev_frame_always (next_frame)` with `next_frame`in the call to
gdbarch_value_to_register.
This is the result of a merge error, since I previously had a patch to
change gdbarch_value_to_register to take the next frame, and later
decided to drop it. Revert that change.
Add a test based on the DWARF assembler to expose the problem and test
the fix. I also tested on ppc64le to make sure the problem reported in
PR 31231 was fixed.
Change-Id: Ib8b851287ac27a4b2e386f7b680cf65865e6aee6
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31231
On ppc64le-linux, I run into:
...
(gdb) bt^M
#0 0x00000000100006dc in foobar (J=2)^M
#1 0x000000001000070c in prog ()^M
(gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo
...
The test-case attemps to emulate additional entry points of a function, with
function bar having entry points foo and foobar:
...
(gdb) p bar
$1 = {void (int, int)} 0x1000064c <bar>
(gdb) p foo
$2 = {void (int, int)} 0x10000698 <foo>
(gdb) p foobar
$3 = {void (int)} 0x100006d0 <foobar>
...
However, when setting a breakpoint on the entry point foo:
...
(gdb) b foo
Breakpoint 1 at 0x100006dc
...
it ends up in foobar instead of in foo, due to prologue skipping, and
consequently the backtrace show foobar instead foo.
The problem is that the test-case does not emulate an actual prologue at each
entry point.
Fix this by disabling the prologue skipping when setting a breakpoint, using
"break *foo".
Tested on ppc64le-linux and x86_64-linux.
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
PR testsuite/31232
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232
I ran into the following FAIL:
...
(gdb) python kill_and_detach()^M
Traceback (most recent call last):^M
File "<string>", line 1, in <module>^M
File "<string>", line 7, in kill_and_detach^M
gdb.error: Selected thread is running.^M
Error while executing Python code.^M
(gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \
python kill_and_detach()
...
The FAIL happens as follows:
- gdb is debugging a process A
- a checkpoint is created, in other words, fork is called in the inferior,
after which we have:
- checkpoint 0 (the fork parent, process A), and
- checkpoint 1 (the fork child, process B).
- during checkpoint creation, lseek is called in the inferior (process A) for
all file descriptors, and it returns != -1 for at least one file descriptor.
- the process A continues in the background
- gdb detaches, from process A
- gdb switches to process B, in other words, it restarts checkpoint 1
- while restarting checkpoint 1, gdb tries to call lseek in the inferior
(process B), but this fails because gdb incorrectly thinks that inferior B
is running.
This happens because linux_nat_switch_fork patches the pid of process B into
the current inferior and current thread which where originally representing
process A. So, because process A was running in the background, the
thread_info fields executing and resumed are set accordingly, but they are not
correct for process B.
There's a line in fork_load_infrun_state that fixes up the thread_info field
stop_pc, so fix this by adding similar fixups for the executing and resumed
fields alongside.
The FAIL did not always reproduce, so extend the test-case to reliably
trigger this scenario.
Tested on x86_64-linux.
Approved-By: Kevin Buettner <kevinb@redhat.com>
PR gdb/31203
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203
Due to the formatted output of objdump, some instructions
that do not require output operands (such as nop/ret) will
have extra spaces added after them.
Determine whether to output operands through the format
of opcodes. When opc->format is an empty string, no extra
spaces are output.
The m32r trap code was written for a 32-bit Linux host (and really, one
whose Linux ABI matched pretty exactly). This has lead to conversions
between integers and pointers which breaks down hard on 64-bit hosts.
Clean up some of the functions where possible to avoid unnecessary
conversions, use uintptr_t to cast 32-bit target pointers to host
pointers in some places, and just stub out a few functions that can't
easily be salvaged currently when sizeof(void*) is not 32-bits. This
is a bit ugly, but lets us enable warnings for the whole file.
The ftime() function has been deprecated since POSIX-1-2004, and
removed in POSIX.1-2008. It's also been deprecated/removed in glibc
since 2.33. POSIX has always said the function is not portable, and
its return value, timezone, and dstflag fields are unspecified. Even
if Linux/glibc & m32r had defined behavior, those aren't the host for
the sim runtime.
So let's stop using the function and switch to clock_gettime. gnulib
already has detection support for it, and it's been around since at
least POSIX-1-2004.
While gcc propagates the printf attribute via the typedef, clang
doesn't seem to, so add it to the prototypes themselves too. We
still keep it on the prototype for cases where it's used as a
variable.
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.
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
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.
This update brings in the following commits from the gcc mainline:
commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f
Author: Tom Tromey <tom@tromey.com>
Date: Tue Jan 9 06:25:26 2024 -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'.
commit 725fb3595622a4ad8cd078a42fab1c395cbf90cb
Author: Pierre-Emmanuel Patry <pierre-emmanuel.patry@embecosm.com>
Date: Wed Oct 25 13:06:48 2023 +0200
build: Add libgrust as compilation modules
Define the libgrust directory as a host compilation module as well as
for targets. Disable target libgrust if we're not building target
libstdc++.
commit 56ca59a03150cf44cea340f58967c990ed6bf43c
Author: Lewis Hyatt <lhyatt@gmail.com>
Date: Thu Nov 16 11:18:37 2023 -0500
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.
commit 6a6d3817afa02bbcd2388c8e005da6faf88932f1
Author: Iain Sandoe <iain@sandoe.co.uk>
Date: Sun Mar 28 14:48:17 2021 +0100
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).
commit 2551e10038a70901f30b2168e6e3af4536748f3c
Author: Sergei Trofimovich <siarheit@google.com>
Date: Mon Oct 2 12:08:17 2023 +0100
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.
commit d1bff1ba4d470f6723be83c0e3c4d5083e51877a
Author: Thomas Schwinge <thomas@codesourcery.com>
Date: Thu Jun 1 23:07:37 2023 +0200
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
PR testsuite/109951
* Makefile.tpl (BASE_TARGET_EXPORTS): Add
'SYSROOT_CFLAGS_FOR_TARGET'.
* Makefile.in: Regenerate.
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
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
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
While reading info_checkpoints_command, I noticed variable printed:
...
const fork_info *printed = NULL;
...
for (const fork_info &fi : fork_list)
{
if (requested > 0 && fi.num != requested)
continue;
printed = &fi;
...
}
if (printed == NULL)
...
has pointer type, but is just used as bool.
Make this explicit by changing the variable type to bool.
Tested on x86_64-linux.
Approved-By: Kevin Buettner <kevinb@redhat.com>
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.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Make cooked_index_entry::parent_entry private, and add member functions to
access it.
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
Make cooked_index_storage::add and cooked_index_entry::add return a
"cooked_index_entry *" instead of a "const cooked_index_entry *".
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
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>
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31223
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.in: Rebuild.
* Makefile.tpl (BASE_EXPORTS): Add GUILE.
(GUILE): New variable.
* Makefile.def (flags_to_pass): Add GUILE.
Add --enable-mark-plt linker configure option to mark PLT entries with
DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT dynamic tags by
default.
* NEWS: Mention -z mark-plt/-z nomark-plt and --enable-mark-plt.
* config.in: Regenerated.
* configure: Likewise.
* configure.ac: Add --enable-mark-plt.
(DEFAULT_LD_Z_MARK_PLT): New AC_DEFINE_UNQUOTED.
* emulparams/x86-64-plt.sh (PARSE_AND_LIST_OPTIONS_X86_64_PLT):
Support DEFAULT_LD_Z_MARK_PLT.
* emultempl/elf-x86.em (elf_x86_64_before_parse): New function.
(LDEMUL_BEFORE_PARSE): New. Set to elf_x86_64_before_parse for
x86-64 targets.
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:
commit f8587a61892cbafd98ce599131bf4f103466f084
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri May 20 19:21:48 2022 -0700
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.
Simon pointed out that my earlier patch to gdbserver's thread name
code:
commit 07b3255c3b
Author: Tom Tromey <tom@tromey.com>
Date: Thu Jul 13 17:28:48 2023 -0600
Filter invalid encodings from Linux thread names
... introduced a regression. This bug was that the iconv output was
not \0-terminated.
Looking at it, I found another bug as well -- replace_non_ascii would
not \0-terminate, and also would return the wrong pointer
This patch fixes both of them.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31153
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.
Regression tested on x86-64 Fedora 38.
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.
PR gas/31178
In da0784f961 ("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).
While having been moved a couple of times since its introduction in
f6c7c3e8b7 ("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.
This brings in the following commits:
commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Dec 5 23:32:19 2023 +0100
libiberty: Fix build with GCC < 7
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.
commit 691858d279335eeeeed3afafdf872b1c5f8f4201
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Tue Dec 5 11:04:06 2023 +0100
libiberty: Fix pex_unix_wait return type
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.
commit c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6
Author: Jason Merrill <jason@redhat.com>
Date: Mon Sep 25 10:15:02 2023 +0100
c++: mangle function template constraints
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.
commit f2c52c0dfde581461959b0e2b423ad106aadf179
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Thu Nov 30 10:06:23 2023 +0100
libiberty: Disable hwcaps for sha1.o
This patch
commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Nov 28 13:14:05 2023 +0100
libiberty: Use x86 HW optimized sha1
broke Solaris/x86 bootstrap with the native as:
libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go
ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000 [ SHA1 ]
gccgo: fatal error: Killed signal terminated program go1
As is already done in a couple of other similar cases, this patches
disables hwcaps support for libiberty.
Initially, this didn't work because config/hwcaps.m4 uses target_os, but
didn't ensure it is defined.
Tested on i386-pc-solaris2.11 with as and gas.
commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Nov 28 13:14:05 2023 +0100
libiberty: Use x86 HW optimized sha1
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.
commit 01bc30b222a9d2ff0269325d9e367f8f1fcef942
Author: Mark Wielaard <mjw@redhat.com>
Date: Wed Nov 15 20:27:08 2023 +0100
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.
commit 879cf9ff45d94065d89e24b71c6b27c7076ac518
Author: Brendan Shanks <bshanks@codeweavers.com>
Date: Thu Nov 9 21:01:07 2023 -0700
[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.
commit 810bcc00156cefce7ad40fc9d8de6e43c3a04450
Author: Jason Merrill <jason@redhat.com>
Date: Thu Aug 17 11:36:23 2023 -0400
c++: constrained hidden friends [PR109751]
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.
PR c++/109751
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)
