gdb: use put_frame_register instead of put_frame_register_bytes in pseudo_to_concat_raw

Here, we write single complete registers, we don't need the
functionality of put_frame_register_bytes, use put_frame_register
instead.

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

gdb: remove stale comment in value_assign

This comment is no longer relevant, put_frame_register_bytes now accepts
the "next frame".

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

aarch64: Add FEAT_ITE support

This patch add support for FEAT_ITE "Instrumentation Extension" adding
the "trcit" instruction.

This is enabled by the +ite march flag.

aarch64: Add FEAT_ECBHB support

This patch add support for FEAT_ECBHB "Exploitative control using
branch history information" adding the "clrbhb" instruction.  AFAIU
the same alias was originally added as "clearbhb" before the
architecture was finalized (Mandatory v8.9-a/v9.4-a; Optional
v8.0-a+/v9.0-a+).

aarch64: Add FEAT_SPECRES2 support

This patch add supports for FEAT_SPECRES2 "Enhanced speculation
restriction instructions" adding the "cosp" instruction.

This is mandatory v8.9-a/v9.4-a and optional v8.0-a+/v9.0-a+.  It is
enabled by the +predres2 march flag.

gdb: register frame_destroyed function for amd64 gdbarch

gdbarches usually register functions to check when a frame is destroyed
which is used with software watchpoints, since the expression of the
watchpoint is no longer vlaid at this point.  On amd64, this wasn't done
anymore because GCC started using CFA for variable locations instead.

However, clang doesn't use the CFA and instead relies on specifying when
an epilogue has started, meaning software watchpoints get a spurious hit
when a frame is destroyed. This patch re-adds the code to register the
function that detects when a frame is destroyed, but only uses this when
the producer is LLVM, so gcc code isn't affected. The logic that
identifies the epilogue has been factored out into the new function
amd64_stack_frame_destroyed_p_1, so the frame sniffer can call it
directly, and its behavior isn't changed.

This can also remove the XFAIL added to gdb.python/pq-watchpoint tests
that handled this exact flaw in clang.

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

sim: common: delete unused argbuf in generated mloop code

This function only uses prev_abuf, not abuf, and doesn't inline code
from the various ports on the fly, so abuf will never be used.

sim: v850: fix -Wunused-variable warnings

sim: sh: fix -Wunused-variable warnings

sim: moxie: fix -Wunused-variable warnings

sim: msp430: fix -Wunused-variable warnings

sim: mn10300: fix -Wunused-variable warnings

sim: mips: fix -Wunused-variable warnings

sim: microblaze: fix -Wunused-variable warnings

sim: mcore: fix -Wunused-variable warnings

sim: m32r: fix -Wunused-variable warnings

sim: lm32: fix -Wunused-variable warnings

sim: iq2000: fix -Wunused-variable warnings

sim: h8300: fix -Wunused-variable warnings

sim: ft32: fix -Wunused-variable warnings

sim: frv: fix -Wunused-variable warnings

sim: erc32: fix -Wunused-variable warnings

sim: cris: fix -Wunused-variable warnings

sim: cr16: fix -Wunused-variable warnings

sim: bpf: fix -Wunused-variable warnings

sim: bfin: fix -Wunused-variable warnings

sim: aarch64: fix -Wunused-variable warnings

sim: common: fix -Wunused-variable warnings

cpu: cris: drop some unused vars

These fix unused variable warnings in the generated sim.

x86: Remove the restriction for size of the mask register in AVX10

Since AVX10.1/256 will also allow 64 bit mask register, we will
remove the restriction for size of the mask register in AVX10.

gas/ChangeLog:

* config/tc-i386.c (VSZ128, VSZ256, VSZ512): New.
(VEX_check_encoding): Remove opcode_modifier check for vsz.
* testsuite/gas/i386/avx10-vsz.l: Remove testcases for mask
registers since they are not needed.
* testsuite/gas/i386/avx10-vsz.s: Ditto.

opcodes/ChangeLog:

* i386-gen.c: Remove Vsz.
* i386-opc.h: Ditto.
* i386-opc.tbl: Remove kvsz.
* i386-tbl.h: Regenerated.

LoongArch: Allow la.got -> la.pcrel relaxation for shared object

Even in shared objects, la.got -> la.pcrel relaxation can still be
performed for symbols with hidden visibility. For example, if a.c is:

    extern int x;
    int f() { return x++; }

and b.c is:

    int x = 114514;

If compiling and linking with:

    gcc -shared -fPIC -O2 -fvisibility=hidden a.c b.c

Then the la.got in a.o should be relaxed to la.pcrel, and the resulted f
should be like:

    pcaddi  $t0, x
    ldptr.w $a0, $t0, 0
    addi.w  $t1, $a0, 1
    stptr.w $t1, $t0, 0
    ret

