bpf: fix relocation addend incorrect symbol value

Relocations installed by the BPF ELF backend were sometimes incorrectly
adding the symbol value to the relocation entry addend, when the correct
relocation value was already stored in the addend. This could lead to a
relocation effectively adding the symbol value twice.

Fix that by making bpf_elf_generic_reloc () more similar to the flow of
bfd_install_relocation in the case where howto->install_addend is set,
which is how it ought to behave.

bfd/
* bpf-reloc.def (R_BPF_64_ABS32, R_BPF_64_ABS64)
(R_BPF_64_NODYLD32): Set partial_inplace to true.
* elf64-bpf.c (bpf_elf_generic_reloc): Do not include the value
of the symbol when installing relocation. Copy some additional
logic from bfd_elf_generic_reloc.

gas/
* testsuite/gas/bpf/bpf.exp: Run new test.
* testsuite/gas/bpf/elf-relo-1.d: New.
* testsuite/gas/bpf/elf-relo-1.s: New.

gdb/testsuite: fix failure in gdb.python/py-inferior.exp

After this commit:

  commit 1925bba80edd37c2ef90ef1d2c599dfc2fc17f72
  Date:   Thu Jan 4 10:01:24 2024 +0000

      gdb/python: add gdb.InferiorThread.__repr__() method

failures were reported for gdb.python/py-inferior.exp.

The test grabs a gdb.InferiorThread object representing an inferior
thread, and then, later in the test, expects this Python object to
become invalid when the inferior thread has exited.

The gdb.InferiorThread object was obtained from the list returned by
calling gdb.Inferior.threads().

The mistake I made in the original commit was to assume that the order
of the threads returned from gdb.Inferior.threads() somehow reflected
the thread creation order.  Specifically, I was expecting the main
thread to be first in the list, and "other" threads to appear ... not
first.

However, the gdb.Inferior.threads() function creates a list and
populates it from a map.  The order of the threads in the returned
list has no obvious relationship to the thread creation order, and can
vary from host to host.

On my machine the ordering was as I expected, so the test passed for
me.  For others the ordering was not as expected, and it just happened
that we ended up recording the gdb.InferiorThread for the main thread.

As the main thread doesn't exit (until the test is over), the
gdb.InferiorThread object never became invalid, and the test failed.

Fixed in this commit by taking more care to correctly find a non-main
thread.  I do this by recording the main thread early on (when there
is only one inferior thread), and then finding any thread that is not
this main thread.

Then, once all of the secondary threads have exited, I know that the
second InferiorThread object I found should now be invalid.

The test still passes for me, and I believe this should fix the issue
for everyone else too.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31238

Update copyright year range in header of all files managed by GDB

This commit is the result of the following actions:

  - Running gdb/copyright.py to update all of the copyright headers to
    include 2024,

  - Manually updating a few files the copyright.py script told me to
    update, these files had copyright headers embedded within the
    file,

  - Regenerating gdbsupport/Makefile.in to refresh it's copyright
    date,

  - Using grep to find other files that still mentioned 2023.  If
    these files were updated last year from 2022 to 2023 then I've
    updated them this year to 2024.

I'm sure I've probably missed some dates.  Feel free to fix them up as
you spot them.

aarch64: Remove unused code

Most of this code became redundant in my previous commits, but ARMV8_6A_SVE was
already dead when it was first added.

aarch64: Make FEAT_ASMv8p2 instruction aliases always available

There's no reason to disallow the aliases when the aliased instructions are
always available.  The new behaviour matches existing LLVM behaviour.

aarch64: Add +xs flag for existing instructions

Additionally, change FEAT_XS tlbi variants to be gated on "+xs" instead of
"+d128".  This is an incremental improvement; there are still some FEAT_XS tlbi
variants that are gated incorrectly or missing entirely.

aarch64: Add +wfxt flag for existing instructions

aarch64: Add +rcpc2 flag for existing instructions

aarch64: Add +flagm2 flag for existing instructions

aarch64: Add +frintts flag for existing instructions

aarch64: Add +jscvt flag for existing fjcvtzs instruction

aarch64: Fix option parsing to disallow prefixes of valid options

