gdb: remove unnecessary declarations in target.c

I found that these local declarations were not needed, remove them.
Tested by rebuilding.

Change-Id: I8d4fd0839ee1063b91dc002216d683aee0d4be22

Have DAP handle non-Value results from 'children'

A pretty-printer's 'children' method may return values other than a
gdb.Value -- it may return any value that can be converted to a
gdb.Value.

I noticed that this case did not work for DAP.  This patch fixes the
problem.

Handle gdb.LazyString in DAP

Andry pointed out that the DAP code did not properly handle
gdb.LazyString results from a pretty-printer, yielding:

    TypeError: Object of type LazyString is not JSON serializable

This patch fixes the problem, partly with a small patch in varref.py,
but mainly by implementing tp_str for LazyString.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Fix register-setting response from DAP

Andry noticed that given a DAP setExpression request, where the
expression to set is a register, DAP will return the wrong value -- it
will return the old value, not the updated one.

This happens because gdb.Value.assign (which was recently added for
DAP) does not update the value.

In this patch, I chose to have the assign method update the Value
in-place.  It's also possible to have it return a new value, but this
didn't seem very useful to me.

Fix: GNU-ld: ARM: Issues when trying to set target output architecture

  PR 28910
  * elf32-arm.c (elf32_arm_merge_private_bfd_data): Do not set output flags if the input flags have not been set.

Fix: GNU-ld: ARM: Issues when trying to set target output architecture

  PR 28910
  * lexsup.c (ld_options): Require that the --architecture option is given exactly two dashes, so that it does not become confused with the -a option.

Add DAP scope cache

Andry Ogorodnik, a co-worker, noticed that multiple "scopes" requests
with the same frame would yield different variableReference values in
the response.

This patch adds a regression test for this, and adds a scope cache in
scopes.py, ensuring that multiple identical requests will get the same
response.

Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

[gdb/symtab] Work around PR gas/29517

When using glibc debuginfo generated with gas 2.39, we run into PR gas/29517:
...
$ gdb -q -batch a.out -ex start -ex "p (char *)strstr (\"haha\", \"ah\")"
Temporary breakpoint 1 at 0x40051b: file hello.c, line 6.

Temporary breakpoint 1, main () at hello.c:6
6   printf ("hello\n");
Invalid cast.
...
while without glibc debuginfo installed we get the expected result:
...
$n = 0x7ffff7daa1b1 "aha"
...
and likewise with glibc debuginfo generated with gas 2.40.

The strstr ifunc resolves to __strstr_sse2_unaligned.  The problem is that gas
generates dwarf that states that the return type is void:
...
<1><3e1e58>: Abbrev Number: 2 (DW_TAG_subprogram)
    <3e1e59>   DW_AT_name        : __strstr_sse2_unaligned
    <3e1e5d>   DW_AT_external    : 1
    <3e1e5e>   DW_AT_low_pc      : 0xbbd2e
    <3e1e66>   DW_AT_high_pc     : 0xbc1c3
...
while the return type should be a DW_TAG_unspecified_type, as is the case
with gas 2.40.

We can still use the workaround of casting to another function type for both
__strstr_sse2_unaligned:
...
(gdb) p ((char * (*) (const char *, const char *))__strstr_sse2_unaligned) \
  ("haha", "ah")
$n = 0x7ffff7daa211 "aha"
...
and strstr (which requires using *strstr to dereference the ifunc before we
cast):
...
gdb) p ((char * (*) (const char *, const char *))*strstr) ("haha", "ah")
$n = 0x7ffff7daa251 "aha"
...
but that's a bit cumbersome to use.

Work around this in the dwarf reader, such that we have instead:
...
(gdb) p (char *)strstr ("haha", "ah")
$n = 0x7ffff7daa1b1 "aha"
...

This also requires fixing producer_is_gcc to stop returning true for
producer "GNU AS 2.39.0".

Tested on x86_64-linux.

Approved-By: Andrew Burgess <aburgess@redhat.com>
PR symtab/30911
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30911

Only allow closure lookup by address if there are threads displaced-stepping

Since commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, we have an assertion in
displaced_step_buffers::copy_insn_closure_by_addr that makes sure a closure
is available whenever we have a match between the provided address argument and
the buffer address.

That is fine, but the report in PR30872 shows this assertion triggering when
it really shouldn't. After some investigation, here's what I found out.

The 32-bit Arm architecture is the only one that calls
gdbarch_displaced_step_copy_insn_closure_by_addr directly, and that's because
32-bit Arm needs to figure out the thumb state of the original instruction
that we displaced-stepped through the displaced-step buffer.

Before the assertion was put in place by commit
1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, there was the possibility of
getting nullptr back, which meant we were not doing a displaced-stepping
operation.

Now, with the assertion in place, this is running into issues.

It looks like displaced_step_buffers::copy_insn_closure_by_addr is
being used to return a couple different answers depending on the
state we're in:

1 - If we are actively displaced-stepping, then copy_insn_closure_by_addr
is supposed to return a valid closure for us, so we can determine the
thumb mode.

2 - If we are not actively displaced-stepping, then copy_insn_closure_by_addr
should return nullptr to signal that there isn't any displaced-step buffers
in use, because we don't have a valid closure (but we should always have
this).

Since the displaced-step buffers are always allocated, but not always used,
that means the buffers will always contain data. In particular, the buffer
addr field cannot be used to determine if the buffer is active or not.

For instance, we cannot set the buffer addr field to 0x0, as that can be a
valid PC in some cases.

My understanding is that the current_thread field should be a good candidate
to signal that a particular displaced-step buffer is active or not. If it is
nullptr, we have no threads using that buffer to displaced-step.  Otherwise,
it is an active buffer in use by a particular thread.

The following fix modifies the displaced_step_buffers::copy_insn_closure_by_addr
function so we only attempt to return a closure if the buffer has an assigned
current_thread and if the buffer address matches the address argument.

Alternatively, I think we could use a function to answer the question of
whether we're actively displaced-stepping (so we have an active buffer) or
not.

I've also added a testcase that exercises the problem. It should reproduce
reliably on Arm, as that is the only architecture that faces this problem
at the moment.

Regression-tested on Ubuntu 20.04. OK?

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30872
Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb: replace architecture_changed with new_architecture observer

This commit replaces the architecture_changed observer with a
new_architecture observer.

Currently the only user of the architecture_changed observer is the
Python code, which uses this observer to register the Python unwinder
with the architecture.

The problem is that the architecture_changed observer is triggered
from inferior::set_arch(), which only sees the inferior-wide gdbarch
value.  For targets that use thread-specific architectures, these
never trigger the architecture_changed observer, and so never have the
Python unwinder registered with them.

When it comes to unwinding GDB makes use of the frame's gdbarch, which
is based on the thread's regcache gdbarch, which is set in
get_thread_regcache to the value returned from
target_thread_architecture, which is not always the inferiors gdbarch
value, it might be a thread-specific gdbarch which has not passed
through inferior::set_arch().

The new_architecture observer will be triggered from
gdbarch_find_by_info, whenever a new gdbarch is created and
initialised.  As GDB caches and reuses gdbarch values, we should
expect to see each new architecture trigger the new_architecture
observer just once.

After this commit, targets that make use of thread-specific
architectures should be able to make use of Python unwinders.

As I don't have access to a machine that makes use of thread-specific
architectures right now, I asked Luis to confirm that an AArch64
target that uses SVE/SME can't use the Python unwinders in threads
that are using a thread-specific architectures, and he confirmed that
this is indeed the case, see this discussion:

  https://inbox.sourceware.org/gdb/87wmvsat8i.fsf@redhat.com