Remove bfd_link_executable from the condition of la.got -> la.pcrel
relaxation so this will really happen.  The SYMBOL_REFERENCES_LOCAL
check is enough not to wrongly relax preemptable symbols (for e.g.
when -fvisibility=hidden is not used).

Note that on x86_64 this is also relaxed and the produced code is like:

    lea x(%rip), %rdx
    mov (%rdx), %rax
    lea 1(%rax), %ecx
    mov %ecx, (%rdx)
    ret

Tested by running ld test suite, bootstrapping and regtesting GCC with
the patched ld, and building and testing Glibc with the patched ld.  No
regression is observed.

Signed-off-by: Xi Ruoyao <xry111@xry111.site>

Yet another fix for mcore-sim (rotli)

This came up testing the CRC optimization work from Mariam@RAU.
Basically to optimize some CRC loops into table lookups or carryless
multiplies, we may need to do a bit reflection, which on the mcore
processor is done using a rotate instruction.

Unfortunately the simulator implementation of rotates has the exact same
problem as we saw with right shifts.  The input value may have been sign
extended from 32 to 64 bits.  When we rotate the extended value, we get
those sign extension bits and thus the wrong result.

The fix is the same.  Rather than using a "long", use a uint32_t for the
type of the temporary.  This fixes a handful of tests in the GCC testsuite:

Automatic date update in version.in

gettext: disable install, docs targets, libasprintf, threads

This fixes issues reported by David Edelsohn <dje.gcc@gmail.com>, and by
Eric Gallager <egallager@gcc.gnu.org>.

ChangeLog:

* Makefile.def (gettext): Disable (via missing)
{install-,}{pdf,html,info,dvi} and TAGS targets.  Set no_install
to true.  Add --disable-threads --disable-libasprintf.
* Makefile.in: Regenerate.

ld: Print 0 size in B and not in GB

When using --print-memory-usage, the printed size can be zero and in
that case, the unit should be B and not GB.

ld/
* ldlang.c (lang_print_memory_size) Print 0 B instead of 0 GB.
* testsuite/ld-scripts/print-memory-usage-1.l: Validate emplty region.
* testsuite/ld-scripts/print-memory-usage-1.t: Define empty region.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

PR31162, Memory Leak in ldwrite.c

This isn't a particularly worrying memory leak, but fix it anyway.

PR 31162
* ldwrite.c (build_link_order): Use bfd_alloc rather than xmalloc.
Add %E to error messages.

gdb/testsuite: another attempt to fix gdb.threads/thread-specific-bp.exp