Add "+rdm" as an explicit alias for "+rdma", to maintain existing compatibility
with Clang.

aarch64: Add +fcma alias for +compnum

aarch64: Fix +lse feature flag dependency

gdb/doc: update examples in gdb.Progspace and gdb.Objfile docs

This commit updates the Python example code in the gdb.Progspace and
gdb.Objfile sections of the docs.  Changes made:

  1. Use @value{GDBP} for the GDB prompt rather than
  hard-coding (gdB),

  2. Use @group...@end group to split the example code into
  unbreakable chunks, and

  3. Add parenthesis to the Python print() calls in the examples.  In
  Python 2 it was OK to drop the parenthesis, but now GDB is Python 3
  only, example code should include the parenthesis.

Approved-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/doc: add some notes on selecting suitable attribute names

In previous commits I've added Object.__dict__ support to gdb.Inferior
and gdb.InferiorThread, this is similar to the existing support for
gdb.Objfile and gdb.Progspace.

This commit extends the documentation to offer the user some guidance
on selecting good names for their custom attributes so they
can (hopefully) avoid conflicting with any future attributes that GDB
might add.

The rules I've proposed are:

  1. Don't start user attributes with a lower case letter, all the
  current GDB attributes start with a lower case letter, and I suspect
  all future attributes would also start with a lower case letter, and

  2. Don't start user attributes with a double underscore, this risks
  conflicting with Python built in attributes (e.g. __dict__) - though
  clearly the user would need to start and end with a double
  underscore, but it seemed easier just to say no double underscores.

I'm doing this as a separate commit as I've updated the docs for the
existing gdb.Objfile and gdb.Progspace so they all reference a single
paragraph on selecting attribute names.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: Add gdb.InferiorThread.__dict__ attribute

The gdb.Objfile, gdb.Progspace, gdb.Type, and gdb.Inferior Python
types already have a __dict__ attribute, which allows users to create
user defined attributes within the objects.  This is useful if the
user wants to cache information within an object.

This commit adds the same functionality to the gdb.InferiorThread
type.

After this commit there is a new gdb.InferiorThread.__dict__
attribute, which is a dictionary.  A user can, for example, do this:

  (gdb) pi
  >>> t = gdb.selected_thread()
  >>> t._user_attribute = 123
  >>> t._user_attribute
  123
  >>>

There's a new test included.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: Add gdb.Inferior.__dict__ attribute

The gdb.Objfile, gdb.Progspace, and gdb.Type Python types already have
a __dict__ attribute, which allows users to create user defined
attributes within the objects.  This is useful if the user wants to
cache information within an object.

This commit adds the same functionality to the gdb.Inferior type.

After this commit there is a new gdb.Inferior.__dict__ attribute,
which is a dictionary.  A user can, for example, do this:

  (gdb) pi
  >>> i = gdb.selected_inferior()
  >>> i._user_attribute = 123
  >>> i._user_attribute
  123
  >>>

There's a new test included.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: remove users ability to create gdb.Progspace objects

I noticed that it is possible for the user to create a new
gdb.Progspace object, like this:

  (gdb) pi
  >>> p = gdb.Progspace()
  >>> p
  <gdb.Progspace object at 0x7ffad4219c10>
  >>> p.is_valid()
  False

As the new gdb.Progspace object is not associated with an actual C++
program_space object within GDB core, then the new gdb.Progspace is
created invalid, and there is no way in which the new object can ever
become valid.

Nor do I believe there's anywhere in the Python API where it makes
sense to consume an invalid gdb.Progspace created in this way, for
example, the gdb.Progspace could be passed as the locus to
register_type_printer, but all that would happen is that the
registered printer would never be used.

In this commit I propose to remove the ability to create new
gdb.Progspace objects.  Attempting to do so now gives an error, like
this:

  (gdb) pi
  >>> gdb.Progspace()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: cannot create 'gdb.Progspace' instances

Of course, there is a small risk here that some existing user code
might break ... but if that happens I don't believe the user code can
have been doing anything useful, so I see this as a small risk.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: add gdb.Frame.__repr__() method