Tested-By: Lancelot Six <lancelot.six@amd.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

objcopy: Fix name of the field modified by pe_stack_reserve.

RISC-V: Add "lp64e" ABI support

Since RV32E and RV64E are now ratified, this commit prepares the ABI
support for LP64E (LP64 with reduced GPRs).

gas/ChangeLog:

* config/tc-riscv.c (riscv_set_abi_by_arch): Update the error
message.  (md_parse_option): Accept "lp64e".
* doc/c-riscv.texi: Update the documentation to allow "lp64e".
* testsuite/gas/riscv/mabi-fail-rv32e-lp64f.l:
Change error message.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.l: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64q.l: Likewise.

RISC-V: Remove RV64E conflict

Since RV32E *and* RV64E are ratified, RV64E is no longer invalid.

This commit removes a restriction that prevents making base ISA with
reduced GPRs with XLEN > 32.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_parse_check_conflicts): Remove RV64E
conflict since the ratified 'E' base ISAs include RV64E.

gas/ChangeLog:

* testsuite/gas/riscv/march-fail-base-02.d: Removed.
* testsuite/gas/riscv/march-fail-base-02.l: Removed.

Automatic date update in version.in

sim: add distclean dep for gnulib

opcodes: microblaze: Add new bit-field instructions

This patches adds new bsefi and bsifi instructions.
BSEFI- The instruction shall extract a bit field from a
register and place it right-adjusted in the destination register.
The other bits in the destination register shall be set to zero.
BSIFI- The instruction shall insert a right-adjusted bit field
from a register at another position in the destination register.
The rest of the bits in the destination register shall be unchanged.

Further documentation of these instructions can be found here:
https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref

With version 6 of the patch, no new relocation types are added as
this was unnecessary for adding the bsefi and bsifi instructions.

FIXED: Segfault caused by incorrect termination of microblaze_opcodes.

Signed-off-by: nagaraju <nagaraju.mekala@amd.com>
Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@amd.com>
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>

sim: mips: fix printf string

Automatic date update in version.in

Automatic date update in version.in

[aarch64] Use SVE_VQ_BYTES instead of __SVE_VQ_BYTES

__SVE_VQ_BYTES is only available if SVE definitions are available in
the system's headers, and this is not true for all systems.

For this purpose, we define SVE_VQ_BYTES.  This patch fixes the
name of the constant being used.

ld: replace wrong bfd_malloc in nto.em

xmalloc should be called in ld instead of bfd_malloc.

ld/ChangeLog:

* emultempl/nto.em (nto_lookup_QNX_note_section): Replace
bfd_malloc by xmalloc.

ld: warn when duplicated QNX stack note are detected

This warning is triggered only when a stack parameter is given to
the linker.

ld/ChangeLog:

        * emultempl/nto.em: Add warning when several QNX .note are
        detected.

ld: correctly handle QNX --lazy-stack without -zstack-size

The warning was skipped if -zstack-size is not provided.

ld/ChangeLog:

        * emultempl/nto.em: Move --lazy-stack warning before missing
        -zstack-size skip.

ld: allow update of existing QNX stack note

Up to now, the linker would always create a QNX stack note from scratch.
However, object files could already have such note, ending up into
duplicates. QNX loader doesn't handle that.

Update the mechanism to first search through the input files for a .note
section holding a QNX stack note. If none are found, then a new section
is created into the stub file as before. This requires this search to be
done once the file have been opened, moving the whole logic a bit later
in the emulation process.

As part for this update, also allow to request an executable stack
without necessarily having to provide its size as well.  In this case, s
etup a default lazy stack of 0x1000.

ld/ChangeLog:

        * emultempl/nto.em (nto_create_QNX_note_section): New Function.
        (nto_lookup_QNX_note_section): New Function.
        (nto_add_note_section): Move the creation of the note section
        in the above new functions.
        (nto_create_output_section_statements): rename nto_after_open
        * testsuite/ld-aarch64/aarch64-nto.exp: add new test.
        * testsuite/ld-aarch64/nto-stack-note-3.d: New test.
        * testsuite/ld-aarch64/nto-stack-note.s: New test.

RISC-V: Add support for numbered ISA mapping strings

The elf psabi allows for mapping symbols to be of the form $x<ISA>.<any>

opcodes/
* riscv-dis.c (riscv_get_map_state): allow mapping symbol to
be suffixed by a unique identifier .<any>

Move -lsocket check to common.m4

A user pointed out that the -lsocket check in gdb should also apply to
gdbserver -- otherwise it can't find the Solaris socketpair.  This
patch makes the change.  It also removes a couple of redundant
function checks from gdb's configure.ac.

This was tested by the person who reported the bug.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927
Approved-By: Pedro Alves <pedro@palves.net>

Automatic date update in version.in

Fix test suite failure in file-then-restart.exp

Simon pointed out that the new file-then-restart.exp test fails with
the extended-remote target board.

The problem is that the test suite doesn't use gdb_file_cmd -- which
handles things like "set remote exec-file".  This patch changes
gdb_file_cmd to make the "kill" command optional, and then switches
the test case to use it.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933
Approved-By: Simon Marchi <simon.marchi@efficios.com>

bfd: add new bfd_cache_size() function

In GDB we have a problem with the BFD cache.

As GDB runs for a potentially extended period of time, if the BFD
cache holds a file descriptor for an open on-disk file, this can, on
some targets (e.g. Win32) prevent the OS writing to the file.

This might, for example, prevent a user from recompiling their
executable as GDB is (via the BFD cache) holding an open reference to
that file.

Another problem, relates to bfd_stat, for BFDs that are using the BFD
cache (i.e. they call cache_bstat to implement bfd_stat).  The
cache_bstat function finds the BFD in the cache, opening the file if
needed, and then uses fstat on the open file descriptor.

What this means is that, if the on-disk file changes, but the cache
was holding an open reference to the file, the bfd_stat will return
the 'struct stat' for the old file, not the new file.

Now, for this second problem, we might be tempted to make use of an
actual stat call, instead of calling bfd_stat, however, this isn't
ideal as we have some BFDs that use a custom iovec, and implement the
various functions over GDB's remote protocol.  By using bfd_stat we
can have a single call that should work for both local files, and for
remote files.

To solve both of these problems GDB has calls to bfd_cache_close_all
sprinkled around its code base.  And in theory this should work fine.

However, I recently ran into a case where we had missed a
bfd_cache_close_all call, and as a result some BFDs were held open.
This caused a bfd_stat call to return an unexpected result (old file
vs new file).

What I'd like is some way within GDB that I can do:

  gdb_assert ( /* Nothing is held open in the cache.  */ );

As this would allow GDB to quickly identify when we've missed some
bfd_cache_close_all calls.

And so, to support this, I would like to add a new bfd_cache_size
function.  This function returns an integer, which is the number of
open files in the cache.  I can then start adding:

  gdb_assert (bfd_cache_size() == 0);

to GDB in some strategic spots, and start fixing all of the missing
bfd_cache_close_all calls that crop up as a result.

bfd/cache: change type used to track cached BFDs from int to unsigned

Within bfd/cache.c change the type for max_open_files and open_files
variables from int to unsigned.  As a consequence of this, the return
type for bfd_cache_max_open() is also changed from int to unsigned.

Within bfd_cache_max_open I've left the local 'max' variable as an
int, this should ensure that if the sysconf call fails, and returns
-1, then the computed max value will be less than 10, which means
max_open_files will be set to 10.  If 'max' was changed to unsigned
then, should the sysconf call fail, we'd end up with max becoming a
very large positive number ... which is clearly not what we want.