The gdb.threads/thread-specific-bp.exp test has been a little
problematic, see commits:

  commit 89702edd933a5595557bcd9cc4a0dcc3262226d4
  Date:   Thu Mar 9 12:31:26 2023 +0100

      [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver

and

  commit 2e5843d87c4050bf1109921481fb29e1c470827f
  Date:   Fri Nov 19 14:33:39 2021 +0100

      [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp

But I recently saw a test failure for that test, which looked like
this:

  ...
  (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected
  continue -a
  Continuing.

  Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
  29      }
  (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited]
  Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
  FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout)
  ...

This only crops up (for me) when running on a loaded machine, and
still only occurs sometimes.  I've had to leave the test running in a
loop for 10+ minutes sometimes in order to see the failure.

The problem is that we use gdb_test_multiple to try and match two
patterns:

  (1) The 'Thread-specific breakpoint 3 deleted ....' message, and
  (2) The GDB prompt.

As written in the test, we understand that these patterns can occur in
any order, and we have a flag for each pattern.  Once both patterns
have been seen then we PASS the test.

The problem is that once expect has matched a pattern, everything up
to, and including the matched text is discarded from the input
buffer.  Thus, if the input buffer contains:

  <PATTERN 2><PATTERN 1>

Then expect will first try to match <PATTERN 1>, which succeeds, and
then expect discards the entire input buffer up to the end of the
<PATTERN 1>.  As a result, we will never spot <PATTERN 2>.

Obviously we can't just reorder the patterns within the
gdb_test_multiple, as the output can legitimately (and most often
does) occur in the other order, in which case the test would mostly
fail, and only occasionally pass!

I think the easiest solution here is just to have the
gdb_test_multiple contain two patterns, each pattern consists of the
two parts, but in the alternative orders, thus, for a particular
output configuration, only one regexp will match.  With this change in
place, I no longer see the intermittent failure.

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

LoongArch: Add call36 and tail36 pseudo instructions for medium code model

  For tail36, it is necessary to explicitly indicate the temporary register.
  Therefore, the compiler and users will know that the tail will use a register.

  call36 func
    pcalau18i $ra, %call36(func)
    jirl      $ra, $ra, 0;

  tail36 $t0, func
    pcalau18i $t0, %call36(func)
    jirl      $zero, $t0, 0;

LoongArch: Add new relocation R_LARCH_CALL36

R_LARCH_CALL36 is used for medium code model function call pcaddu18i+jirl, and
these two instructions must adjacent.

The LoongArch ABI v2.20 at here: https://github.com/loongson/la-abi-specs.

PR31177: Let region text start at __TEXT_REGION_ORIGIN___

The start of MEMORY region text currently starts hard-coded at 0.

The linker can produce more exact diagnostics when it knows the exact placements of the memory regions.

For some old devices, program memory starts at 0x8000, so allow to specify program memory start at __TEXT_REGION_ORIGIN__ similar to how the data region is described.

If ok, please apply to master.
This one is also fine to back-port.

Johann

--

AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text.

ld/
PR 31177
* scripttempl/avr.sc (__TEXT_REGION_ORIGIN__): New symbol.
(MEMORY): Use as start address for the text region.

Automatic date update in version.in

sim: warnings: add more flags

We already build cleanly with these.

Automatic date update in version.in

Use function entry point record only for entry values

PR28987 notes that optimized code sometimes shows the wrong
value of variables at the entry point of a function, if some
code was optimized away and the variable has multiple values
stored in the debug info for this location.

In this example:
```
void foo()
{
   int l_3 = 5, i = 0;
   for (; i < 8; i++)
       ;
   test(l_3, i);
}
```
When compiled with optimization, the entry point of foo is at
the test() function call, since everything else is optimized
away.
The debug info of i looks like this:
```
(gdb) info address i
Symbol "i" is multi-location:
  Base address 0x140001600  Range 0x13fd41600-0x13fd41600: the constant 0
  Range 0x13fd41600-0x13fd41600: the constant 1
  Range 0x13fd41600-0x13fd41600: the constant 2
  Range 0x13fd41600-0x13fd41600: the constant 3
  Range 0x13fd41600-0x13fd41600: the constant 4
  Range 0x13fd41600-0x13fd41600: the constant 5
  Range 0x13fd41600-0x13fd41600: the constant 6
  Range 0x13fd41600-0x13fd41600: the constant 7
  Range 0x13fd41600-0x13fd4160f: the constant 8
(gdb) p i
$1 = 0
```

Currently, when at the entry point of a function, it will
always show the initial value (here 0), while the user would
expect the last value (here 8).
This logic was introduced for showing the entry-values of
function arguments if they are available, but for some
reason this was added for non-entry-values as well.

One of the tests of amd64-entry-value.exp shows the same
problem for function arguments, if you "break stacktest"
in the following example, you stop at this line:
```
124     static void __attribute__((noinline, noclone))
125     stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1, int s2,
126                double d1, double d2, double d3, double d4, double d5, double d6,
127                double d7, double d8, double d9, double da)
128     {
129       s1 = 3;
130       s2 = 4;
131       d9 = 3.5;
132       da = 4.5;
133 ->    e (v, v);
134     asm ("breakhere_stacktest:");
135       e (v, v);
136     }
```
But `bt` still shows the entry values:
```
s1=s1@entry=11, s2=s2@entry=12, ..., d9=d9@entry=11.5, da=da@entry=12.5
```

I've fixed this by only using the initial values when
explicitely looking for entry values.

Now the local variable of the first example is as expected:
```
(gdb) p i
$1 = 8
```

And the test of amd64-entry-value.exp shows the expected
current and entry values of the function arguments:
```
s1=3, s1@entry=11, s2=4, s2@entry=12, ..., d9=3.5, d9@entry=11.5, da=4.5, da@entry=12.5
```

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28987
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

[gdb/build] Remove dependency on _rl_term_autowrap

Commit deb1ba4e38b ("[gdb/tui] Fix TUI resizing for TERM=ansi") introduced a
dependency on readline private variable _rl_term_autowrap.

There is precedent for this, but it's something we want to get rid of
(PR build/10723).

Remove the dependency on _rl_term_autowrap, and instead calculate
readline_hidden_cols by comparing the environment variable COLS with cols as
returned by rl_get_screen_size.

Tested on x86_64-linux.

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

[gdb/tui] Show regs when switching to regs layout

When starting gdb in CLI mode, running to main and switching into the TUI regs
layout:
...
$ gdb -q a.out -ex start -ex "layout regs"
...
we get:
...
+---------------------------------+
|                                 |
| [ Register Values Unavailable ] |
|                                 |
+---------------------------------+
...

Fix this by handling this case in tui_data_window::rerender.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR tui/28600
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600

[gdb/tui] Use more box_width in tui-regs.c

While experimenting with can_box () == false by default, I noticed two places
in tui-regs.c where we can replace a hardcoded 1 with box_width ().

It also turned out to be necessary to set scrollok to false, otherwise writing
the last char of the last line with register info will cause a scroll.

Tested on x86_64-linux.

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

sim: cr16: clean up unused insn operands

The push/pop insns only have 2 operands, so delete unused "c".

The pushret/popret insns use 2 operands, but they don't implement the
logic directly, they call the push/pop implementations.  So delete the
unused "a" & "b".

sim: sh: adjust some dsp insn masks

The pmuls encoding is incorrect -- it looks like a copy & paste error
from the padd pmuls variant.  The SuperH software manual covers this.

On the flip side, the manual lists pwsb & pwad as insns that exist,
but no description of what they do, what the insn name means, or the
actual encoding.  Our sim implementation stubs them both out as nops.
Let's mark the fields to avoid unused variable warnings.

sim: sh: tidy up gencode slightly

Mark a few things static/const, and clean up trailing whitespace.

sim: bfin: fix typo in bf52x ports

These should be using the BF52x set of ports, not BF51x.

sim: warnings: enable -Wunused-but-set-variable

sim: mn10300: fix incorrect implementation of a few insns

Fix a few problems caught by compiler warnings:
* Some of the asr & lsr insns were setting up the c state flag,
  but then forgetting to set it in the PSW.  Add it like the other
  asr & lsr variants.
* Some of the dmulh insns were multiplying one of the source regs
  against itself instead of against the other source reg.
* The sat16_cmp parallel insn was using the wrong register in the
  compare -- the reg1 src/dst pair are used in the sat16 op, and
  the reg2 src/dst pair are used in the add op.

Automatic date update in version.in

Refine Ada overload matching

Currently, the overload handling in Ada assumes that any two array
types are compatible.  However, this is obviously untrue, and a user
reported an oddity where comparing two Ada strings resulted in a call
to the "=" function for packed boolean arrays.

This patch improves the situation somewhat, by requiring that the two
arrays have the same arity and compatible base element types.  This is
still over-broad, but it seems safe and is better than the status quo.

Boolify ada_type_match

This changes ada_type_match to return bool.

Fix segmentation fault in bfd/elf32-hppa.c

2023-12-15  John David Anglin  <danglin@gcc.gnu.org>

PR ld/31148

bfd/ChangeLog:

* elf32-hppa.c (elf32_hppa_finish_dynamic_symbol): Output
relative reloc only when eh->root.type is bfd_link_hash_defined
or bfd_link_hash_defweak.

arm: reformat -march option section in gas documentation

Hi,

This patch contains a reformatting of -march option section in gas documentation.

For instance (see https://sourceware.org/binutils/docs-2.41/as.html#ARM-Options),
before all the options were on one line:
   For armv8-a:
   +crc: Enables CRC32 Extension. +simd: Enables VFP and NEON for Armv8-A. +crypto: Enables
   Cryptography Extensions for Armv8-A, implies +simd. +sb: Enables Speculation Barrier
   Instruction for Armv8-A. +predres: Enables Execution and Data Prediction Restriction
   Instruction for Armv8-A. +nofp: Disables all FPU, NEON and Cryptography Extensions.
   +nocrypto: Disables Cryptography Extensions.

Now, the readability is improved thanks to the itemization of the options:
   For armv8-a:
    +crc: Enables CRC32 Extension.
    +simd: Enables VFP and NEON for Armv8-A.
    +crypto: Enables Cryptography Extensions for Armv8-A, implies +simd.
    +sb: Enables Speculation Barrier Instruction for Armv8-A.
    +predres: Enables Execution and Data Prediction Restriction Instruction for Armv8-A.
    +nofp: Disables all FPU, NEON and Cryptography Extensions.
    +nocrypto: Disables Cryptography Extensions.

Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.

Regards,
Matthieu.

aarch64: Enable Cortex-X3 CPU

Hi,

This patch adds support for the Cortex-X3 CPU to binutils.

Gas regression testing for aarch64-none-linux-gnu target and found no regressions.

Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.

Regards,

Matthieu.

arm: document -march=armv9.[123]-a binutils options

x86: last-insn recording should be per-subsection

Otherwise intermediate subsection switches result in inconsistent
behavior. Leverage ELF's section change hook to switch state as
necessary, limiting overhead to the bare minimum when subsections aren't
used.

ELF: reliably invoke md_elf_section_change_hook()

... after any (sub)section change. While certain existing target hooks
only look at now_seg, for a few others it looks as if failing to do so
could have caused anomalies if sub-sections were used. In any event a
subsequent x86 change is going to require the sub-section to be properly
in place at the time the hook is invoked.

This primarily means for obj_elf_section() to pass the new subsection
into change_section(), for it to be set right away (ahead of invoking
the hook).

Also adjust obj_elf_ident() to invoke the hook after all section
changes. (Note that obj_elf_version(), which also changes sections and
then changes them back, has no hook invocation at all so far, so none
are added. Presumably there is a reason for this difference in
behavior.)

ELF: drop "push" parameter from obj_elf_change_section()

No caller outside of obj-elf.c cares about the parameter - drop it by
introducing an obj-elf.c-internal wrapper.

While adding the new function parameter, take the opportunity and change
the adjacent boolean one to "bool".

x86: don't needlessly override .bss

ELF, COFF, and Mach-O all have custom handlers for .bss. Don't override
those; install a handler only for a.out.

revert "x86: allow 32-bit reg to be used with U{RD,WR}MSR"

This reverts commit 1f865bae65db9588f6994c02a92355bfb4e3d955. The
specification is going to by updated in a way rendering this change
wrong.

x86: fold assembly dialect attributes

Now that ATTSyntax and ATTMnemonic aren't use in combination anymore,
fold them and IntelSyntax into a single, enum-like attribute. Note that
this shrinks i386_opcode_modifier back to 2 32-bit words (albeit that's
not for long, seeing in-flight additions for APX).

x86: Intel syntax implies Intel mnemonics

As noted in the context of d53e6b98a259 ("x86/Intel: correct disassembly
of fsub*/fdiv*") there's no such thing as Intel syntax without Intel
mnemonics. Enforce this on the assembler side, and disentangle command
line option handling on the disassembler side accordingly.

As a result in the opcode table specifying ATTMnemonic|ATTSyntax becomes
redundant with just ATTMnemonic. Drop the now meaningless ATTSyntax and
remove the then no longer accessible templates.

Arm64: fix build for certain gcc versions

Some complain (by default) about isalpha shadowing ctype.h's isalpha().
Some also complain about signed/unsigned comparison a few lines later.

Addendum to PR31124

This is a small addendum to PR31124 "rodata in flash for
more AVR devices".

It adds some symbols so the startup code can set a lock
on the FLMAP bit field as specified by the user.

New symbols are introduced because otherwise, all the
computations / decisions would have to be performed at
run-time.

It approved, please apply to master.

Johann

--

ld/
PR 31124
* scripttempl/avr.sc: Adjust comments.
[MAYBE_FLMAP]: Add symbols __flmap_value and __flmap_value_with_lock.
Remove __flmap_lsl4.

sim: m32r: fix mloop.in variant stamp deps

The migration to local.mk in commit 0a129eb19a773d930d60b084209570f663db2053
accidentally listed the deps for all mloop steps as mloop.in instead of the
various variants that m32r uses.

Reported-by: Simon Marchi <simon.marchi@polymtl.ca>

sim: m32r: use @cpu@_fill_argbuf_tp to set trace & profile state

The mloop.in code does this, but these variants do not.  Use it to
avoid unused function warnings.  The fast_p logic in these files
also looks off, but that'll require a bit more work to fixup.

  CC       m32r/mloopx.o
m32r/mloopx.c:37:1: error: ‘m32rxf_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
   37 | m32rxf_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
      | ^~~~~~~~~~~~~~~~~~~~~

  CC       m32r/mloop2.o
m32r/mloop2.c:37:1: error: ‘m32r2f_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
   37 | m32r2f_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
      | ^~~~~~~~~~~~~~~~~~~~~

Reported-by: Simon Marchi <simon.marchi@polymtl.ca>
Tested-By: Simon Marchi <simon.marchi@polymtl.ca>

sim: igen: do not reindent literal semantics output

When generating semantics.c from .igen source files, indenting the code
makes it more readable, but confuses compiler diagnostics.  The latter
is a bit more important than the former, so bias towards that.

For example, with an introduced error, we can see w/gcc-13:

(before this change)
  CC       mn10300/semantics.o
../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
../../../sim/mn10300/am33-2.igen:11:5: error: ‘srcreg’ undeclared (first use in this function)
   11 |   srcreg = translate_rreg (SD_, RN2);
      |     ^~~~~~

(with this change)
  CC       mn10300/semantics.o
../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
../../../sim/mn10300/am33-2.igen:11:3: error: ‘srcreg’ undeclared (first use in this function)
   11 |   srcreg = translate_rreg (SD_, RN2);
      |   ^~~~~~

regen ld POTFILES

PR31145, potential memory leak in binutils/ld

PR 31145
* bfd.c (BFD_IN_MEMORY): Mention that bim is malloc'd.
* format.c (io_reinit): Free BFD_IN_MEMORY iostream.
* opncls.c (_bfd_delete_bfd): Likewise.
(bfd_make_readable): Delete unnecessary code.
* bfd-in2.h: Regenerate.

Re: readelf..debug-dump=loc displays bogus base addresses

Commit b05efa39b479 removed checks I added in commit f22f27f46c75 to
prevent segfaults when debug_info_p is NULL, which can be the case
with fuzzed objects.  Restore those checks.  Also, for dwo look at
rnglists_dwo rather than rnglists.

RISC-V: Imply 'Zicntr' and 'Zihpm' implicitly depended on 'Zicsr'

This commit adds support for ratified extensions:
'Zicntr' and 'Zihpm', Which are all implicitly depend on 'Zicsr'.

This is based on:
<https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf>

bfd/ChangeLog:

* elfxx-riscv.c:  Add 'Zicntr' and 'Zihpm' -> 'Zicsr'.
        (riscv_supported_std_z_ext) Add 'Zicntr' and 'Zihpm' to the list.

Automatic date update in version.in

gprofng: fix -Wuse-after-free warning

Removed incorrect unnecessary code.

gprofng/ChangeLog
2023-12-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/collctrl.cc (set_synctrace): Fix -Wuse-after-free warning.

gdb/options: fix copy&paste error in string_option_def

Spotted what appears to be a copy&paste error in string_option_def,
the code for string handling writes the address fetching callback
function into the option_def::var_address::enumeration location,
rather than option_def::var_address::string.

Of course, this works just fine as option_def::var_address is a union,
and all of its members are function pointers, so they're going to be
the same size on every target GDB cares about.

But it doesn't hurt to be correct, so fixed in this commit.

There should be no user visible changes after this commit.

gdb/testsuite: add tests for unwinding of pseudo registers

This patch adds tests to exercise the previous patches' changes.

All three tests:

 - aarch64-pseudo-unwind
 - amd64-pseudo-unwind
 - arm-pseudo-unwind

follow the same pattern, just with different registers.

The other test, arm-pseudo-unwind-legacy, tests the special case where
the unwind information contains an entry for a register considered a
pseudo-register by GDB.

Change-Id: Ic29ac040c5eb087b4a0d79f9d02f65b7979df30f
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-by: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)
Tested-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)

gdb: migrate arm to new gdbarch_pseudo_register_write

Make arm use the new gdbarch_pseudo_register_write.  This fixes writing
pseudo registers to non-current frames for that architecture.

Change-Id: Icb2a649ab6394817844230e9e94c3d0564d2f765
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-by: Luis Machado <luis.machado@arm.com>

gdb: migrate arm to gdbarch_pseudo_register_read_value

Make arm use the "newer" gdbarch_pseudo_register_read_value.  This fixes
reading pseudo registers in non-current frames on that architecture.

Change-Id: Ic4d3d5d96957a4addfa3443c7b567dc4a31794a9
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-by: Luis Machado <luis.machado@arm.com>

gdb: migrate aarch64 to new gdbarch_pseudo_register_write

Make aarch64 use the new gdbarch_pseudo_register_write.  This fixes
writing pseudo registers to non-current frames on this architecture.

Change-Id: Ic012a0b95ae728d45a7121f77a79d604c23a849e
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>

gdb: add missing raw register read in aarch64_sme_pseudo_register_write

It seems like the intention here is to read the contents of the ZA
register and only write part of it.  However, there's no actual read of
the ZA register, so it looks like we'll write uninitialized bytes to the
target, for the portion of the raw register where we don't write the
pseudo register.  Add a call to raw_read to fix this.

I don't know how to test this though.

Change-Id: I7548240bd4324f6a3b729a1ebf7502fae5a46e9e
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-by: Luis Machado <luis.machado@arm.com>

gdb: make aarch64_za_offsets_from_regnum return za_offsets

This is not necessary, but it seems more natural to me to make
aarch64_za_offsets_from_regnum return a za_offsets object, rather than
fill an instance passed by parameter.

Change-Id: I40a185f055727da887ce7774be193eef1f4b9147
Approved-by: Luis Machado <luis.machado@arm.com>
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: migrate i386 and amd64 to the new gdbarch_pseudo_register_write

Make i386 and amd64 use the new gdbarch_pseudo_register_write.  This
fixes writing to pseudo registers in non-current frames for those
architectures.

Change-Id: I4977e8fe12d2cef116f8834c34cdf6fec618554f
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: add gdbarch_pseudo_register_write that takes a frame

Add a new variant of gdbarch_pseudo_register_write that takes a
frame_info in order to write raw registers.  Use this new method when
available:

 - in put_frame_register, when trying to write a pseudo register to a given frame
 - in regcache::cooked_write

No implementation is migrated to use this new method (that will come in
subsequent patches), so no behavior change is expected here.

The objective is to fix writing pseudo registers to non-current
frames.  See previous commit "gdb: read pseudo register through
frame" for a more detailed explanation.

Change-Id: Ie7fe364a15a4d86c2ecb09de2b4baa08c45555ac
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: rename gdbarch_pseudo_register_write to gdbarch_deprecated_pseudo_register_write

The next patch introduces a new variant of gdbarch_pseudo_register_write
that takes a frame instead of a regcache for implementations to write
raw registers.  Rename to old one to make it clear it's deprecated.

Change-Id: If8872c89c6f8a1edfcab983eb064248fd5ff3115
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: change parameter name in frame_unwind_register_unsigned declaration

For consistency with the declarations around.

Change-Id: I398266a61eae6e93fb7e306923009da9dd7f8fc4
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: read pseudo register through frame

Change gdbarch_pseudo_register_read_value to take a frame instead of a
regcache.  The frame (and formerly the regcache) is used to read raw
registers needed to make up the pseudo register value.  The problem with
using the regcache is that it always provides raw register values for
the current frame (frame 0).

Let's say the user wants to read the ebx register on amd64.  ebx is a pseudo
register, obtained by reading the bottom half (bottom 4 bytes) of the
rbx register, which is a raw register.  If the currently selected frame
is frame 0, it works fine:

    (gdb) frame 0
    #0  break_here_asm () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:36
    36      in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
    (gdb) p/x $ebx
    $1 = 0x24252627
    (gdb) p/x $rbx
    $2 = 0x2021222324252627

But if the user is looking at another frame, and the raw register behind
the pseudo register has been saved at some point in the call stack, then
we get a wrong answer:

    (gdb) frame 1
    #1  0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56
    56      in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
    (gdb) p/x $ebx
    $3 = 0x24252627
    (gdb) p/x $rbx
    $4 = 0x1011121314151617

Here, the value of ebx was computed using the value of rbx in frame 0
(through the regcache), it should have been computed using the value of
rbx in frame 1.

In other to make this work properly, make the following changes:

 - Make dwarf2_frame_prev_register return nullptr if it doesn't know how
   to unwind a register and that register is a pseudo register.
   Previously, it returned `frame_unwind_got_register`, meaning, in our
   example, "the value of ebx in frame 1 is the same as the value of ebx
   in frame 0", which is obviously false.  Return nullptr as a way to
   say "I don't know".

 - In frame_unwind_register_value, when prev_register (for instance
   dwarf2_frame_prev_register) returns nullptr, and we are trying to
   read a pseudo register, try to get the register value through
   gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read.
   If using gdbarch_pseudo_register_read, the behavior is known to be
   broken.  Implementations should be migrated to use
   gdbarch_pseudo_register_read_value to fix that.

 - Change gdbarch_pseudo_register_read_value to take a frame_info
   instead of a regcache, update implementations (aarch64, amd64, i386).
   In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that
   uses a frame instead of a regcache.  The version using the regcache
   is still used by i386_pseudo_register_write.  It will get removed in
   a subsequent patch.

 - Add some helpers in value.{c,h} to implement the common cases of
   pseudo registers: taking part of a raw register and concatenating
   multiple raw registers.

 - Update readable_regcache::{cooked_read,cooked_read_value} to pass the
   current frame to gdbarch_pseudo_register_read_value.  Passing the
   current frame will give the same behavior as before: for frame 0, raw
   registers will be read from the current thread's regcache.

Notes:

 - I do not plan on changing gdbarch_pseudo_register_read to receive a
   frame instead of a regcache. That method is considered deprecated.
   Instead, we should be working on migrating implementations to use
   gdbarch_pseudo_register_read_value instead.

 - In frame_unwind_register_value, we still ask the unwinder to try to
   unwind pseudo register values.  It's apparently possible for the
   debug info to provide information about [1] pseudo registers, so we
   want to try that first, before falling back to computing them
   ourselves.

[1] https://inbox.sourceware.org/gdb-patches/20180528174715.A954AD804AD@oc3748833570.ibm.com/

Change-Id: Id6ef1c64e19090a183dec050e4034d8c2394e7ca
Reviewed-by: John Baldwin <jhb@FreeBSD.org>

gdb: add value::allocate_register

Add value::allocate_register, to facilitate allocating a value
representing a register in a given frame (or rather, in the given
frame's previous frame).  It will be used in a subsequent patch.  I
changed one relatively obvious spot that could use it, to at least
exercise the code path.

Change-Id: Icd4960f5e471a74b657bb3596c88d89679ef3772
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: make get_frame_register_bytes take the next frame

Similar to the previous patches, change get_frame_register_bytes to take
the "next frame" instead of "this frame".

Change-Id: Ie8f35042bfa6e93565fcefaee71b6b3903f0fe9f
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: make put_frame_register_bytes take the next frame

Similar to the previous patches, change put_frame_register_bytes to take
the "next frame" instead of "this frame".

Change-Id: I27bcb26573686d99b231230823cff8db6405a788
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: make put_frame_register take the next frame

Similar to the previous patches, change put_frame_register to take the
"next frame" instead of "this frame".

Change-Id: I062fd4663b8f54f0fc7bbf39c860b7341363821b
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: remove frame_register

I was going to change frame_register to take the "next frame", but I
realized that doing so would make it a useless wrapper around
frame_register_unwind.  So, just remove frame_register and replace uses
with frame_register_unwind.

Change-Id: I185868bc69f8e098124775d0550d069220a4678a
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: change value_of_register and value_of_register_lazy to take the next frame

Some functions related to the handling of registers in frames accept
"this frame", for which we want to read or write the register values,
while other functions accept "the next frame", which is the frame next
to that.  The later is needed because we sometimes need to read register
values for a frame that does not exist yet (usually when trying to
unwind that frame-to-be).

value_of_register and value_of_register_lazy both take "this frame",
even if what they ultimately want internally is "the next frame".  This
is annoying if you are in a spot that currently has "the next frame" and
need to call one of these functions (which happens later in this
series).  You need to get the previous frame only for those functions to
get the next frame again.  This is more manipulations, more chances of
mistake.

I propose to change these functions (and a few more functions in the
subsequent patches) to operate on "the next frame".  Things become a bit
less awkward when all these functions agree on which frame they take.

So, in this patch, change value_of_register_lazy and value_of_register
to take "the next frame" instead of "this frame".  This adds a lot of
get_next_frame_sentinel_okay, but if we convert the user registers API
to also use "the next frame" instead of "this frame", it will get simple
again.

Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: make put_frame_register take an array_view

Change put_frame_register to take an array_view instead of a raw
pointer.

Add an assertion to verify that the number of bytes we try to write
matches the length of the register.

Change-Id: Ib75a9c8a12b47e203097621643eaa2c1830591ae
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: fix bugs in {get,put}_frame_register_bytes

I found this only by inspection: the myaddr pointer in
{get,put}_frame_register_bytes is reset to `buffer.data ()` at each
iteration.  This means that we will always use the bytes at the
beginning of `buffer` to read or write to the registers, instead of
progressing in `buffer`.

Fix this by re-writing the functions to chip away the beginning of the
buffer array_view as we progress in reading or writing the data.

These bugs was introduced almost 3 years ago [1], and yet nobody
complained.  I'm wondering which architecture relies on that register
"overflow" behavior (reading or writing multiple consecutive registers
with one {get,put}_frame_register_bytes calls), and in which situation.
I find these functions a bit dangerous, if a caller mis-calculates
things, it could end up silently reading or writing to the next
register, even if it's not the intent.

If I could change it, I would prefer to have functions specifically made
for that ({get,put}_frame_register_bytes_consecutive or something like
that) and make {get,put}_frame_register_bytes only able to write within
a single register (which I presume represents most of the use cases of
the current {get,put}_frame_register_bytes).  If a caller mis-calculates
things and an overflow occurs while calling
{get,put}_frame_register_bytes, it would hit an assert.  The problem is
knowing which callers rely on the overflow behavior and which don't.

[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/bdec2917b1e94c7198ba39919f45060067952f43

Change-Id: I43bd4a9f7fa8419d388a2b20bdc57d652688ddf8
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: change regcache interface to use array_view

Change most of regcache (and base classes) to use array_view when
possible, instead of raw pointers.  By propagating the use of array_view
further, it enables having some runtime checks to make sure the what we
read from or write to regcaches has the expected length (such as the one
in the `copy(array_view, array_view)` function.  It also integrates well
when connecting with other APIs already using gdb::array_view.

Add some overloads of the methods using raw pointers to avoid having to
change all call sites at once (which is both a lot of work and risky).

I tried to do this change in small increments, but since many of these
functions use each other, it ended up simpler to do it in one shot than
having a lot of intermediary / transient changes.

This change extends into gdbserver as well, because there is some part
of the regcache interface that is shared.

Changing the reg_buffer_common interface to use array_view caused some
build failures in nat/aarch64-scalable-linux-ptrace.c.  That file
currently "takes advantage" of the fact that
reg_buffer_common::{raw_supply,raw_collect} operates on `void *`, which
IMO is dangerous.  It uses raw_supply/raw_collect directly on
uint64_t's, which I guess is fine because it is expected that native
code will have the same endianness as the debugged process.  To
accomodate that, add some overloads of raw_collect and raw_supply that
work on uint64_t.

This file also uses raw_collect and raw_supply on `char` pointers.
Change it to use `gdb_byte` pointers instead.  Add overloads of
raw_collect and raw_supply that work on `gdb_byte *` and make an
array_view on the fly using the register's size.  Those call sites could
be converted to use array_view with not much work, in which case these
overloads could be removed, but I didn't want to do it in this patch, to
avoid starting to dig in arch-specific code.

During development, I inadvertently changed reg_buffer::raw_compare's
behavior to not accept an offset equal to the register size.  This
behavior (effectively comparing 0 bytes, returning true) change was
caught by the AArch64 SME core tests.  Add a selftest to make sure that
this raw_compare behavior is preserved in the future.

Change-Id: I9005f04114543ddff738949e12d85a31855304c2
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: simplify conditions in regcache::{read,write,raw_collect,raw_supply}_part

Make a few simplifications in these functions.

1. When checking if we need to do nothing, if the length is 0, we don't
   need to do anything, regardless of the value of offset.  Remove the
   offset check.

2. When check if transferring the whole register, if the length is equal
   to the register size, then we transfer the whole register, no need to
   check the offset.  Remove the offset check.

3. In the gdb_asserts, it is unnecessary to check for:

     offset <= reg_size

   given that right after we check for:

     len >= 0 && offset + len <= reg_size

   If `offset + len` is <= reg_size and len is >= 0, then necessarily
   offset is <= reg_size.  Remove the `offset <= reg_size` check.

Change-Id: I30a73acdc7bf432c45a07f5f177224d1cdc298e8
Reviewed-By: John Baldwin <jhb@FreeBSD.org>