Add a gdb.Frame.__repr__() method.  Before this patch we would see
output like this:

  (gdb) pi
  >>> gdb.selected_frame()
  <gdb.Frame object at 0x7fa8cc2df270>

After this patch, we now see:

  (gdb) pi
  >>> gdb.selected_frame()
  <gdb.Frame level=0 frame-id={stack=0x7ffff7da0ed0,code=0x000000000040115d,!special}>

More verbose, but, I hope, more useful.

If the gdb.Frame becomes invalid, then we will see:

  (gdb) pi
  >>> invalid_frame_variable
  <gdb.Frame (invalid)>

which is inline with how other invalid objects are displayed.

Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: add gdb.InferiorThread.__repr__() method

Add a gdb.InferiorThread.__repr__() method.  Before this patch we
would see output like this:

  (gdb) pi
  >>> gdb.selected_thread()
  <gdb.InferiorThread object at 0x7f4dcc49b970>

After this patch, we now see:

  (gdb) pi
  >>> gdb.selected_thread()
  <gdb.InferiorThread id=1.2 target-id="Thread 0x7ffff7da1700 (LWP 458134)">

More verbose, but, I hope, more useful.

If the gdb.InferiorThread becomes invalid, then we will see:

  (gdb) pi
  >>> invalid_thread_variable
  <gdb.InferiorThread (invalid)>

Which is inline with how other invalid objects are displayed.

Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: hoist common invalid object repr code into py-utils.c

Many object types now have a __repr__() function implementation.  A
common pattern is that, if an object is invalid, we print its
representation as: <TYPENAME (invalid)>.

I thought it might be a good idea to move the formatting of this
specific representation into a utility function, and then update all
of our existing code to call the new function.

The only place where I haven't made use of the new function is in
unwind_infopy_repr, where we currently return a different string.
This case is a little different as the UnwindInfo is invalid because
it references a frame, and it is the frame itself which is invalid.
That said, I think it would be fine to switch to using the standard
format; if the UnwindInfo references an invalid frame, then the
UnwindInfo is itself invalid.  But changing this would be an actual
change in behaviour, while all the other changes in this commit are
just refactoring.

Approved-By: Tom Tromey <tom@tromey.com>

gdb: add trailing '/' when using 'complete' with directory names

This patch contains work pulled from this previously proposed patch:

  https://inbox.sourceware.org/gdb-patches/20210213220752.32581-2-lsix@lancelotsix.com/

But has been modified by me.  Credit for the original idea and
implementation goes to Lancelot, any bugs in this new iteration belong
to me.

Consider the executable `/tmp/foo/my_exec', and if we assume `/tmp' is
empty other than the `foo' sub-directory, then currently within GDB,
if I type:

  (gdb) file /tmp/f

and then hit TAB, GDB completes this to:

  (gdb) file /tmp/foo/

notice that not only did GDB fill in the whole of `foo', but GDB also
added a trailing '/' character.  This is done within readline when the
path that was just completed is a directory.  However, if I instead
do:

  (gdb) complete file /tmp/f
  file /tmp/foo

I now see the completed directory name, but the trailing '/' is
missing.  The reason is that, in this case, the completions are not
offered via readline, but are handled entirely within GDB, and so
readline never gets the chance to add the trailing '/' character.

The above patch added filename option support to GDB, which included
completion of the filename options.  This initially suffered from the
same problem that I've outlined above, but the above patch proposed a
solution to this problem, but this solution only applied to filename
options (which have still not been added to GDB), and was mixed in
with the complete filename options support.

This patch pulls out just the fix for the trailing "/" problem, and
applies it to GDB's general filename completion.  This patch does not
add filename options to GDB, that can always be done later, but I
think this small part is itself a useful fix.

One of the biggest changes I made in this version is that I got rid of
the set_from_readline member function, instead, I now pass the value
of m_from_readline into the completion_tracker constructor.

I then moved the addition of the trailing '/' into filename_completer
so that it is applied in the general filename completion case.  I also
added a call to gdb_tilde_expand which was missing from the original
patch, I haven't tested, but I suspect that this meant that the
original patch would not add the trailing '/' if the user entered a
path starting with a tilde character.

When writing the test for this patch I ran into two problems.