And, while I was auditing how open_files is used, I added an assert
within bfd_cache_delete to ensure that we don't try to reduce
open_files below zero.

There should be no user visible change with this commit.

Automatic date update in version.in

[RFA] Fix for mcore simulator

I was looking for cases where a GCC patch under evaluation would cause test
results to change.  Quite surprisingly the mcore-elf port showed test
differences.   After a fair amount of digging my conclusion was the sequences
before/after the patch should have been semantically the same.

Of course if the code is supposed to behave the same, then that points to
problems elsewhere (assembler, linker, simulator).  Sure enough the mcore
simulator was mis-handling the sign extension instructions.  The simulator
implementation of sextb is via paired shift-by-24 operations. Similarly the
simulator implements sexth via paired shift-by-16 operations.

The temporary holding the value was declared as a "long" thus this approach
worked fine for hosts with a 32 bit wide long and failed miserably for hosts
with a 64 bit wide long.

This patch makes the shift count automatically adjust based on the size of the
temporary.  It includes a simple test for sextb and sexth.  I have _not_ done a
full audit of the mcore simulator for more 32->64 bit issues.

This also fixes 443 execution tests in the GCC testsuite

gprofng: Use the correct application name in error messages

The old application name (er_archive) is used in many places.

gprofng/ChangeLog
2023-10-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/Experiment.cc: Replace er_archive with gp-archive.
* src/Experiment.cc: Likewise.

Automatic date update in version.in

gdb: LoongArch: Handle special struct in dummy call

When execute the following command on LoongArch:

  make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"

there exist some failed testcases:

  === gdb Summary ===

  # of expected passes 5533
  # of unexpected failures 367

The root cause is related with a struct containing floating-point
members as function argument or return value for a dummy call.

(1) Structure consists of one floating-point member within FRLEN bits
    wide, it is passed in an FAR if available.
(2) Structure consists of two floating-point members both within FRLEN
    bits wide, it is passed in two FARs if available.
(3) Structure consists of one integer member within GRLEN bits wide and
    one floating-point member within FRLEN bits wide, it is passed in a
    GAR and an FAR if available.

Note that in the above cases, empty structure or union members are also
ignored even in C++.

Here is a simple test on LoongArch:

  loongson@bogon:~$ cat test.c

  #include<stdio.h>

  struct test {
  long   a;
  double b __attribute__((aligned(16)));
  };
  struct test val = { 88, 99.99 };
  int check_arg_struct (struct test arg)
    {
      printf("arg.a = %ld\n", arg.a);
      printf("arg.b = %f\n", arg.b);
      printf("sizeof(val) = %d\n", sizeof(val));
      return 1;
    }
  int main()
  {
     check_arg_struct (val);
     return 0;
  }
  loongson@bogon:~$ gcc -g test.c -o test
  loongson@bogon:~$ ./test
  arg.a = 88
  arg.b = 99.990000
  sizeof(val) = 32

Before:

loongson@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:19
19    check_arg_struct (val);
(gdb) p check_arg_struct (val)
arg.a = 140737488286128
arg.b = -nan
sizeof(val) = 32
$1 = 1
...

After:

loongson@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:19
19    check_arg_struct (val);
(gdb) p check_arg_struct (val)
arg.a = 88
arg.b = 99.990000
sizeof(val) = 32
$1 = 1
...

With this patch, there are no failed testcases:

  make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"

   === gdb Summary ===

   # of expected passes 5900

Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: add assertion when marking the remote async flag

As reported in bug 30630 [1], we hit a case where the remote target's
async flag is marked while the target is not configured (yet) to work
async.  This should not happen.  It is caught thanks to this assert in
remote_target::wait:

    /* Start by clearing the flag that asks for our wait method to be called,
       we'll mark it again at the end if needed.  If the target is not in
       async mode then the async token should not be marked.  */
    if (target_is_async_p ())
      rs->clear_async_event_handler ();
    else
      gdb_assert (!rs->async_event_handler_marked ());

This is helpful, but I think that we could have caught the problem earlier than
that, at the moment we marked the handler.  Catching problems earlier
makes them easier to debug.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30630

Change-Id: I7e229c74b04da82bef6a817d5a676be5cf52e833
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: add remote_state::{is_async_p,can_async_p}

A subsequent patch will want to know if the remote is async within a
remote_state method.  Add a helper method for that, and for "can async"
as well, for symmetry.

Change-Id: Id0f648ee4896736479fa942f5453eeeb0e5d4352
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: make remote_state's async token private

Make remote_async_inferior_event_token private (rename to
m_async_event_handler_token) and add methods for the various operations
we do on it.  This will help by:

 - allowing to break on those methods when debugging
 - allowing to add assertions in the methods

Change-Id: Ia3b8a2bc48ad4849dbbe83442c3f83920f03334d
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: remove trailing whitespaces in remote.c

Change-Id: I88d136b6b5a0a54d1c8a9f8a0068762a5456a29a

gdb: scope down registers_changed call in inferior::set_arch

inferior::set_arch calls registers_changed, which invalidates all
regcaches.  It would be enough to invalidate only regcaches of threads
belonging to this inferior.  Call registers_changed_ptid instead, with
the proper process target / ptid.  If the inferior does not have a
process target, there should be no regcaches for that inferior, so no
need to invalidate anything.

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

gdb: remove target_gdbarch

This function is just a wrapper around the current inferior's gdbarch.
I find that having that wrapper just obscures where the arch is coming
from, and that it's often used as "I don't know which arch to use so
I'll use this magical target_gdbarch function that gets me an arch" when
the arch should in fact come from something in the context (a thread,
objfile, symbol, etc).  I think that removing it and inlining
`current_inferior ()->arch ()` everywhere will make it a bit clearer
where that arch comes from and will trigger people into reflecting
whether this is the right place to get the arch or not.

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

gdb: move set_target_gdbarch to inferior::set_arch

set_target_gdbarch is basically a setter for the current inferior's
arch, that notifies other parts of GDB of the architecture change.  Move
the code of set_target_gdbarch to the inferior::set_arch method.

Add gdbarch_initialized_p, so we can keep the assertion.

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

gdb: add inferior parameter to architecture_changed observable

This is to make it explicit which inferior's architecture just changed,
and that the callbacks should not assume it is the current inferior.

Update the only caller, pyuw_on_new_gdbarch, to add the parameter,
although it doesn't use it currently.

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

gdb: add inferior::{arch, set_arch}

Make the inferior's gdbarch field private, and add getters and setters.
This helped me by allowing putting breakpoints on set_arch to know when
the inferior's arch was set.  A subsequent patch in this series also
adds more things in set_arch.

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

asan: buffer overflow in elf32_arm_get_synthetic_symtab

Guard against fuzzed files where .plt size isn't commensurate with
plt relocations.

* elf32-arm.c (elf32_arm_plt0_size): Add data_size param.
Return -1 if data_size is too small.
(elf32_arm_plt_size): Likewise.  Delete temp var.  Formatting.
(elf32_arm_get_synthetic_symtab): Adjust to suit.

asan: null dereference in read_and_display_attr_value

This fixes multiple places in read_and_display_attr_value dealing with
range and location lists that can segfault when debug_info_p is NULL.
Fuzzed object files can contain arbitrary DW_FORMs.

* dwarf.c (read_and_display_attr_value): Don't dereference NULL
debug_info_p.

asan: invalid free in bfd_init_section_compress_status