The first was that the procedures in lib/completion-support.exp relied
on the command being completed for the test name.  This is fine for
many commands, but not when completing a filename, if we use the
command in this case the test name will (potentially) include the name
of the directory in which the test is being run, which means we can't
compare results between two runs of GDB from different directories.

So in this commit I've gone through completion-support.exp and added a
new (optional) testname argument to many of the procedures, this
allows me to give a unique test name, that doesn't include the path
for my new tests.

The second issue was in the procedure make_tab_completion_list_re,
this builds the completion list which is displayed after a double tab
when there are multiple possible completions.

The procedure added the regexp ' +' after each completion, and then
added another ' +' at the very end of the expected output.  So, if we
expected to match the name of two functions 'f1' and 'f2' the
generated regexp would be: 'f1 +f2 + +'.  This would match just fine,
the actual output would be: 'f1  f2  ', notice that we get two spaces
after each function name.

However, if we complete two directory names 'd1' and 'd2' then the
output will be 'd1/ d2/ '.  Notice that now we only have a single
space between each match, however, we do get the '/' added instead.

What happens is that when presenting the matches, readline always adds
the appropriate trailing character; if we performed tab completion of
'break f1' then, as 'f1' is a unique match, we'd get 'break f1 ' with
a trailing space added.  However, if we complete 'file d1' then we get
'file d1/'.  Then readline is adding a single space after each
possible match, including the last one, which accounts for the
trailing space character.

To resolve this I've simply remove the addition o the second ' +'
within make_tab_completion_list_re, for the function completion
example I gave above the expected pattern is now 'f1 +f2 +', which for
the directory case we expect 'd1/ +d2/ +', both of which work just
fine.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16265
Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb/python: New InferiorThread.ptid_string attribute

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>

[gdb/testsuite] Use require in gdb.dwarf2/assign-variable-value-to-register.exp

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.

gas: sframe: warn when skipping SFrame FDE generation

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.

LoongArch: Fix relaxation overflow caused by section alignment

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.

x86: Fix indentation and use true/false instead of 1/0

gas/ChangeLog:

        * config/tc-i386.c (establish_rex): Fix indentation.
        (check_EgprOperands): Use true/false instead of 1/0.

Automatic date update in version.in

gdb: fix frame passed to gdbarch_value_to_register in value_assign

Commit 78f2fd84e83 ("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

[gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le

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

[gdb/testsuite] Extend gdb.base/kill-during-detach.exp

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

LoongArch: ld: Adjusted some code order in relax.exp.

ld/testsuite/ChangeLog:

* ld/testsuite/ld-loongarch-elf/relax.exp: Modify test.

LoongArch: Discard extra spaces in objdump output

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.

sim: ppc: return register error when unhandled

We don't want to fallthru and use cooked_buf when we haven't initialized
it to anything.  Returning 0 indicates the register wasn't recognized.

sim: m32r: enable warnings in traps.c

File should be clean now!

sim: m32r: fixup some of the int<->pointer casts

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.

sim: m32r: fix missing break statement

The ftime syscall should not fallthrough to the sync syscall.
Clearly the code was missing a break statement.

sim: m32r: migrate ftime() to clock_gettime()

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.

sim: m32r: cleanup unused variables

We've been building this file with -Wno-error, so clean up unused
variable warnings.

sim: igen: add printf attributes to the prototypes too

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.

gdbsupport: tighten up libiberty code a bit with dnl

No functional change here, just touch up generated output slightly.

Approved-By: Tom Tromey <tom@tromey.com>

sim: build: switch to gdbsupport/libiberty.m4

Leverage this common logic to find all the libiberty settings rather
than duplicate it ourselves.

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.

gdb: libiberty: switch to AC_CHECK_DECLS_ONCE

Only check these decls once in case other m4 macros also look for them.

Approved-By: Tom Tromey <tom@tromey.com>

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.

Approved-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

gprofng: add an examples directory

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.

Fix AIX catchpoint warning during fork () event

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.

Sync top level configure and makefiles

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.

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

[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

[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

[gdb] Make variable printed bool in info_checkpoints_command

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>

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.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>

gdb/symtab: Make cooked_index_entry::parent_entry private

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>

gdb/symtab: Allow changing of added cooked_index entries

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>

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>

Automatic date update in version.in

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.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31223

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'.

* Makefile.in: Rebuild.
* Makefile.tpl (BASE_EXPORTS): Add GUILE.
(GUILE): New variable.
* Makefile.def (flags_to_pass): Add GUILE.

ld: Add --enable-mark-plt configure option

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.

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:

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.

x86: Don't check R_386_NONE nor R_X86_64_NONE

Update x86 ELF linker to skip R_386_NONE/R_X86_64_NONE when scanning
relocations.

bfd/

* PR ld/31047
* elf32-i386.c (elf_i386_scan_relocs): Don't check R_386_NONE.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Don't check
R_X86_64_NONE.

ld/

* PR ld/31047
* testsuite/ld-i386/i386.exp: Run PR ld/31047 test.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-i386/pr31047.d: New file.
* testsuite/ld-x86-64/pr31047-x32.d: Likewise.
* testsuite/ld-x86-64/pr31047.d: Likewise.
* testsuite/ld-x86-64/pr31047a.s: Likewise.
* testsuite/ld-x86-64/pr31047b.s: Likewise.

Fix two bugs in gdbserver thread name handling

Simon pointed out that my earlier patch to gdbserver's thread name
code:

    commit 07b3255c3bae7126a0d679f957788560351eb236
    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

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.

Regression tested on x86-64 Fedora 38.

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.

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).

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.

Synchronize sourceware version of the libiberty sources with the master gcc versions.

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

aarch64: ADD FEAT_THE RCWCAS instructions.

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)

aarch64: Regenerate aarch64-*-2.c files

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.

aarch64: Add TLBIP tests

aarch64: Add xs variants of tlbip operands

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.

[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2020

aarch64: Implement TLBIP 128-bit instruction

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.

Syntax:

sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>}

aarch64: Add support for optional operand pairs

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:

       #define F_OPD1_OPT (2 << 12) : 0b10 << 12
       #define F_OPD2_OPT (3 << 12) : 0b11 << 12

such that by virtue of the observation that

       (F_OPD1_OPT | F_OPD2_OPT) == F_OPD2_OPT

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.

aarch64: Expand maximum number of operands from 5 to 6

Given the introduction of the new Armv9.4-a `sysp' insn using the
following syntax:

sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>}

and by extension the need to encode 6 assembly operands, extend
Binutils to handle instructions taking 6 operands, up from a previous
maximum of 5.

aarch64: Add +d128 architectural feature support

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.

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.

sim: igen: fix format-zero-length warnings

Fix warnings from calling printf functions with "" which normally
is useless.

sim: m68hc11: gencode: add printf markings

sim: m32c: fix declaration-after-statement warnings

sim: warnings: fix unused variable warnings

Leave the igen code in place as it's meant to be used with newer
(to-be-written) code ported from the ppc version.

The sh code isn't really necessary as the opcodes enums have been
maintained independently from here, and the lists are out-of-sync
already.

sim: warnings: mark local funcs/vars as static

These are only used in the respective files, so mark them as static.
This fixes missing prototype warnings at build time.

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.

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.

After this patch, the "file" case is much faster:

    (gdb) file /tmp/gdb
    2023-10-23 13:16:54.456 - command started
    Reading symbols from /tmp/gdb...
    2023-10-23 13:16:54.520 - command finished
    Command execution time: 0.225906 (cpu), 0.064313 (wall)

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.

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.

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.

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.

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.

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.

Before this patch, "file" on my machine:

    (gdb) file /tmp/gdb
    2023-10-23 12:29:56.885 - command started
    Reading symbols from /tmp/gdb...
    2023-10-23 12:29:58.047 - command finished
    Command execution time: 5.867228 (cpu), 1.162444 (wall)

After the patch, more work is done in the background and so this takes
a bit less time:

    (gdb) file /tmp/gdb
    2023-10-23 13:25:51.391 - command started
    Reading symbols from /tmp/gdb...
    2023-10-23 13:25:51.712 - command finished
    Command execution time: 1.894500 (cpu), 0.320306 (wall)

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.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29942
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30174

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.