With specially crafted compressed sections, it's possible to tickle a
problem when decompressing:  If the compression headers says the
uncompressed size is zero, this will be seen as an error return from
bfd_compress_section_contents.  On errors the caller should free any
malloc'd input buffers, but this isn't really an error and the section
contents have been updated to a bfd_alloc'd buffer which can't be
freed.

* compress.c (bfd_compress_section_contents): Return -1 as error
rather than 0.
(bfd_init_section_compress_status, bfd_compress_section): Adjust.

gdb/python: implement support for sending custom MI async notifications

This commit adds a new Python function, gdb.notify_mi, that can be used
to emit custom async notification to MI channel.  This can be used, among
other things, to implement notifications about events MI does not support,
such as remote connection closed or register change.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb/python: generalize serialize_mi_result()

This commit generalizes serialize_mi_result() to make usable in
different contexts than printing result of custom MI command.

To do so, the check whether passed Python object is a dictionary has been
moved to the caller - at the very least, different uses require different
error messages.  Also it has been renamed to serialize_mi_results() to better
match GDB/MI output syntax (see corresponding section in documentation,
in particular rules 'result-record' and 'async-output'.

Since it is now more generic function, it has been moved to py-mi.c.

This is a preparation for implementing Python support for sending custom
MI async events.

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

LoongArch/GAS: Add support for branch relaxation

For the instructions of R_LARCH_B16/B21, if the immediate overflow,
add a B instruction and R_LARCH_B26 relocation.

For example:

.L1
  ...
  blt $t0, $t1, .L1
    R_LARCH_B16

change to:

.L1
  ...
  bge $t0, $t1, .L2
  b .L1
    R_LARCH_B26
.L2

[readelf] Handle .gdb_index section version 9

Add the abilitity to print a v9 .gdb_index section.

The v9 section contains an extra table, which is printed as follows:
...
Shortcut table:
Language of main: Fortran 95
Name of main: contains_keyword
...

[ For the example, I used the exec of gdb test-case
gdb.fortran/nested-funcs-2-exp when running the test-case with target board
cc-with-gdb-index. ]

Tested on x86_64-linux.

Approved-By: Nick Clifton <nickc@redhat.com>

[gdb/symtab] Add name_of_main and language_of_main to the DWARF index

This patch adds a new section to the DWARF index containing the name
and the language of the main function symbol, gathered from
`cooked_index::get_main`, if available. Currently, for lack of a better name,
this section is called the "shortcut table". The way this name is both saved and
applied upon an index being loaded in mirrors how it is done in
`cooked_index_functions`, more specifically, the full name of the main function
symbol is saved and `set_objfile_main_name` is used to apply it after it is
loaded.

The main use case for this patch is in improving startup times when dealing with
large binaries. Currently, when an index is used, GDB has to expand symtabs
until it finds out what the language of the main function symbol is. For some
large executables, this may take a considerable amount of time to complete,
slowing down startup. This patch bypasses that operation by having both the name
and language of the main function symbol be provided ahead of time by the index.

In my testing (a binary with about 1.8GB worth of DWARF data) this change brings
startup time down from about 34 seconds to about 1.5 seconds.

When testing the patch with target board cc-with-gdb-index, test-case
gdb.fortran/nested-funcs-2.exp starts failing, but this is due to a
pre-existing issue, filed as PR symtab/30946.

Tested on x86_64-linux, with target board unix and cc-with-gdb-index.

PR symtab/24549
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549

Approved-By: Tom de Vries <tdevries@suse.de>

Automatic date update in version.in

gdb_unique_ptr.h: Fix a typo in a comment

Fix: Null pointer dereference in ldlex.l

  PR 30951
  * ldlex.l (yy_input): Check for YY_CURRENT_BUFFER being NULL.

Fix: A potential null_pointer_deference bug

  PR 30954
  * ldlang.c (map_input_to_output_sections): Check that os is non NULL before using it.

Fix: Null pointer dereference in elf32-i386.c

  PR 30950
  * elf32-i386.c (elf_i386_convert_load_reloc): Check for elf_x86_hash_table returning a NULL pointer.

Fix: A potential bug of null pointer dereference

  PR 30949
  * elflink.c (elf_gc_mark_debug_section): Check for bfd_section_from_elf_index returning a NULL pointer.

gdb/testsuite: match complete lines in gdb.base/maint.exp

This thread:

  https://inbox.sourceware.org/gdb-patches/20231003195338.334948-1-thiago.bauermann@linaro.org/

pointed out that within gdb.base/maint.exp, some regexps within a
gdb_test_multiple were failing to match a complete line, while later
regexps within the gdb_test_multiple made use of the '^' anchor, and
so assumed that earlier lines had been completely matched and removed
from expect's buffer.

When testing with READ1 set this assumption was failing.

Fix this by extending the offending patterns with a trailing '\r\n'.

Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

Automatic date update in version.in

Update gdb/NEWS after GDB 14 branch creation.

This commit a new section for the next release branch, and renames
the section of the current branch, now that it has been cut.

Bump version to 15.0.50.DATE-git.

Now that the GDB 14 branch has been created,
this commit bumps the version number in gdb/version.in to
15.0.50.DATE-git

For the record, the GDB 14 branch was created
from commit 8f12a1a841cd0c447de7a5a0f134a0efece73588.

Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:

* gdb.base/default.exp: Change $_gdb_major to 15.

Add testsuits for new assembler option of mthin-add-sub.

as: add option for generate R_LARCH_32/64_PCREL.

Some older kernels cannot handle the newly generated R_LARCH_32/64_PCREL,
so the assembler generates R_LARCH_ADD32/64+R_LARCH_SUB32/64 by default,
and use the assembler option mthin-add-sub to generate R_LARCH_32/64_PCREL
as much as possible.

The Option of mthin-add-sub does not affect the generation of R_LARCH_32_PCREL
relocation in .eh_frame.

Automatic date update in version.in

Revert "opcodes: microblaze: Add new bit-field instructions"

This reverts commit 6bbf249557ba17cfebe01c67370df4da9e6a56f9.

Maciej W. Rozycki <macro@orcam.me.uk>:
 Yet it has caused numerous regressions:

microblaze-elf  +FAIL: unordered .debug_info references to .debug_ranges
microblaze-elf  +FAIL: binutils-all/pr26548
microblaze-elf  +FAIL: readelf -Wwi pr26548e (reason: unexpected output)
microblaze-elf  +FAIL: readelf --debug-dump=loc locview-1 (reason: unexpected output) Yet it has caused numerous regressions:
microblaze-elf  +FAIL: unordered .debug_info references to .debug_ranges
microblaze-elf  +FAIL: binutils-all/pr26548
microblaze-elf  +FAIL: readelf -Wwi pr26548e (reason: unexpected output)
...

[gdb/testsuite] Fix gdb.arch/i386-signal.exp on x86_64

On x86_64-linux, with test-case gdb.arch/i386-signal.exp I run into:
...
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector i386-signal.c \
  -fdiagnostics-color=never -fno-pie -g -no-pie -lm -o i386-signal^M
/tmp/cc2xydTG.s: Assembler messages:^M
/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M
compiler exited with status 1
output is:
/tmp/cc2xydTG.s: Assembler messages:^M
/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M

gdb compile failed, /tmp/cc2xydTG.s: Assembler messages:
/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'
UNTESTED: gdb.arch/i386-signal.exp: failed to compile
...

This is with gas 2.41, it compiles without problems with gas 2.40.  Some more
strict checking was added in commit 5cc007751cd ("x86: further adjust
extend-to-32bit-address conditions").  This may or may not be a gas regression
( https://sourceware.org/pipermail/binutils/2023-October/129818.html ).

The offending bit is:
...
    "    push $sigframe\n"
...
which refers to a function:
...
    "    .globl sigframe\n"
    "sigframe:\n"
...

The test-case passes with target board unix/-m32.

Make the test-case work by using pushq instead of push for the
is_amd64_regs_target case.

Tested on x86_64-linux, with target boards:
- unix/-m64 (is_amd64_regs_target == 1), and
- unix/-m32 (is_amd64_regs_target == 0),

PR testsuite/30928
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30928

gdb: support rseq auxvs

Linux kernel commit commit 317c8194e6ae ("rseq: Introduce feature size
and alignment ELF auxiliary vector entries") introduced two new auxvs:
AT_RSEQ_FEATURE_SIZE and AT_RSEQ_ALIGN.  Support them in GDB.  This
fixes auxv.exp on kernels >= v6.3.

Change-Id: I8966c4d5c73eb7b45de6d410a9b28a6628edad2e
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30540
Approved-By: Tom Tromey <tom@tromey.com>

gprofng: 30910 cross test fail: can't read "CHECK_TARGET": no such variable

When TCL_TRY is FALSE, the wrong check-DEJAGNU is generated.
Place "if TCL_TRY / endif" in the right place.

gprofng/ChangeLog
2023-10-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30910
* Makefile.am: Correct "if TCL_TRY / endif".
* Makefile.in: Rebuild.

Automatic date update in version.in

process-dies-while-detaching.exp: Exit early if GDB misses sync breakpoint

I'm seeing a lot of variability in the failures of
gdb.threads/process-dies-while-detaching.exp on aarch64-linux.  On this
platform, a problem yet to be investigated causes GDB to miss the _exit
breakpoint.  What happens next is random because after missing that
breakpoint, GDB is out of sync with the inferior.  This causes the tests
following that point in the testcase to fail in a random way.

In this scenario it's better to exit the testcase early to avoid random
results in the testsuite.

We are relying on gdb_continue_to_breakpoint to return the result of
gdb_test_multiple.  This is already the case because in Tcl the return
value of a function is the return value of the last command it runs.  But
change gdb_continue_to_breakpoint to explicitly return this value, to make
it clear this is the intended behaviour.

Tested on aarch64-linux.

Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

opcodes: microblaze: Add new bit-field instructions

This patches adds new bsefi and bsifi instructions.
BSEFI- The instruction shall extract a bit field from a
register and place it right-adjusted in the destination register.
The other bits in the destination register shall be set to zero.
BSIFI- The instruction shall insert a right-adjusted bit field
from a register at another position in the destination register.
The rest of the bits in the destination register shall be unchanged.

Further documentation of these instructions can be found here:
https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref

This patch has been tested for years of AMD Xilinx Yocto
releases as part of the following patch set:

https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils

Signed-off-by: nagaraju <nagaraju.mekala@amd.com>
Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@amd.com>
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>

gdb/NEWS: reorder some entries in the NEWS file

I spotted two entries in the NEWS file that I believe are in the wrong
place, these are:

  - An entry about MI v1 being deprecated, this feels like it should
    be the first entry under the 'MI changes' heading, and

  - An entry for the $_shell convenience function which is currently
    under the 'New commands' heading (sort of), when I think this
    should be listed in the general news section.

gdbserver: fix gdbserver builds after expedite_regs changes

After this commit:

  commit 6a65998a8a94abaaae7ca4ff0ab9c3f25dc2e766
  Date:   Mon Sep 11 12:42:00 2023 +0100

      Convert tdesc's expedite_regs to a string vector

The risc-v, loongarch, and csky gdbserver builds were broken.  A use
of target_desc::expedite_regs (for each architecture)  was not updated
to take account of the type change.

I've tested that this fixes the risc-v build.  I haven't tested the
other architectures, but they should be fine.

gdb/testsuite: cleanup in gdb.base/args.exp

The last few commits resolved the KFAILs in gdb.base/args.exp.  With
those out of the way we can clean up this test script a little.

In this commit I have:

  - Stopped passing 'nowarnings' flag when building the source file.
    I see no reason why this source should issue a warning,

  - Moved setup of GDBFLAGS into args_test proc, callers that passed a
    newline needed a small tweak, and also the matching code needs
    updating for newline handling, but I think this is nicer, the
    argument lists are now given just once,

  - Updated comment on args_test,

  - Updated other comments.

There should be no change in what is tested after this commit.

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

gdbserver: cleanup in handle_v_run

After the previous commit there is now a redundant string copy in
handle_v_run, this commit cleans that up.

There should be no functional change after this commit.

During review I was pointed to this older series:

  https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/

which also includes this fix as part of a larger set of changes.  I'm
giving a Co-Authored-By credit to the author of that original series.
I believe this smaller fix brings some benefits on its own, though the
original series does offer additional improvements.  Once this is
merged I'll take a look at rebasing and resubmitting the original series.

Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
Approved-By: Tom Tromey <tom@tromey.com>

gdbserver: handle newlines in inferior arguments

Similarly to how single quotes were mishandled, which was fixed two
commits ago, this commit fixes handling of newlines in arguments
passed to gdbserver.

We already had a test that covered this, gdb.base/args.exp, which,
when run with the native-extended-gdbserver board contained several
KFAIL covering this situation.

In this commit I remove the unnecessary, attempt to quote incoming
newlines within arguments, and do some minimal cleanup of the related
code.  There is additional cleanup that can be done, but I'm leaving
that for the next commit.

Then I've removed the KFAIL from the test case, and performed some
minimal cleanup there too.

After this commit the gdb.base/args.exp is 100% passing with the
native-extended-gdbserver board file.

During review I was pointed to this older series:

  https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/

which also includes this fix as part of a larger set of changes.  I'm
giving a Co-Authored-By credit to the author of that original series.
I believe this smaller fix brings some benefits on its own, though the
original series does offer additional improvements.  Once this is
merged I'll take a look at rebasing and resubmitting the original series.

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

Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
Approved-By: Tom Tromey <tom@tromey.com>

gdbserver: fix handling of trailing empty argument

When I posted the previous patch for review Andreas Schwab pointed out
that passing a trailing empty argument also doesn't work.

The fix for this is in the same area of code as the previous patch,
but is sufficiently different that I felt it deserved a patch of its
own.

I noticed that passing arguments containing single quotes to gdbserver
didn't work correctly:

  gdb -ex 'set sysroot' --args /tmp/show-args
  Reading symbols from /tmp/show-args...
  (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args
  Remote debugging using | gdbserver --once --multi - /tmp/show-args
  stdin/stdout redirected
  Process /tmp/show-args created; pid = 176054
  Remote debugging using stdio
  Reading symbols from /lib64/ld-linux-x86-64.so.2...
  (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
  (gdb) set args abc ""
  (gdb) run
  The program being debugged has been started already.
  Start it from the beginning? (y or n) y
  Starting program: /tmp/show-args \'
  stdin/stdout redirected
  Process /tmp/show-args created; pid = 176088
  2 args are:
    /tmp/show-args
    abc
  Done.
  [Inferior 1 (process 176088) exited normally]
  (gdb) target native
  Done.  Use the "run" command to start a process.
  (gdb) run
  Starting program: /tmp/show-args \'
  2 args are:
    /tmp/show-args
    abc

  Done.
  [Inferior 1 (process 176095) exited normally]
  (gdb) q

The 'shows-args' program used here just prints the arguments passed to
the inferior.

Notice that when starting the inferior using the extended-remote
target there is only a single argument 'abc', while when using the
native target there is a second argument, the blank line, representing
the empty argument.

The problem here is that the vRun packet coming from GDB looks like
this (I've removing the trailing checksum):

  $vRun;PROGRAM_NAME;616263;

If we compare this to a packet with only a single argument and no
trailing empty argument:

  $vRun;PROGRAM_NAME;616263

Notice the lack of the trailing ';' character here.

The problem is that gdbserver processes this string in a loop.  At
each point we maintain a pointer to the character just after a ';',
and then we process everything up to either the next ';' character, or
to the end of the string.

We break out of this loop when the character we start with (in that
loop iteration) is the null-character.  This means in the trailing
empty argument case, we abort the loop before doing anything with the
empty argument.

In this commit I've updated the loop, we now break out using a 'break'
statement at the end of the loop if the (sub-)string we just processed
was empty, with this change we now notice the trailing empty
argument.

I've updated the test case to cover this issue.

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

gdbserver: fix handling of single quote arguments

I noticed that passing arguments containing single quotes to gdbserver
didn't work correctly:

  gdb -ex 'set sysroot' --args /tmp/show-args
  Reading symbols from /tmp/show-args...
  (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args
  Remote debugging using | gdbserver --once --multi - /tmp/show-args
  stdin/stdout redirected
  Process /tmp/show-args created; pid = 176054
  Remote debugging using stdio
  Reading symbols from /lib64/ld-linux-x86-64.so.2...
  (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
  (gdb) set args \'
  (gdb) r
  The program being debugged has been started already.
  Start it from the beginning? (y or n) y
  Starting program: /tmp/show-args \'
  stdin/stdout redirected
  Process /tmp/show-args created; pid = 176088
  2 args are:
    /tmp/show-args
    \'
  Done.
  [Inferior 1 (process 176088) exited normally]
  (gdb) target native
  Done.  Use the "run" command to start a process.
  (gdb) run
  Starting program: /tmp/show-args \'
  2 args are:
    /tmp/show-args
    '
  Done.
  [Inferior 1 (process 176095) exited normally]
  (gdb) q

The 'shows-args' program used here just prints the arguments passed to
the inferior.

Notice that when starting the inferior using the extended-remote
target the second argument is "\'", while when running using native
target the argument is "'".  The second of these is correct, the \'
used with the "set args" command is just to show GDB that the single
quote is not opening an argument string.

It turns out that the extra backslash is injected on the gdbserver
side when gdbserver processes the arguments that GDB passes it, the
code that does this was added as part of this much larger commit:

  commit 2090129c36c7e582943b7d300968d19b46160d84
  Date:   Thu Dec 22 21:11:11 2016 -0500

      Share fork_inferior et al with gdbserver

In this commit I propose removing the specific code that adds what I
believe is a stray backslash.  I've extended an existing test to cover
this case, and I now see identical behaviour when using an
extended-remote target as with the native target.

This partially fixes PR gdb/27989, though there are still some issues
with newline handling which I'll address in a later commit.

During review I was pointed to this older series:

  https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/

which also includes this fix as part of a larger set of changes.  I'm
giving a Co-Authored-By credit to the author of that original series.
I believe this smaller fix brings some benefits on its own, though the
original series does offer additional improvements.  Once this is
merged I'll take a look at rebasing and resubmitting the original series.

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

Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
Approved-By: Tom Tromey <tom@tromey.com>

Fix: alpha: ld segfaults in

  PR 30940
  * elf64-alpha.c (elf64_alpha_check_relocs): Correct error message.

gdb/configure.ac: Add option --with-additional-debug-dirs

If you want to install GDB in a custom prefix, have it look for debug info
in that prefix but also in the distro's default location (typically,
/usr/lib/debug) and run the GDB testsuite before doing "make install", you
have a bit of a problem:

Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory'
parameter to $PREFIX/lib/debug.  Unfortunately this precludes GDB from
looking for distro-installed debug info in /usr/lib/debug.  For regular GDB
use you could set debug-file-directory to $PREFIX:/usr/lib/debug in
$PREFIX/etc/gdbinit so that GDB will look in both places, but if you want
to run the testsuite then that doesn't help because in that case GDB runs
with the '-nx' option.

There's the configure option '--with-separate-debug-dir' to set the default
value for 'debug-file-directory', but it accepts only one directory and not
a list.  I considered modifying it to accept a list, but it's not obvious
how to do that because its value is also used by BFD, as well as processed
for "relocatability".

I thought it was simpler to add a new option to specify a list of
additional directories that will be appended to the debug-file-directory
setting.

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

Automatic date update in version.in

[gdb/go] Handle v3 go_0 mangled prefix

With gcc-10 we have:
...
(gdb) break package2.Foo^M
Breakpoint 2 at 0x402563: file package2.go, line 5.^M
(gdb) PASS: gdb.go/package.exp: setting breakpoint 1
...
but with gcc-11:
...
gdb) break package2.Foo^M
Function "package2.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.go/package.exp: gdb_breakpoint: set breakpoint at package2.Foo
...

In the gcc-10 case, though the exec contains dwarf, it's not used to set the
breakpoint (which is an independent problem, filed as PR go/30941), instead
the minimal symbol information is used.

The minimal symbol information changed between gcc-10 and gcc-11:
...
$ nm a.out.10 | grep Foo
000000000040370d T go.package2.Foo
0000000000404e50 R go.package2.Foo..f
$ nm a.out.11 | grep Foo
0000000000403857 T go_0package2.Foo
0000000000405030 R go_0package2.Foo..f
...

A new v3 mangling scheme was used.  The mangling schemes define a separator
character and mangling character:
- for v2, dot is used both as separator character and mangling character, and
- for v3, dot is used as separator character and underscore as mangling
  character.

For more details, see [1] and [2].

In v3, "_0" demangles to ".". [ See gcc commit a01dda3c23b ("compiler, libgo:
change mangling scheme"), function Special_char_code::Special_char_code. ]

Handle the new go_0 prefix in unpack_mangled_go_symbol, which fixes the
test-case.

Note that this doesn't fix this regression:
...
$ gccgo-10 package2.go -c -g0
$ gccgo-10 package1.go package2.o -g0
$ gdb -q -batch a.out -ex "break go.package2.Foo"
Breakpoint 1 at 0x40370d
$ gccgo-11 package2.go -c -g0
$ gccgo-11 package1.go package2.o -g0
$ gdb -q -batch a.out -ex "break go.package2.Foo"
Function "go.package2.Foo" not defined.
...

With gcc-10, we set a breakpoint on the mangled minimal symbol.  That
one has simply changed for gcc-11, so it's equivalent to using:
...
$ gdb -q -batch a.out -ex "break go_0package2.Foo"
Breakpoint 1 at 0x403857
...
which does work.

Tested on x86_64-linux:
- openSUSE Leap 15.4, using gccgo-7,
- openSUSE Tumbleweed, using gccgo-13.

PR go/27238
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27238

[1] https://go-review.googlesource.com/c/gofrontend/+/271726
[2] https://github.com/golang/go/issues/41862#issuecomment-707244103

gdb: use objfile->pspace in free_objfile observers

Use objfile->pspace instead of current_program_space.

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

gdb: remove unnecessary nullptr check in free_objfile observers

The free_objfile observable is never called with a nullptr objfile.

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

gdb: add all_objfiles_removed observer

The new_objfile observer is currently used to indicate both when a new
objfile is added to program space (when passed non-nullptr) and when all
objfiles of a program space were just removed (when passed nullptr).
I think this is confusing (and Andrew apparently thinks so too [1]).
Add a new "all_objfiles_removed" observer to remove the second role from
"new_objfile".

Some existing users of new_objfile do nothing if the passed objfile is
nullptr.  For them, we can simply drop the nullptr check.  For others,
add a new all_objfiles_removed callback, and refactor things a bit to
keep the existing behavior as much as possible.

Some callbacks relied on current_program_space, and following
the refactoring now use either objfile->pspace or the pspace passed to
all_objfiles_removed.  I think this should be relatively safe, and in
general a step in the right direction.

On the notify side, I found only one call site to change from
new_objfile to all_objfiles_removed, in clear_symtab_users.  It is not
entirely clear to me that this is entirely correct.  clear_symtab_users
appears to be called in spots that don't remove all objfiles
(functions finish_new_objfile, remove_symbol_file_command, reread_symbols,
do_module_cleanups).  But I think that this patch at least makes the
current code clearer.

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

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

gdb: add program_space parameters to some auto-load functions

Make the current_program_space references bubble up a bit.

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

gdb: use objfile->pspace in auto-load.c

Use objfile->pspace instead of current_program_space in two spots.

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

gdb: add program_space parameter to emit_clear_objfiles_event

Add program_space space parameters to emit_clear_objfiles_event and
create_clear_objfiles_event_object, making the reference to
current_program_space bubble up a bit.

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

gdb: add program_space parameters to some functions in symtab.c

Add some program_space parameters to functions related to getting and
setting the main name, making the references to current_program_space
bubble up a bit.  find_main_name calls ada_main_name, which implicitly
relies on the current program space, so I didn't add a parameter to that
function.

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

gdb: add program_space parameter to ada_clear_symbol_cache

Make the references to current_program_space bubble up one level.

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

gdb: fix auxv cache clearing from new_objfile observer

It was pointed out on the mailing list that a recently added
test (gdb.python/py-progspace-events.exp) was failing when run with
the native-extended-gdbserver board.  This test was added with this
commit:

  commit 59912fb2d22f8a4bb0862487f12a5cc65b6a013f
  Date:   Tue Sep 19 11:45:36 2023 +0100

      gdb: add Python events for program space addition and removal

It turns out though that the test is failing due to a existing bug
in GDB, the new test just exposes the problem.  Additionally, the
failure really doesn't even rely on the new functionality added in the
above commit.  I reduced the test to a simple set of steps that
reproduced the failure and tested against GDB 13, and the test passes;
so the bug was introduced since then.  In fact, the bug was introduced
with this commit:

  commit a2827364e2bf19910fa5a54364a594a5ba3033b8
  Date:   Fri Sep 8 15:48:16 2023 +0100

      gdb: remove final user of the executable_changed observer

This commit changed how the per-inferior auxv data cache is managed,
specifically, when the cache is cleared, and it is this that leads to
the failure.

This bug is interesting because it exposes a number of issues with
GDB, I'll explain all of the problems I see, though ultimately, I only
propose fixing one problem in this commit, which is enough to resolve
the crash we are currently seeing.

The crash that we are seeing manifests like this:

  ...
  [Inferior 2 (process 3970384) exited normally]
  +inferior 1
  [Switching to inferior 1 [process 3970383] (/tmp/build/gdb/testsuite/outputs/gdb.python/py-progspace-events/py-progspace-events)]
  [Switching to thread 1.1 (Thread 3970383.3970383)]
  #0  breakpt () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.python/py-progspace-events.c:28
  28 { /* Nothing.  */ }
  (gdb) step
  +step
  terminate called after throwing an instance of 'gdb_exception_error'

  Fatal signal: Aborted
  ... etc ...

What's happening is that GDB attempts to refill the auxv cache as a
result of the gdbarch_has_shared_address_space call in
program_space::~program_space, the backtrace looks like this:

  #0  0x00007fb4f419a9a5 in raise () from /lib64/libpthread.so.0
  #1  0x00000000008b635d in handle_fatal_signal (sig=6) at ../../src/gdb/event-top.c:912
  #2  <signal handler called>
  #3  0x00007fb4f38e3625 in raise () from /lib64/libc.so.6
  #4  0x00007fb4f38cc8d9 in abort () from /lib64/libc.so.6
  #5  0x00007fb4f3c70756 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () from /lib64/libstdc++.so.6
  #6  0x00007fb4f3c7c6dc in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6
  #7  0x00007fb4f3c7b6e9 in __cxa_call_terminate () from /lib64/libstdc++.so.6
  #8  0x00007fb4f3c7c094 in __gxx_personality_v0 () from /lib64/libstdc++.so.6
  #9  0x00007fb4f3a80c63 in _Unwind_RaiseException_Phase2 () from /lib64/libgcc_s.so.1
  #10 0x00007fb4f3a8154e in _Unwind_Resume () from /lib64/libgcc_s.so.1
  #11 0x0000000000e8832d in target_read_alloc_1<unsigned char> (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2266
  #12 0x0000000000e73dea in target_read_alloc (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2315
  #13 0x000000000058248c in target_read_auxv_raw (ops=0x408a3a0) at ../../src/gdb/auxv.c:379
  #14 0x000000000058243d in target_read_auxv () at ../../src/gdb/auxv.c:368
  #15 0x000000000058255c in target_auxv_search (match=0x0, valp=0x7ffdee17c598) at ../../src/gdb/auxv.c:415
  #16 0x0000000000a464bb in linux_is_uclinux () at ../../src/gdb/linux-tdep.c:433
  #17 0x0000000000a464f6 in linux_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/linux-tdep.c:440
  #18 0x0000000000510eae in gdbarch_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/gdbarch.c:4889
  #19 0x0000000000bc7558 in program_space::~program_space (this=0x4544aa0, __in_chrg=<optimized out>) at ../../src/gdb/progspace.c:124
  #20 0x00000000009b245d in delete_inferior (inf=0x47b3de0) at ../../src/gdb/inferior.c:290
  #21 0x00000000009b2c10 in prune_inferiors () at ../../src/gdb/inferior.c:480
  #22 0x00000000009c5e3e in fetch_inferior_event () at ../../src/gdb/infrun.c:4558
  #23 0x000000000099b4dc in inferior_event_handler (event_type=INF_REG_EVENT) at ../../src/gdb/inf-loop.c:42
  #24 0x0000000000cbc64f in remote_async_serial_handler (scb=0x4090a30, context=0x408a6b0) at ../../src/gdb/remote.c:14859
  #25 0x0000000000d83d3a in run_async_handler_and_reschedule (scb=0x4090a30) at ../../src/gdb/ser-base.c:138
  #26 0x0000000000d83e1f in fd_event (error=0, context=0x4090a30) at ../../src/gdb/ser-base.c:189

So this is problem #1, if we throw an exception while deleting a
program_space then this is not caught, and is going to crash GDB.

Problem #2 becomes evident when we ask why GDB is throwing an error in
this case; the error is thrown because the remote target, operating in
non-async mode, can't read the auxv data while an inferior is running
and GDB is waiting for a stop reply.  The problem here then, is why
does GDB get into a position where it tries to interact with the
remote target in this way, at this time?  The problem is caused by the
prune_inferiors call which can be seen in the above backtrace.

In prune_inferiors we check if the inferior is deletable, and if it
is, we delete it.  The problem is, I think, we should also check if
the target is currently in a state that would allow us to delete the
inferior.  We don't currently have such a check available, we'd need
to add one, but for the remote target, this would return false if the
remote is in async mode and the remote is currently waiting for a stop
reply.  With this change in place GDB would defer deleting the
inferior until the remote target has stopped, at which point GDB would
be able to refill the auxv cache successfully.

And then, problem #3 becomes evident when we ask why GDB is needing to
refill the auxv cache now when it didn't need to for GDB 13.  This is
where the second commit mentioned above (a2827364e2bf) comes in.
Prior to this commit, the auxv cache was cleared by the
executable_changed observer, while after that commit the auxv cache
was cleared by the new_objfile observer -- but only when the
new_objfile observer is used in the special mode that actually means
that all objfiles have been unloaded (I know, the overloading of the
new_objfile observer is horrible, and unnecessary, but it's not really
important for this bug).

The difference arises because the new_objfile observer is triggered
from clear_symtab_users, which in turn is called from
program_space::~program_space.  The new_objfile observer for auxv does
this:

  static void
  auxv_new_objfile_observer (struct objfile *objfile)
  {
    if (objfile == nullptr)
      invalidate_auxv_cache_inf (current_inferior ());
  }

That is, when all the objfiles are unloaded, we clear the auxv cache
for the current inferior.

The problem is, then when we look at the prune_inferiors ->
delete_inferior -> ~program_space path, we see that the current
inferior is not going to be an inferior that exists within the
program_space being deleted; delete_inferior removes the deleted
inferior from the global inferior list, and then only deletes the
program_space if program_space::empty() returns true, which is only
the case if the current inferior isn't within the program_space to
delete, and no other inferior exists within that program_space
either.

What this means is that when the new_objfile observer is called we
can't rely on the current inferior having any relationship with the
program space in which the objfiles were removed.  This was an error
in the commit a2827364e2bf, the only thing we can rely on is the
current program space.  As a result of this mistake, after commit
a2827364e2bf, GDB was sometimes clearing the auxv cache for a random
inferior.  In the native target case this was harmless as we can
always refill the cache when needed, but in the remote target case, if
we need to refill the cache when the remote target is executing, then
we get the crash we observed.

And additionally, if we think about this a little more, we see that
commit a2827364e2bf made another mistake.  When all the objfiles are
removed, they are removed from a program_space, a program_space might
contain multiple inferiors, so surely, we should clear the auxv cache
for all of the matching inferiors?

Given these two insights, that the current_inferior is not relevant,
only the current_program_space, and that we should be clearing the
cache for all inferiors in the current_program_space, we can update
auxv_new_objfile_observer to:

  if (objfile == nullptr)
    {
      for (inferior *inf : all_inferiors ())
{
  if (inf->pspace == current_program_space)
    invalidate_auxv_cache_inf (inf);
}
    }

With this change we now correctly clear the auxv cache for the correct
inferiors, and GDB no longer needs to refill the cache at an
inconvenient time, this avoids the crash we were seeing.

And finally, we reach problem #4.  Inspired by the observation that
using the current_inferior from within the ~program_space function was
not correct, I added some debug to see if current_inferior() was
called anywhere else (below ~program_space), and the answer is yes,
it's called a often.  Mostly the culprit is GDB doing:

  current_inferior ()->top_target ()-> ....

But I think all of these calls are most likely doing the wrong thing,
and only work because the top target in all these cases is shared
between all inferiors, e.g. it's the native target, or the remote
target for all inferiors.  But if we had a truly multi-connection
setup, then we might start to see odd behaviour.

Problem #1 I'm just ignoring for now, I guess at some point we might
run into this again, and then we'd need to solve this.  But in this
case I wasn't sure what a "good" solution would look like.  We need
the auxv data in order to implement the linux_is_uclinux() function.
If we can't get the auxv data then what should we do, assume yes, or
assume no?  The right answer would probably be to propagate the error
back up the stack, but then we reach ~program_space, and throwing
exceptions from a destructor is problematic, so we'd need to catch and
deal at this point.  The linux_is_uclinux() call is made from within
gdbarch_has_shared_address_space(), which is used like:

  if (!gdbarch_has_shared_address_space (target_gdbarch ()))
    delete this->aspace;

So, we would have to choose; delete the address space or not.  If we
delete it on error, then we might delete an address space that is
shared within another program space.  If we don't delete the address
space, then we might leak it.  Neither choice is great.

A better solution might be to have the address spaces be reference
counted, then we could remove the gdbarch_has_shared_address_space
call completely, and just rely on the reference count to auto-delete
the address space when appropriate.

The solution for problem #2 I already hinted at above, we should have
a new target_can_delete_inferiors() call, which should be called from
prune_inferiors, this would prevent GDB from trying to delete
inferiors when a (remote) target is in a state where we know it can't
delete the inferior.  Deleting an inferior often (always?) requires
sending packets to the remote, and if the remote is waiting for a stop
reply then this will never work, so the pruning should be deferred in
this case.

The solution for problem #3 is included in this commit.

And, for problem #4, I'm not sure what the right solution is.  Maybe
delete_inferior should ensure the inferior to be deleted is in place
when ~program_space is called?  But that seems a little weird, as the
current inferior would, in theory, still be using the current
program_space...

Anyway, after this commit, the gdb.python/py-progspace-events.exp test
now passes when run with the native-extended-remote board.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30935
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I41f0e6e2d7ecc1e5e55ec170f37acd4052f46eaf

gprofng: 30894 bison should be no hard dependency

When running from a distribution tarball, bison should not be necessary.
The generated files (QLParser.tab.cc, QLParser.tab.hh) should be distributed.
configure.ac should not abort if bison is missing.
configure.ac should remove temporary files (dummy.c, Simple.class).
bison must be run once to create QLParser.tab.cc and QLParser.tab.hh.

gprofng/ChangeLog
2023-10-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30894
* configure.ac: Don't abort if bison is missing. Remove temporary files.
* src/Makefile.am: Distribute QLParser.tab.cc and QLParser.tab.hh.
* Run bison once to create QLParser.tab.cc and QLParser.tab.hh.
* configure: Rebuild.
* src/Makefile.in: Rebuild.

Fix: nm: SEGV at bfd/elf.c:2267 in _bfd_elf_get_dynamic_symbols

  PR 30904
  * elf.c (_bfd_elf_get_dynamic_symbols): Fix typo when checking to see if the gnuchains array has been successfully created.

Fix: ld: Test case pr28158 fails on x86_64-linux-musl when index is > 19

  PR 30905
  * testsuite/ld-elf/pr28158.rd: Adjust regexp to allow for section indicies larger than 9.

Fix: addr2line testsuite fails when targeting PowerPC 64 big-endian with ELFv2 ABI

  PR 30916
  * testsuite/binutils-all/addr2line.exp: Do not use PowerPC specific options when working with a MUSL target.

Fix: ld testsuite: glibc-specific DT_RELR tests should not be run on musl systems

  PR 30917
  * testsuite/ld-elf/dt-relr.exp: Skip for MUSL targets.

Fix: ld testsuite: non-PIC shared tests fail on powerpc-linux-musl

  PR 30918
  * testsuite/ld-shared/shared.exp: Add XFAILs for tests that fail with the MUSL library.

Fix: ld testsuite: Thumb PLT and GOT tests should be skipped on musl armhf targets

  PR 30923
  * testsuite/ld-arm/thumb-plt-got.d: Skip test for configurations using the MUSL library.
  * testsuite/ld-arm/thumb-plt.d: Likewise.

Fix: ld testsuite: pr22001-1 test segfaults on musl/x86

  PR 30925
  PR 22001
  * testsuite/ld-i386/i386.exp: Skip the pr22001 test with TEXTREL relocations enabled on configurations using the MUSL library.