gdb/aarch64: Tests for fpmr

Add tests for FPMR support in gdb/gdbserver. These tests check
availability of FPMR, reading/writing to FPMR, core file generation and
preservation under sighandler frame unwinding.

A run of the full gdb testsuite has been done on aarch64-none-linux-gnu
without FPMR support. The gdb.arch tests were run on Shrinkwrap with
FPMR support.

Approved-By: Luis Machado <luis.machado.foss@gmail.com>

gdb/aarch64: core file support for FPMR

Add support for FPMR dumps/reads for core files.

Approved-By: Luis Machado <luis.machado.foss@gmail.com>

gdb/aarch64: signal frame support for fpmr

Add support for FPMR in signal frames and restore contents of FPMR.

Approved-By: Luis Machado <luis.machado.foss@gmail.com>

gdbserver/aarch64: Enable FPMR for AArch64 in gdbserver on Linux

Add support for FPMR in gdbserver.

Approved-By: Luis Machado <luis.machado.foss@gmail.com>

gdb/aarch64: Enable FPMR for AArch64 in gdb on Linux

The Floating Point Mode Register controls the behaviours of FP8
instructions. This patch add FPMR to GDB if it is enabled on the
target.

Approved-By: Luis Machado <luis.machado.foss@gmail.com>

bfd/ELF: Core file support for AArch64 FPMR

The Floating Point Mode Register is a new register which controls the
behaviour of FP8 instructions. This is handled by the Linux kernel
through a new NT_ARM_FPMR register set.

This patch adds required code to support core file dumps with
NT_ARM_FPMR in them.

gdb: simplify find_symbol_at_address

This commit further simplifies find_symbol_at_address by moving
the special handling in case of -readnow down to readnow_functions.

Running all tests in gdb.rust with and without -readnow shown no
regressions (tested on Debian, x86_64).

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

gdb: change find_compunit_symtab_by_address to find_symbol_by_address

This commit changes objfile::find_compunit_symtab_by_address and
corresponding quick_symbol_functions::find_compunit_symtab_by_address
to find_symbol_by_address return symbol.

This will allow simplifying find_symbol_at_address (the only caller of
find_compunit_symtab_by_address) by removing the special-case for
-readnow and moving the logic down to readnow_functions.

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

gdb: change search_symtab helper to be a method

This commit changes search_symtab helper in find_symbol_at_address to
be a method.

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

gdb, gdbserver: fix read/write_ptid types

In write_ptid(), a ptid's LWP member, which is declared long, is stored in
an int local variable before printing, potentially truncating it.  Fix it.

In read_ptid(), both PID and LWP are read as ULONGEST and then cast to
their respective type without checking for overflows.  Fix it.

In read_ptid(), an empty component is treated as zero.  Diagnose that as
an error, instead.

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

gdb, remote: fix set_thread () in start_remote ()

remote_target::start_remote_1 () calls set_continue_thread (minus_one_ptid)
with the intent to

      /* Let the stub know that we want it to return the thread.  */
      set_continue_thread (minus_one_ptid);

I interpret it such that it expects a later get_current_thread () to
return the thread selected by the target:

          /* We have thread information; select the thread the target
             says should be current.  If we're reconnecting to a
             multi-threaded program, this will ideally be the thread
             that last reported an event before GDB disconnected.  */
          ptid_t curr_thread = get_current_thread (wait_status);

This results in the packet sequence Hc-1, qC.

Hc simply sets cont_thread:

          else if (cs.own_buf[1] == 'c')
            cs.cont_thread = thread_id;

          write_ok (cs.own_buf);

and qC returns the general thread.  This doesn't match.

It also has some special treatment for null_ptid and minus_one_ptid:

    if (cs.general_thread != null_ptid && cs.general_thread != minus_one_ptid)
      ptid = cs.general_thread;
    else
      {
        init_thread_iter ();
        ptid = thread_iter->id;
      }

Similarly, Hg has some special treatment for null_ptid:

    if (cs.own_buf[1] == 'g')
      {
        if (thread_id == null_ptid)
          {
            /* GDB is telling us to choose any thread.  Check if
               the currently selected thread is still valid. If
               it is not, select the first available.  */
            thread_info *thread = find_thread_ptid (cs.general_thread);
            if (thread == NULL)
              thread = get_first_thread ();
            thread_id = thread->id;
          }

        cs.general_thread = thread_id;

The comment at Hg matches the intent of GDB for sending Hc-1.

Change the set_thread () call in remote_target::start_remote_1 () to

    set_general_thread (any_thread_ptid);

This results in GDB sending Hg0 and gdbserver preserving the currently
selected thread that is later returned in response to qC.

CC: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdbserver, read_ptid: handle '0' and '-1' thread ids

The special thread id '-1' means 'all threads'.
The special thread id '0' means 'any thread'.

Read_ptid () currently returns

    <current pid>.-1.0

and

    <current pid>.0.0

respectively.

Change that to minus_one_ptid for '-1' and to null_ptid for '0'.

CC: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: build solib-svr4-linux.o when building for targets xtensa*-*-*linux*

When building a GDB configured with --target=xtensa-buildroot-linux-uclibc, we get:

  CXXLD  gdb
/usr/bin/ld: xtensa-linux-tdep.o: in function `xtensa_linux_init_abi(gdbarch_info, gdbarch*)':
/home/simark/src/binutils-gdb/gdb/xtensa-linux-tdep.c:115:(.text+0x102): undefined reference to `make_linux_ilp32_svr4_solib_ops(program_space*)'

Fix it by adding solib-svr4-linux.o to the list of objects build for
targets xtensa*-*-*linux*.

Change-Id: I0caa04a1d1c097defb5ea9c285cccc09ba80058d

Automatic date update in version.in

hppa64: Fix handling of dynamic relocations

This change fixes issues with dynamic relocations.  We now support
R_PARISC_FPTR64 relocations for local symbols for both LTOFF and
simple FPTR64 relocations.  Allocation of dynrel relocations is
revised along the lines of ia64.  OPDs are reduced in size to 16
bytes so .opd section is now identical to that generated by the
HP linker.

Small applications now link and run successfully on HP-UX but better
stub support is needed for executables larger than roughly 8 MB.
Many PCREL22F branches can't reach their target.  This prevents
building any recent version of gcc.

2025-11-16  John David Anglin  <danglin@gcc.gnu.org>

bfd/ChangeLog:

* elf64-hppa.c (OPD_ENTRY_SIZE): Change to 16 bytes.
(elf64_hppa_check_relocs): Revise maybe_dynamic calculation.
Revise R_PARISC_FPTR64 case to request dynrel when hh is
not NULL.  Add local symbols to local dynamic symbol table.
Always add global symbols to dynamic symbol table when a
dynrel may be needed.
(allocate_global_data_opd): Update OPD entry allocation
for reduced OPD size.
(allocate_dynrel_entries): Rework along the lines of ia64.
(elf64_hppa_late_size_sections): Revise DLT allocation.
Revise OPD allocation.
(elf64_hppa_finalize_opd): Revise for reduced OPD size.
Remove unnecessary NULL check.
(elf64_hppa_finalize_dlt): Remove unnecessary NULL check.
(elf64_hppa_finalize_dynreloc): Rework along the lines of
ia64.  Correct relocation handling.
(elf_hppa_final_link_relocate): Don't zero first two words
of OPD.  Update relocation handling to output EPLT and
FPTR64 relocations for local symbols.

Automatic date update in version.in

ld-elfvers: Remove vers8.c

commit c8a8d3bb27743c6894b7d5406a84e809965b9266
Author:     Ian Lance Taylor <ian@airs.com>
AuthorDate: Thu Mar 13 02:46:09 1997 +0000
Commit:     Ian Lance Taylor <ian@airs.com>
CommitDate: Thu Mar 13 02:46:09 1997 +0000

    Wed Mar 12 21:44:19 1997  Eric Youngdale  <eric@andante.jic.com>

            * ld-elfvers/vers.exp, *: New tests for symbol versioning.
            * config/default.exp: Set ar and strip.

added an unused vers8.c.  There is

build_vers_lib_pic "vers8" vers1.c vers8 vers8.map "" vers8.ver vers1.dsym vers1.sym

The differences are:

1. Version scripts:

vers1.map:

VERS_1.1 {
 local:
 hide_old*;
 hide_original*;
 hide_new*;
};

VERS_1.2 {
} VERS_1.1;

VERS_2.0 {
 show_bar1; show_bar2;
} VERS_1.2;

vers8.map:

VERSION {
VERS_1.1 {
 local:
 hide_old*;
 hide_original*;
 hide_new*;
};

VERS_1.2 {
} VERS_1.1;

VERS_2.0 {
 show_bar1; show_bar2;
} VERS_1.2;
}

2. Symbol version dump:

vers1.ver:

Version definitions:
[1-4] 0x01 0x0c96425f vers1.so
[1-4] 0x00 0x0a7927b1 VERS_1.1
[1-4] 0x00 0x0a7927b2 VERS_1.2
VERS_1.1
[1-4] 0x00 0x0a7922b0 VERS_2.0
VERS_1.2

vers8.ver:

Version definitions:
[1-4] 0x01 0x0c96b25f vers8.so
[1-4] 0x00 0x0a7927b1 VERS_1.1
[1-4] 0x00 0x0a7927b2 VERS_1.2
VERS_1.1
[1-4] 0x00 0x0a7922b0 VERS_2.0
VERS_1.2

We can remove the unused vers8.c.

PR ld/33631
* testsuite/ld-elfvers/vers8.c: Removed.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

elf: Wire up PR ld/21086 test

commit 3c5fce9bc29b216af7d10f8d6e4d8c3f11a48359
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Apr 21 12:00:55 2017 -0700

    Require --no-dynamic-linker with -static -E/--dynamic-list

added pr21086.c and pr21086.list without wiring them up.  Wire them up to
verify that there is no dynamic section with -static -E/--dynamic-list.

PR ld/21086
PR ld/33630
* testsuite/ld-elf/pr21086.rd: New file.
* testsuite/ld-elf/shared.exp: Wire PR ld/21086 test.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

shared.exp: Use pr14862.map to build libpr14862.so

commit dda8ddc56f160befb8f8fc3ddc69d66cec6ac4f8
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Nov 20 22:17:27 2012 +0000

    Remove ref_dynamic_nonweak added by accident

used pr11138-1.map to build libpr14862.so by accident and pr14862.map
should be used instead.  The difference is

pr11138-1.map:

VERS_1 {
  global: bar; foo;
  local: *;
};

vs

pr14862.map:

VERS_1 {
  global: bar;
  local: *;
};

Since only "bar" is used, it didn't cause test failure.  Use pr14862.map
to build libpr14862.so as intended.

PR ld/14862
* ld-elf/shared.exp: Replace pr11138-1.map with pr14862.map
when building libpr14862.so.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

Automatic date update in version.in

MIPS/GAS: Select symbolic GPR and FPR names based on current ABI setting

Add GPR and FPR symbolic register names to GAS for all ABI choices,
selecting the set of names based on the ABI being assembled for.

This extends the existing feature where the oldabi and newabi would
provide different symbolic GPR names to the assembler.  Both EABIs and
o64 are now supported along with symbolic FPR names for all ABI choices.

Signed-off-by: Maximilian Ciric <max.ciric@gmail.com>

gdb: add microblaze-linux.xml to XMLTOC, regenerate microblaze-linux.c

microblaze-linux.c is out of date compared to the other .c files in the
features directory.  I think it's because it's missing from XMLTOC.  Add
it there and run the "cfiles" target, causing the updates to
microblaze-linux.c.

I thought that we could get rid of regformats/microblaze-linux.dat,
since microblaze-linux is described with an XML target, but apparently
not, I don't really understand (or forget) how these things work.

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

gdbserver: adjust init_target_desc call in tic6x_read_description

I spotted this call missing an argument.

For context, init_target_desc gained this osabi parameter in this
commit:

    Author:     Andrew Burgess <aburgess@redhat.com>
    AuthorDate: Fri Oct 4 19:30:04 2024 +0100
    Commit:     Andrew Burgess <aburgess@redhat.com>
    CommitDate: Tue Nov 12 12:51:36 2024 +0000

        gdbserver: pass osabi to GDB in more target descriptions

This bug was present in GDB 16.  I wonder if anybody uses this today.

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

gdb: remove tic6x .dat files

The tix6x gdbserver port was modified to use target descriptions in
commit 506fe5f49967 ("Change tic6x target descriptions").  The old
regformats .dat files were kept as a way to make sure the new target
descriptions matched the old register decsriptions.  I think by now it's
not necessary to keep the .dat files.

I don't have a way to build-test this though.

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

gdb, gdbsupport: use DISABLE_COPY_AND_ASSIGN in a few spots

Replace some explicitly deleted copy constructor and copy assignment
operator with the DISABLE_COPY_AND_ASSIGN macro for consistency
with the rest of the codebase.

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

Reject negative children in DAP

This changes DAP to ignore the case where a pretty-printer returns a
negative number from the num_children method.  It didn't seem worth
writing a test case for this.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33594
Reviewed-By: Ciaran Woodward <ciaranwoodward@xmos.com>

Have DAP handle multiple breakpoints at same location

A user pointed out that if multiple breakpoints are set at the same
spot, in DAP mode, then changing the breakpoints won't reset all of
them.

The problem here is that the breakpoint map only stores a single
breakpoint, so if two breakpoints have the same key, only one will be
stored.  Then, when breakpoints are changed, the "missing" breakpoint
will not be deleted.

The fix is to change the map to store a list of breakpoints.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33467
Reviewed-By: Ciaran Woodward <ciaranwoodward@xmos.com>

Rename variable in DAP breakpoint.py

This renames the variable 'breakpoint_map' in DAP's breakpoint.py,
adding an underscore to make it clear that it is private to the
module.

Reviewed-By: Ciaran Woodward <ciaranwoodward@xmos.com>

Mark Pascal as case-insensitive

The Pascal language is not case-sensitive, so implement the
appropriate language method.  This fixes gdb.pascal failures with
-gw3.

I wasn't sure if -gw3 should be the default so I've left it as-is.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33617
Approved-By: Tom de Vries <tdevries@suse.de>

[gdb/testsuite] Fix gdb.rust/methods.exp on i686-linux

On i686-linux, with test-case gdb.rust/methods.exp I get:
...
(gdb) print x.take()
$5 = methods::HasMethods {value: 4}
(gdb) FAIL: $exp: print x.take()
...

The instructions for the function methods::HasMethods::take look like this:
...
00007b90 <_ZN7methods10HasMethods4take17hf373500ea3bd6e27E>:
    7b90:       8b 44 24 04             mov    0x4(%esp),%eax
    7b94:       c3                      ret
...
which is equivalent to what you get for:
...
$ cat test.c
int foo (int val) { return val; }
$ gcc test.c -O2 -S -o-
  ...
movl 4(%esp), %eax
ret
  ...
$
...

The inferior call mechanism however decides that this is a return_method_struct
function, and adds an implicit first parameter pointing to the return value
location.  Then two things go wrong:
- the argument is written to a place where the code doesn't read from, and
- the return value is read from a place where the code doesn't write to.

AFAIU, both gdb and rustc are behaving correctly:
- there's no stable ABI and consequently rustc is at liberty to optimize this
  function how it wants, and
- gdb cannot be expected to target an unstable ABI.

The solution is to mark the function for interoperability using 'extern "C"'.

Doing so causes a compilation warning:
...
warning: `extern` fn uses type `HasMethods`, which is not FFI-safe
  --> gdb.rust/methods.rs:50:28
   |
50 |     pub extern "C" fn take(self) -> HasMethods {
   |                            ^^^^ not FFI-safe
   |
   = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute
     to this struct
   = note: this struct has unspecified layout
...
which we fix by using '#[repr(C)]'.

Likewise in gdb.rust/generics.exp.

Tested on i686-linux and x86_64-linux.

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

s390: Mention GOTIE20 relocation in TLS related comment

Commit bd1ea41b84b0 introduced the R_390_TLS_GOTIE20 relocation, but
missed to update a comment that mentions the related R_390_TLS_GOTIE12
relocation.

bfd/
* elf32-s390.c (allocate_dynrelocs): Mention GOTIE20 relocation
in TLS related comment.
* elf64-s390.c (allocate_dynrelocs): Likewise.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>

s390: Do not emit orphaned GOT entry for TLS IE to LE transition

Commit 69fc87f180bf introduced TLS support for s390 32-bit and 64-bit.
It defined GOT_TLS_IE_NLT in both elf32-s390.c and elf64-s390.c, but
erroneously assigned it the same value as GOT_TLS_IE in elf64-s390.c.
As a consequence the linker for s390 64-bit erroneously emitted an
orphaned GOT entry when performing TLS Initial Exec (IE) to Local
Exec (LE) transition optimization.

Correct the value of GOT_TLS_IE_NLT in elf64-s390.c.  This causes the
liker to actually optimize away the GOT entry when performing IE to LE
transition.  While at it add a comment that the suffix NLT denotes
"no literal (pool entry)".

Found while inspecting and cleaning up differences between elf32-s390.c
and elf64-s390.c.

bfd/
* elf32-s390.c (GOT_TLS_IE_NLT): Add comment that NLT denotes
no literal pool entry.
* elf64-s390.c (GOT_TLS_IE_NLT): Likewise.  Correct value.

ld/testsuite/
* ld-s390/tlsbin_64.dd: Adjust expected test results.
* ld-s390/tlsbin_64.sd: Likewise.

Fixes: 69fc87f180bf
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

s390: Check sreldynrelro in elf_s390_finish_dynamic_symbol

Add check for sreldynrelro being NULL, introduced by commit 5474d94f03ae
("dynrelro section for read-only dynamic symbols copied into
executable") in elf32-s390.c function elf_s390_finish_dynamic_symbol,
also to its elf64-s390.c counterpart.

Found while inspecting and cleaning up differences between elf32-s390.c
and elf64-s390.c.

bfd/
* elf64-s390.c (elf_s390_finish_dynamic_symbol): Add
sreldynrelro check from elf32-s390.c.

Fixes: 5474d94f03ae ("dynrelro section for read-only dynamic symbols copied into executable")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

s390: Increment PC-relative relocation count for PC24DBL relocs

Commit fb798c50b2c8 added the R_390_PC24DBL relocation.  Due to a copy
and paste error it messed up to increment the PC-relative relocation
count in elf64-s390.c function elf_s390_check_relocs (i.e. duplicate
check for R_390_PC16DBL).

Found while inspecting and cleaning up differences between elf32-s390.c
and elf64-s390.c.

bfd/
* elf64-s390.c (elf_s390_check_relocs): Increment PC-relative
relocation count for R_390_PC24DBL.

Fixes: fb798c50b2c8
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

bfd/ELF: properly mark bfd_elf_{,gc_common_}final_link() as private

They're solely used as hook functions (or helpers thereof), so aren't
intended to be invoked directly from outside the library. Add underscore
prefixes and make them hidden.

bfd/ELF: nds32_convert_{16_to_32,32_to_16}() are exposed to gas

As non-private functions, they should come with full disambiguating
prefixes - add bfd_elf_ to both. Hence commit bf4128d0cc6d2 ("bfd/ELF:
mark internal NDS32 functions hidden") also wrongly added ATTRIBUTE_HIDDEN
to them.

bfd/ELF: loongarch_{larch_reloc_name_lookup,adjust_reloc_bitsfield}() are exposed to gas

As non-private functions, they should come with full disambiguating
prefixes - add bfd_elf_ to both. Hence commit 2903d813fcc2 ("bfd/ELF: mark
internal LoongArch functions hidden") also wrongly added ATTRIBUTE_HIDDEN
to them.

While loongarch_get_uleb128_length() also falls in the same category,
having it live in libbfd, when outside of gas there's hardly any use to be
expected, isn't very useful. Drop the function altogether and simplify the
clearing of the ULEB128 in md_apply_fix().

For loongarch_larch_reloc_name_lookup() drop gas'es custom declaration;
the libbfd one ought to be used, for producer and consumer to "see" the
same one. Also drop ATTRIBUTE_UNUSED there, as that makes sense only for
parameters in function definitions.

objcopy binary symbol type check

This exposes an error on alpha-linux-gnuecoff where the start and end
syms are given the wrong storage class.

* testsuite/binutils-all/objcopy.exp (binary_symbol): Tighten
symbol type checking.

Automatic date update in version.in

PowerPC: Add support for RFC02660 - Context Switch Instruction

opcodes/
    * ppc-opc.c: (powerpc_opcodes): Add mtlpl.

gas/
    * testsuite/gas/ppc/future.s: New test.
    * testsuite/gas/ppc/future.d: Likewise.

PowerPC: Support for Controlled Cluster Memory (RFC02689)

opcodes/
    * ppc-opc.c (powerpc_opcodes): Add ccmclean, ccmrl.

gas/
    * testsuite/gas/ppc/future.s: New test.
    * testsuite/gas/ppc/future.d: Likewise.

pre-commit: bump black to 25.11.0

Ran `pre-commit autoupdate`.  No changes in formatting.

Change-Id: I6d779433e50efff858ac407917047b902f821503

gdb: fix flake8 warnings in gdb.base/gdb-index-many-types.py

Fix those:

    gdb/testsuite/gdb.base/gdb-index-many-types.py:17:18: F821 undefined name 'gdb'
    gdb/testsuite/gdb.base/gdb-index-many-types.py:26:42: F821 undefined name 'gdb'
    gdb/testsuite/gdb.base/gdb-index-many-types.py:29:16: F821 undefined name 'gdb'
    gdb/testsuite/gdb.base/gdb-index-many-types.py:31:19: F821 undefined name 'gdb'
    gdb/testsuite/gdb.base/gdb-index-many-types.py:33:16: F821 undefined name 'gdb'
    gdb/testsuite/gdb.base/gdb-index-many-types.py:33:51: F821 undefined name 'gdb'
    gdb/testsuite/gdb.base/gdb-index-many-types.py:47:17: E722 do not use bare 'except'

Change-Id: Iba1949a211af66e8dd1e6cb77a44845e5fa60c2e

gdb: remove attempted type de-duplication when building gdb-index

This commit removes the attempted de-duplication of types when
building the gdb-index.  This commit is the natural extension of this
earlier commit:

  commit aef36dee93bf194cb0b976a4ae49a79a736a188d
  Date:   Sun Aug 13 14:08:06 2023 +0200

      [gdb/symtab] Don't deduplicate variables in gdb-index

Which removed the de-duplication of variables.  It is worth reading
the earlier commit as all the justifications for that patch also
apply to this one.

Currently, when building the gdb-index we sort the type entries,
moving declarations to the end of the entry list, and non-declarations
to the front.  Then within each group, declarations, and
non-declarations, the index entries are sorted by CU offset.

We then emit the first entry for any given type name.

There are two problems with this.

First, a non-declaration entry could be a definition, but it could
also be a typedef.  Now sure, a typedef is a type definition, but not
necessarily a useful one.

If we have a header file that contains:

  typedef struct foo_t foo_t;

And a CU which makes use of 'foo_t', then the CU will include both a
typedef and a type declaration.  The target of the typedef will be the
declaration.  But notice, the CU will not include a type definition.

If we have two CUs, one which only sees the above typedef and
declaration, and another which sees the typedef and an actual type
definition, then the final list of entries for this type's name will
be:

  1. A typedef entry that points at the declaration.
  2. A typedef entry that points at the definition.
  3. A definition.
  4. A declaration.

Now (4) will get sorted to the end of the entry list.  But the order
of (1), (2), and (3) will depend on the CU offset.  If the CU which
containing the typedef and declaration has the smallest offset,
then (1) will be sorted to the front of the list of entries for this
type name.  Due to the de-duplication code this means that only (1)
will be added to the gdb-index.

After GDB starts and parses the index, if a user references 'foo_t'
GDB will look in the index and find just (1).  GDB loads the CU
containing (1) and finds both the typedef and the declaration.  But
GDB does not find the full type definition.  As a result GDB will
display 'foo_t' as an incomplete type.

This differs from the behaviour when no index is used.  With no index
GDB expands the first CU containing 'foo_t', finds the typedef and
type declaration, decides that this is not good enough and carries on.
GDB will then expand the second CU and find the type's definition, GDB
now has a full understanding of the type, and can print the type
correctly.

We could solve this problem by marking typedefs as a distinct
sub-category of types, just as we do with declarations.  Then we could
sort definitions to the front of the list, then typedefs, and finally,
declarations after that.  This would, I think, mean that we always
prefer emitting a definition for a type, which would resolve this
first problem, or at least, it would resolve it well enough, but it
wouldn't fix the second problem.

The second problem is that the Python API and the 'info types' command
can be used to query all type symbols.  As such, GDB needs to be able
to find all the CUs which contain a given type.  Especially as it is
possible that a type might be defined differently within different
CUs.

NOTE: Obviously a program doing this (defining a type differently in
  different CUs) would need to be mindful of the One Definition Rule,
  but so long as the type doesn't escape outside of a single CU then
  reusing a type name isn't, as I understand it, wrong.  And even if
  it is, the fact that it compiles, and could be a source of bugs,
  means (in my opinion) that GDB should handle this case to enable
  debugging of it.

Even something as simple as 'info types ....' relies on GDB being able
to find multiple entries for a given type in different CUs.  If the
index only contains a single type entry, then this means GDB will see
different things depending on which CUs happen to have been expanded.

Given all of the above, I think that any attempt to remove type
entries from the gdb-index is unsafe and can result in GDB behaving
differently when using the gdb-index compared to using no index.

The solution is to remove the de-duplication code, which is what this
patch does.

Now that we no longer need to sort declarations to the end of the
entry list, I've removed all the code related to the special use of
GDB_INDEX_SYMBOL_KIND_UNUSED5 (which is how we marked declarations),
this cleans things up a little bit.

I've also renamed some of the functions away from minimize, now that
there's no minimization being done.

A problem was revealed by this change.  When running the test
gdb.cp/stub-array-size.exp with the --target_board=cc-with-gdb-index,
I was seeing a failure using gcc 15.1.0.

This test has two CUs, and a type 'A'.  The test description says:

  Test size of arrays of stubbed types (structures where the full
  definition is not immediately available).

Which I don't really understand given the test's source code.  The
type 'A' is defined in a header, which is included in both CUs.
However, the test description does seem to be accurate; in one CU the
type looks like this:

 <1><4a>: Abbrev Number: 8 (DW_TAG_structure_type)
    <4b>   DW_AT_name        : A
    <4d>   DW_AT_declaration : 1
    <4d>   DW_AT_sibling     : <0x6d>
 <2><51>: Abbrev Number: 9 (DW_TAG_subprogram)
    <52>   DW_AT_external    : 1
    <52>   DW_AT_name        : ~A
    <55>   DW_AT_decl_file   : 2
    <56>   DW_AT_decl_line   : 20
    <57>   DW_AT_decl_column : 11
    <58>   DW_AT_linkage_name: (indirect string, offset: 0x103): _ZN1AD4Ev
    <5c>   DW_AT_virtuality  : 1        (virtual)
    <5d>   DW_AT_containing_type: <0x4a>
    <61>   DW_AT_declaration : 1
    <61>   DW_AT_object_pointer: <0x66>
    <65>   DW_AT_inline      : 0        (not inlined)
 <3><66>: Abbrev Number: 10 (DW_TAG_formal_parameter)
    <67>   DW_AT_type        : <0x8c>
    <6b>   DW_AT_artificial  : 1
 <3><6b>: Abbrev Number: 0
 <2><6c>: Abbrev Number: 0

while in the second CU, the type looks like this:

 <1><178>: Abbrev Number: 4 (DW_TAG_structure_type)
    <179>   DW_AT_name        : A
    <17b>   DW_AT_byte_size   : 8
    <17c>   DW_AT_decl_file   : 2
    <17d>   DW_AT_decl_line   : 18
    <17e>   DW_AT_decl_column : 8
    <17f>   DW_AT_containing_type: <0x178>
    <183>   DW_AT_sibling     : <0x1ac>
 <2><187>: Abbrev Number: 5 (DW_TAG_member)
    <188>   DW_AT_name        : (indirect string, offset: 0x19e): _vptr.A
    <18c>   DW_AT_type        : <0x1be>
    <190>   DW_AT_data_member_location: 0
    <191>   DW_AT_artificial  : 1
 <2><191>: Abbrev Number: 6 (DW_TAG_subprogram)
    <192>   DW_AT_external    : 1
    <192>   DW_AT_name        : ~A
    <195>   DW_AT_decl_file   : 1
    <196>   DW_AT_decl_line   : 20
    <197>   DW_AT_decl_column : 1
    <198>   DW_AT_linkage_name: (indirect string, offset: 0x103): _ZN1AD4Ev
    <19c>   DW_AT_virtuality  : 1       (virtual)
    <19d>   DW_AT_containing_type: <0x178>
    <1a1>   DW_AT_declaration : 1
    <1a1>   DW_AT_object_pointer: <0x1a5>
 <3><1a5>: Abbrev Number: 7 (DW_TAG_formal_parameter)
    <1a6>   DW_AT_type        : <0x1cd>
    <1aa>   DW_AT_artificial  : 1
 <3><1aa>: Abbrev Number: 0
 <2><1ab>: Abbrev Number: 0

So, for reasons that I don't understand, the type, despite (as far as
I can see) having its full definition available, is recorded only as
declared in one CU.

The test then performs some actions that rely on 'sizeof(A)' and
expects GDB to correctly figure out the size.  This requires GDB to
find, and expand the CU containing the real definition of 'A'.

Prior to this patch GDB would sort the two type entries for 'A',
placing the declaration second, and then record only one entry, the
definition.  When it came to expansion there was only one thing to
expand, and this is the declaration we needed.  It happens that in
this test the definition is in the second CU, that is, the CU with the
biggest offset.  This means that, if all index entries were considered
equal, the definition entry would be second.  However, currently, due
to the way GDB forces definitions to the front, the entry for the
second CU, the definition, is placed first in the index, and with
de-duplication, this is the only entry added to the index.

After this patch, both the declaration and the definition are placed
in the index, and as the declaration is in the CU at offset 0, the
declaration is added first to the index.

This should be fine.  When looking for 'A' GDB should expand the CU
containing the declaration, see that all we have is a declaration, and
so continue, next expanding the definition, at which point we're done.

However, in read-gdb-index.c, in the function
mapped_gdb_index::build_name_components, there is a work around for
gold bug PR gold/15646.  Ironically, the bug here is that gold was not
removing duplicate index entries, and it is noted that this has a
performance impact on GDB.  A work around for this was added to GDB in
commit:

  commit 8943b874760d9cf35b71890a70af9866e4fab2a6
  Date:   Tue Nov 12 09:43:17 2013 -0800

      Work around gold/15646.

A test for this was added in:

  commit 40d22035a7fc239ac1e944b75a2e3ee9029d1b76
  Date:   Tue May 26 11:35:32 2020 +0200

      [gdb/testsuite] Add test-case gold-gdb-index.exp

And the fix was tweaked in commit:

  commit f030440daa989ae3dadc1fa4342cfa16d690db3c
  Date:   Thu May 28 17:26:22 2020 +0200

      [gdb/symtab] Make gold index workaround more precise

The problem specifically called out in the bug report is that
namespaces can appear in multiple CUs, and that trying to complete
'ns::misspelled' would expand every CU containing namespace 'ns' due
to the duplicate 'ns' type symbols.

The work around that was added in 8943b874760d9cf3 was to ignore
duplicate global symbols when expanding entries from the index.  In
commit f030440daa989ae3 this work around was restricted to only ignore
duplicate type entries.  This restriction was required to allow the
earlier de-duplication patch aef36dee93bf194c to function correctly.

Now that I'm taking the work started in aef36dee93bf194c to its
logical conclusion, and allowing duplicate type entries, the work
around of ignoring duplicate global type symbols is no longer needed,
and can be removed.

The associated test for this, added in 40d22035a7fc239a, is also
removed in this commit.

To be clear; the performance issue mentioned in PR gold/15646 is now
back again.  But my claim is that gold was right all along to include
the duplicate index entries, and any performance hit we see as a
result, though unfortunate, is just a consequence of doing it right.

That doesn't mean there's not room for optimisation and improvement in
the future, though I don't have any immediate ideas, or plans in this
area.  It's just we can't throw out a bunch of index entries that are
critical, and claim this as a performance optimisation.

I am seeing some failure with this patch when using the board file
dwarf5-fission-debug-types.  These failures all have the error:

  DWARF Error: wrong unit_type in unit header (is DW_UT_skeleton, should be DW_UT_type) [in module ....]

However, I ran the whole testsuite with this board, and this error
crops up often, so I don't think this is something specific to my
patch, so I'm choosing to ignore this.

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

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

gdb: symbol_search objects of different types are not the same

Consider the C construct:

  typedef struct foo
  {
    int a;
    int b;
  } foo;

GDB will see two types here, 'struct foo' and the typedef 'foo'.
However, if we use 'info types foo' we will see this:

  File test.c:
  18: struct foo;

At least that's what I see with current HEAD of master.  However, it
is really just luck that we see the 'struct' here.  See more below.

When searching for symbols matching 'foo' GDB ends up in the function
global_symbol_searcher::add_matching_symbols, where we consider all
possible matching symbols.  This will include the 'struct foo' and the
typedef 'foo'.  However, before a new symbols is added to the results,
we attempt to remove duplicates with this code:

  /* Match, insert if not already in the results.  */
  symbol_search ss (block, sym);
  if (result_set->find (ss) == result_set->end ())
    result_set->insert (ss);

If a symbol is already present in result_set then it will not be added
a second time.

The symbol_search equality check is done using the function
symbol_search::compare_search_syms, this function does a number of
checks, but at the end, any two symbols that are in the same block
within the same file, with the same name, are considered the same,
even if the types of those symbols are different.

This makes sense in most cases, it usually wouldn't make sense to have
two symbols within a single block with different types.  But the
'struct foo' and typedef 'foo' case is a bit of a strange one.  Within
DWARF and GDB we consider both of these as just types.  But in C
types and structure names live in different namespaces, and so we can
have both in the same block.  I don't think that GDB should consider
these two as the same, especially if we consider something really
ill-advised like this:

  struct foo
  {
    int a;
    int b;
  };

  typedef int foo;

This is perfectly valid C code, 'struct foo' and the typedef 'foo' are
in different namespaces, and can be used within the same block.  But
please, never write C code like this.

Given the above, I think, when asked about 'foo', GDB should, report
both 'struct foo' and the typedef 'foo'.

To do this I propose extending symbol_search::compare_search_syms such
that if two symbol_search objects are in the same block, within the
same file, and they have the same name, then if just one of them is a
typedef, the two objects will not be considered equal.  The results
will be sorted by line number if the line numbers are different, or,
if the line numbers are the same, the non-typedef will be sorted
first.  This means that for something like this:

  typedef struct foo { int a; } foo;

We'll get an 'info types foo' result like:

  File test.c:
  18: struct foo;
  18: typedef struct foo foo;

I mentioned earlier that it is really just luck that we see 'struct
foo'.  I ran into this problem while working on another patch.  When
testing with the 'debug-types' board file I was seeing the typedef
being reported rather than the struct.  In "normal" DWARF given the
'typedef struct foo { ...} foo;' construct, the compiler will usually
emit the struct definition first, and then the typedef definition.  So
when GDB parses the DWARF it sees the struct first.  It is the typedef
that becomes the duplicate which is not added to the results list.

But with the 'debug-types' board the compiler moves the struct
definition out to the .debug_types section.  And GDB now parses the CU
containing the typedef first, and then expands the structure
definition from the separate section afterwards.  As a result, it is
the structure that is now considered the duplicate, and the typedef is
the result that gets reported.

I think this is yet another motivation for this patch.  Changes like
this (the use of .debug_types section) shouldn't impact what results
GDB shows to the user.

There is an interesting update to the gdb.base/info-types.exp.tcl test
script.  In this case the C results only needed to change to include
the typedef.  The C++ results already included both the struct and the
typedef in the expected results.  The reason for this is that C places
both the struct baz_t and the typedef for baz_t into the global block,
while C++ places the struct in the global block, and the typedef into
the static block.  I have no idea why there's a difference in the
placement, but I'm choosing to believe the difference is correct.  But
this explains why only the C results needed to change.  If anything
this (I think) is yet another justification for this change; having C
not show the typedef in this case seems weird when the same source
code compiled as C++ does show the typedef.

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

Automatic date update in version.in

[gdb/testsuite] Fix typo IBM'x -> IBM's some more

Fix typo in lib/compiler.cc: IBM'x -> IBM's.

[gdb/testsuite] Fix typo IBM'x -> IBM's

Fix typo in gdb.base/nodebug.exp and lib/compiler.c: IBM'x -> IBM's.

[gdb/testsuite] Use -std=c99 in gdb.base/nodebug.exp

With test-case gdb.base/nodebug.exp I run into:
...
gdb compile failed, gdb.base/nodebug.c: In function 'multf_noproto':
gdb.base/nodebug.c:63:1: warning: old-style function definition \
  [-Wold-style-definition]
   63 | multf_noproto (v1, v2)
      | ^~~~~~~~~~~~~
...

Fix this using -std=c99.

Tested on x86_64-linux.

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

Automatic date update in version.in

Allow Python to create const+volatile types

A user pointed out that the Python API can't create a type that is
both const and volatile.

The bug is that the calls to make_cv_type did not preserve the "other"
flag.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33585
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

[gdb/rust] Fix handling of unsigned discriminant

On i686-linux, with test-case gdb.rust/simple.exp, we get:
...
(gdb) print str_none^M
$71 = core::option::Option<alloc::string::String>::Some(alloc::string::String {vec: alloc::vec::Vec<u8, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {inner: alloc::raw_vec::RawVecInner<alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: core::ptr::non_null::NonNull<u8> {pointer: 0xbfffe6e8}, _marker: core::marker::PhantomData<u8>}, cap: core::num::niche_types::UsizeNoHighBit (2147483648), alloc: alloc::alloc::Global}, _marker: core::marker::PhantomData<u8>}, len: 4321411}})^M
(gdb) FAIL: $exp: print str_none
...
while this is expected:
...
(gdb) print str_none^M
$71 = core::option::Option<alloc::string::String>::None^M
(gdb) PASS: $exp: print str_none
...

Printing the variable in C mode:
...
$ gdb -q -batch outputs/gdb.rust/simple/simple \
    -ex "b 161" \
    -ex run \
    -ex "set language c" \
    -ex "p /x str_none"
  ...
$1 = {0x80000000, Some = {__0 = {vec = {buf = {inner = {ptr = {pointer = {pointer = 0xbfffedd8}, _marker = {<No data fields>}}, cap = {__0 = 0x80000000}, alloc = {<No data fields>}}, _marker = {<No data fields>}}, len = 0x41f083}}}}
...
shows us that the discriminant value is 0x80000000, which matches the "None"
variant:
...
 <3><1427>: Abbrev Number: 16 (DW_TAG_structure_type)
    <1428>   DW_AT_name        : Option<alloc::string::String>
    <142c>   DW_AT_byte_size   : 12
    <142d>   DW_AT_accessibility: 1     (public)
    <142e>   DW_AT_alignment   : 4
 <4><142f>: Abbrev Number: 47 (DW_TAG_variant_part)
    <1430>   DW_AT_discr       : <0x1434>
 <5><1434>: Abbrev Number: 48 (DW_TAG_member)
    <1435>   DW_AT_type        : <0x2cba>
    <1439>   DW_AT_alignment   : 4
    <143a>   DW_AT_data_member_location: 0
    <143b>   DW_AT_artificial  : 1
 <5><143b>: Abbrev Number: 52 (DW_TAG_variant)
    <143c>   DW_AT_discr_value : 0x80000000
 <6><1440>: Abbrev Number: 4 (DW_TAG_member)
    <1441>   DW_AT_name        : None
    <1445>   DW_AT_type        : <0x145a>
    <1449>   DW_AT_alignment   : 4
    <144a>   DW_AT_data_member_location: 0
 <6><144b>: Abbrev Number: 0
 <5><144c>: Abbrev Number: 51 (DW_TAG_variant)
 <6><144d>: Abbrev Number: 4 (DW_TAG_member)
    <144e>   DW_AT_name        : Some
    <1452>   DW_AT_type        : <0x146c>
    <1456>   DW_AT_alignment   : 4
    <1457>   DW_AT_data_member_location: 0
 <6><1458>: Abbrev Number: 0
 <5><1459>: Abbrev Number: 0
...
but the dynamic type resolves to the "Some" variant instead.

This is caused by signedness confusion.

The DW_AT_discr_value 0x80000000 is encoded as an LEB128 number, and the
signedness is determined by the "tag type for the variant part", which in this
case is unsigned:
...
 <1><2cba>: Abbrev Number: 6 (DW_TAG_base_type)
    <2cbb>   DW_AT_name        : u32
    <2cbf>   DW_AT_encoding    : 7      (unsigned)
    <2cc0>   DW_AT_byte_size   : 4
...

However, the value gets interpreted as signed instead (value printed in
resolve_dynamic_struct):
...
(gdb) p /x variant_prop.m_data.variant_parts.m_array.variants.m_array[0].discriminants.m_array[0]
$3 = {low = 0xffffffff80000000, high = 0xffffffff80000000}
...
and then compared against an unsigned 0x80000000 in variant::matches().

Fix this in create_one_variant_part, by passing the required signedness as a
parameter to create_one_variant.

Tested on i686-linux and x86_64-linux.

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

[gdb/testsuite] Fix sizeof test in gdb.rust/simple.exp

On x86_64-linux, with test-case gdb.rust/simple.exp I get:
...
(gdb) print sizeof(e)^M
$52 = 24^M
(gdb) PASS: $exp: print sizeof(e)
...
but on i686-linux I get instead:
...
(gdb) print sizeof(e)^M
$52 = 20^M
(gdb) FAIL: $exp: print sizeof(e)
...

The variable e for which we print the size:
...
    let e = MoreComplicated::Two(73);
...
has type MoreComplicated which is defined like this:
...
pub struct HiBob {
    pub field1: i32,
    field2: u64,
}
  ...
enum MoreComplicated {
    One,
    Two(i32),
    Three(HiBob),
    Four{this: bool, is: u8, a: char, struct_: u64, variant: u32},
}
...

The answer to the question what the size of the enum should be seems to be
non-trivial [1][2], but AFAICT it doesn't seem to be illegal that the size can
differ between different platforms.

Fix this by accepting both 20 and 24 as valid size.

Tested on x86_64-linux and i686-linux.

Approved-By: Tom Tromey <tom@tromey.com>
[1] https://doc.rust-lang.org/reference/types/enum.html
[2] https://doc.rust-lang.org/reference/type-layout.html#the-rust-representation

gdb: use current executable for 'remote exec-file' in some cases

This commit allows GDB to make use of the file set with the 'file'
command when starting a new inferior on an extended-remote target.
There are however some restrictions.

If the user has used 'set remote exec-file', then this setting is
always used in preference to the file set with the 'file' command.

Similarly, if the qExecAndArgs packet has succeeded, and GDB knows
that the remote target has an executable set, then this will be used
in preference to the file set with the 'file' command; this preserves
GDB's existing behaviour.  In effect, when GDB connects to the remote
target, the remote sets the 'remote exec-file' and this prevents GDB
from using the 'file' filename.

And, GDB can only use the file set with the 'file' command if it
believes that both GDB and the remote target will both be able to
access this file.  This means that one of these is true:

  + the the remote_target::filesystem_is_local function returns
    true (see the implementation of that function for details of when
    this can happen).  This means GDB and the remote target can see
    the same file system, GDB can just use the current executable's
    filename as is, or

  + the user has set the 'file' to something with a 'target:' prefix,
    e.g. 'file target:/path/to/exec'.  In this last case, GDB will use
    the exec filename without the 'target:' prefix, this filename is,
    by definition, something the remote target can see, or

  + the sysroot has been updated by the user and no longer contains a
    'target:' prefix.  In this case, if the 'file' filename is within
    the sysroot, then it is assumed the remote will also be able to
    see a file with the same filename.  For example, if the sysroot is
    '/aa/', and the current executable is '/aa/bb/cc', then GDB will
    tell the remote to run '/bb/cc'.  One common case here is when the
    sysroot is set to the empty string, which is usually done when GDB
    and the remote target can see the same filesystem, in this case
    GDB will use the current executable's filename unmodified.

If one of these conditions is met, then GDB will use the current
executable's filename (with possible modifications as mentioned
above), when starting a new extended-remote inferior, in all other
cases, GDB will use the file name  set with 'set remote exec-file'.

This change could be useful any time a user is running a remote target
on the same machine as GDB, but I am specifically thinking of the case
where GDB is using a tool other than gdbserver, e.g. valgrind, as this
saves one additional step that a user must remember.  The current
steps to start valgrind with GDB, as given on the valgrind
website (https://valgrind.org/docs/manual/manual-core-adv.html) are:

  $ gdb prog
  (gdb) set remote exec-file prog
  (gdb) set sysroot /
  (gdb) target extended-remote | vgdb --multi --vargs -q
  (gdb) start

With this GDB work, and once support for the qExecAndArgs packet is
added to valgrind, then the 'set remote exec-file' line can be dropped
from those instructions.

This commit also extends the 'show remote exec-file' command so that
GDB will display the automatic value that it plans to use.  Here's an
example of the new output:

  $ gdb -q /tmp/hello
  Reading symbols from /tmp/hello...
  (gdb) set sysroot
  (gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
  Remote debugging using | ./gdbserver/gdbserver --multi --once -
  Remote debugging using stdio
  (gdb) show remote exec-file
  The remote exec-file is unset, using automatic value "/tmp/hello".

The last line shows the new output.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb/mips: make mips_tdesc_gp{32,64} target_desc_up

Change the types to target_desc_up so it's not needed to `.release()`
them.  This is similar to this review comment:

https: //inbox.sourceware.org/gdb-patches/87seeuak0z.fsf@tromey.com/

Change-Id: I45e0e77b00701aa979e8f7f15f397836b4e19849
Approved-By: Maciej W. Rozycki <macro@orcam.me.uk>
Tested-By: Maciej W. Rozycki <macro@orcam.me.uk>

objcopy binary symbol test

A small tidy that allows other symbols or warnings to appear in nm
output, and works around the case problem of windows drive letters
by simply omitting the $srcdir match.

* testsuite/binutils-all/objcopy.exp (binary_symbol): Check
objcopy and nm return status.  Don't repeat prune_warnings
already done in binutils_run.  Match each symbol separately,
reporting which match failed on a failure.  Don't match
$srcdir in implicit test.

Re: readelf: Display the base symbol version as empty string

Update a gold test for commit 2be0f2da2100.

PR binutils/33599
* testsuite/ver_test_4.sh: Expect "t1_2@".

Automatic date update in version.in

gdb/hppa: guess g packet size

With qemu supporting 64 bit now, add some code to determine the
register size of a hppa remote target.

Signed-off-by: Sven Schnelle <svens@stackframe.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Iffade4e02d758b9cb20c8f206e812bf3205518f7

[gdb/testsuite] Force DWARF in gdb.pascal

On i686-linux (and likewise arm-linux), I run into:
...
(gdb) file str-chars^M
Reading symbols from str-chars...^M
warning: stabs debug information is not supported.^M
(No debugging symbols found in str-chars)^M
(gdb) delete breakpoints^M
...

Fix this by using fpc option -gw2.

Tested on i686-linux.

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

Add uses of _() to symmisc.c

A review of an earlier version of this series pointed out some missing
_() invocations in symmisc.c.  This fixes the ones I thought were
appropriate.  In some spots I chose not to add them because the text
didn't seem like something that ought to be translated.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Print the CU index in cooked_index::dump

While exploring a question I had about the DWARF indexer, I found I
wanted to see the CU index of each entry.  This patch adds this
information.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Add styling to cooked_index::dump

This patch adds some styling to cooked_index::dump, making the output
a bit easier to read.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Add styling to symmisc.c

I was looking at some "maint" output and noticed that symmisc.c could
apply styling in a few spots.  This patch is the result.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Use unordered_map in record-btrace

This changes the bfcache in record-btrace.c to use a
gdb::unordered_map.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Use unordered_set for frame_stash

This changes the frame_stash global to be an unordered_set rather than
a htab_t.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb: remove unused includes in target-descriptions.c

Remove includes reported as unused by clangd.

Change-Id: I3b01165ed7c79d7305a6ba70f1f4c2b30864d26c

[pre-commit] Set verbose=false for check-whitespace

Currently, the pre-commit check check-whitespace has verbose=true:
...
$ pre-commit run --all-files check-whitespace
check-whitespace........................................................Passed
- hook id: check-whitespace
- duration: 0.3s
$
...

That's not necessary, since:
- check-whitespace has no output if the check passes, and
- pre-commit shows the output anyway if the check fails.

Fix this by removing the verbose setting, getting us instead:
...
$ pre-commit run --all-files check-whitespace
check-whitespace........................................................Passed
$
...

Approved-By: Simon Marchi <simon.marchi@efficios.com>

[gdb/testsuite] Drop address from test name in gdb.mi/mi-memory-changed.exp

I ran the testsuite twice, once with target board unix, and once with target
board unix/-fPIE/-pie, compare the two sum files, and got for test-case
gdb.mi/mi-memory-changed.exp:
...
< PASS: $exp: set var *(unsigned int *) 0x4011b0 = 0xe5894855
---
> PASS: $exp: set var *(unsigned int *) 0x5555555551c3 = 0xe5894855
...

Fix this by dropping the concrete address from the test name:
...
PASS: $exp: set var *(unsigned int *) 0x${main_addr} = ${main_insn}
...

Tested on x86_64-linux.

[gdb/testsuite] Drop address from test name in gdb.arch/amd64-shadow-stack-corefile.exp

I ran the testsuite twice, compare the two sum files, and got for test-case
gdb.arch/amd64-shadow-stack-corefile.exp:
...
3077c3077
< PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f7a38
3fffe0
---
> PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f179e
...

Fix this by dropping the address from the test name.

Tested on x86_64-linux.

readelf: Fix typo in --version-info documentation

Change "it they exist" to "if they exist" in the description
of the --version-info option in the readelf man page.

Minor cleanup in ld documentation

ld/
* ld.texi : Remove a remnant of previous edits.

Signed-off-by: Jan Dubiec <jdx@o2.pl>

bfd/ELF: mark internal MIPS functions hidden

This reduces the dynamic symbol table some and allows the compiler to be
more aggressive about inlining (as it sees fit, of course).

bfd/ELF: _bfd_elf_ppc_at_tls_transform() is exposed to gas

As a non-private function, it shouldn't have a "_bfd_" prefix, but merely
a "bfd_" one. Hence commit 50efe229ddf5 ("bfd/ELF: mark internal functions
hidden") also wrongly added ATTRIBUTE_HIDDEN to it.

ld: Fix a H8/300 specific test case

It seems that glob patterns no longer work in the test suite, at least
on some host/dejagnu/shell combinations.  In any case it is better
here not to create a single relax-7?.o file from the two source files,
but to create two separate objects for linking.

ld/
* testsuite/ld-h8300/relax-7.d: Replace the glob pattern with
multiple "source" options.

Signed-off-by: Jan Dubiec <jdx@o2.pl>

Automatic date update in version.in

libsframe: rename encoder to ectx for readability

Addressing (an old) review comment suggesting this housekeeping item.
Use consistent naming style in libsframe.  sframe_decoder_ctx objects
are named 'dctx', so use 'ectx' for sframe_encoder_ctx objects.

Make necessary changes in all the applicable declarations and definitions.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>

[gdb/testsuite] Fix main in gdb.trace/mi-trace-frame-collected.exp

With test-case gdb.trace/mi-trace-frame-collected.exp I run into:
...
gdb compile failed, gdb.trace/actions.c: In function 'main':
gdb.trace/actions.c:139:1: warning: old-style function definition \
  [-Wold-style-definition]
  139 | main (argc, argv, envp)
      | ^~~~
...

Fix this by rewriting main into a prototyped function.

Tested on x86_64-linux.

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

libsframe: fix checks in flip_fde

Adjust the sanity checks for flip_fde workflow and optional trailing
section padding to account for the case of ihp->sfh_fdeoff != 0 or
ihp->sfh_freoff != total FDEs size.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/
        * sframe.c (flip_sframe): Fix checks in flip_fde to accommodate
cases when sfh_fdeoff != 0 or when SFrame FREs are placed after
a gap from SFrame FDEs.

[gdb/testsuite] Use -std=c99 in gdb.base/callfuncs.exp

In test-case gdb.base/callfuncs.exp I run into:
...
gdb compile failed, gdb.base/callfuncs.c: In function 't_func_values':
gdb.base/callfuncs.c:611:12: error: too many arguments to function \
  'func_arg1'; expected 0, have 2
  611 |   return ((*func_arg1) (5,5)  == (*func_val1) (5,5)
      |           ~^~~~~~~~~~~  ~
...

Fix this by using -std=c99.

Tested on x86_64-linux.

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

Automatic date update in version.in

Automatic date update in version.in

readelf: Display the base symbol version as empty string

Update readelf to display the base symbol version as

Symbol table for image contains 5 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000003008     0 OBJECT  GLOBAL DEFAULT   10 bar@@
     2: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS VERS_1
     3: 0000000000003008     0 OBJECT  GLOBAL DEFAULT   10 bar@@VERS_1
     4: 0000000000003000     0 OBJECT  GLOBAL DEFAULT   10 foo@

instead of

Symbol table for image contains 5 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000003008     0 OBJECT  GLOBAL DEFAULT   10 bar
     2: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS VERS_1
     3: 0000000000003008     0 OBJECT  GLOBAL DEFAULT   10 bar@@VERS_1
     4: 0000000000003000     0 OBJECT  GLOBAL DEFAULT   10 foo

That is bar@@ and foo@ vs bar and foo.

binutils/

PR binutils/33599
* readelf.c (process_version_sections): Replace 0x8001 with
(VERSYM_HIDDEN | VERSYM_BASE).
(get_symbol_version_string): Likewise.  Return "" for the base
version.

include/

PR binutils/33599
* elf/common.h (VERSYM_BASE): New.

ld/

PR binutils/33599
* testsuite/ld-elf/pr33599.d: New file.
* testsuite/ld-elf/pr33599.map: Likewise.
* testsuite/ld-elf/pr33599.s: Likewise.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

gdb/testsuite: adjust yet another add-inferior test for native-extended-gdbserver board

I'm seeing this FAIL with the native-extended-gdbserver board:

    (gdb) add-inferior^M
    [New inferior 2]^M
    Added inferior 2 on connection 1 (extended-remote localhost:2365)^M
    (gdb) FAIL: gdb.python/py-parameter.exp: test_per_inferior_parameters: add-inferior

This is another case of add-inferior producing more output when
connected to a remote target.  Adjust the regexp to accomodate it.

Change-Id: Ic5760ff66712c54b90b9debf379dcbf6e07f6eeb

gdb/testsuite: adjust another add-inferior test for native-extended-gdbserver board

I see this FAIL when running with the native-extended-gdbserver board:

    Expecting: ^(-add-inferior[^M
    ]+)?(.*\^done,inferior="i2"[^M
    ]+[(]gdb[)] ^M
    [ ]*)
    -add-inferior^M
    =thread-group-added,id="i2"^M
    ~"[New inferior 2]\n"^M
    ~"Added inferior 2 on connection 1 (extended-remote localhost:2345)\n"^M
    ^done,inferior="i2",connection={number="1",name="extended-remote"}^M
    (gdb) ^M
    FAIL: gdb.mi/set-show.exp: test_per_inferior_parameters: add inferior (unexpected output)

This is another case of the add-inferior command producing more output
when connected to a remote target.  Adjust the regexp to accomodate it.

Change-Id: Ifa0590211fd75d4a01dff942c6bb810d5caf1257

pre-commit: check for whitespace errors in on all files under gdb

I got a review comment [1] because I forgot to run

    git diff --staged --check

to check commits before submitting. This commit adds a pre-commit hook
to do this automatically.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
[1]: https://inbox.sourceware.org/gdb-patches/c231d267-f541-4774-8005-6d433a9d6e96@simark.ca/

Write entire buffer in gdbserver write_prim

We had a customer bug report which was eventually tracked down to
gdbserver not fully sending a target description to gdb.  (This
presented as a timeout on the gdb side.)

The customer was using the WINAPI code, which does this:

  # define write(fd, buf, len) send (fd, (char *) buf, len, 0)

In this setup, I think it's possible to have a partial write.
However, gdbserver does not account for this possibility, despite the
fact that write_prim documents this.

This patch attempts to fix the problem by always writing the full
buffer in write_prim.  In this case the customer fixed their bug in a
different way, so we haven't actually tested this in the wild.

v2: Return bool from write_prim.

Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

gdb/dwarf: pass is_debug_types to dwarf2_per_cu constructor, make field private

Make the field private to make it clear it is never meant to change.
Pass its value through the constructor, and add a getter.  The only
place that passes true is the signature_type constructor.

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

gdb/dwarf: make some fields in dwarf2_per_cu private

Except for the m_length field, that is already private and has a setter,
make the fields whose values are passed through the constructor private.
The idea is that their values should be constant throughout the life of
the object.  Add some getters and update the callers.

I wasn't sure if making some bitfields public and some private would
change how they are packed, so I checked with "ptype/o", it does not.

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

gdb/dwarf: clarify comment on dwarf_per_bfd::all_units

I thought that this comment could be updated to clarify what this vector
holds and what it is used for.

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

Revert "bfd/ELF: make is_debuginfo_file() static"

This reverts commit 5e648fc6a0a066fad38d99b72fb85f2710f2c098, since it
breaks the GDB build:

      CXX    elfread.o
    /home/smarchi/src/binutils-gdb/gdb/elfread.c: In function ‘symfile_segment_data_up elf_symfile_segments(bfd*)’:
    /home/smarchi/src/binutils-gdb/gdb/elfread.c:145:12: error: ‘is_debuginfo_file’ was not declared in this scope
      145 |       if (!is_debuginfo_file (abfd)
          |            ^~~~~~~~~~~~~~~~~

Change-Id: I180a9f6936365c365a853c7dae2af01f5207a84e

gdb/testsuite: issue "no repeat" command before "no previous command to relaunch" test

I see this failure:

    $ make check TESTS="gdb.base/with.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
    FAIL: gdb.base/with.exp: repeat: reinvoke with no previous command to relaunch

It seems like that failure has always been there and I didn't notice?

I'm not sure what is the intent of the test exactly.  It sounds like it
is meant to test what happens when you use command "with language ada"
as the very first command of a GDB session?  However, clean_restart and
gdb_load issue some commands before that test.  The different between
the native-extended-gdbserver board and the other boards is: for other
boards, the previous command is a "file" command, which is a "no repeat"
command, which gives the expected error message.  With the
native-extended-gdbserver board, the previous command is "set remote
exec-file", which is a repeatable command.

"Fix" it by making a "no repeat" command just before the test, so that
it works the same regardless of the target board.

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

gdb/testsuite: rename thread_local variables

C standard gnu23 introduces a new keyword 'thread_local'.
So, this variables must be renamed to avoid build errors.

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

s390: Bind defined symbol locally in PIE

Symbols defined in PIE should be bound locally, the same as -shared
-Bsymbolic.

Port x86 commit 4e0c91e45402 ("Bind defined symbol locally in PIE")
change of relocate_section as well as linker tests to s390.  Similar as
done for other architectures with the following commits:
- AArch64: ac33b731d214 ("[AArch64] Bind defined symbol locally in PIE")
- ARM: 1dcb9720d62c ("[ARM] Bind defined symbol locally in PIE")
- RISC-V: 39c7793ba8be ("RISC-V: Bind defined symbol locally in PIE")
- x86: 4e0c91e45402 ("Bind defined symbol locally in PIE")
With this change symbols defined in an executable (i.e. PDE or PIE) are
bound locally, as they cannot be interposed.  In the same way as symbols
defined in a shared library linked with -Bsymbolic are bound locally.

This also ensures that all defined symbols are bound locally in
static PIE.

Do not port the x86 change of check_relocs (now scan_relocs).  None of
the linker tests where the change in condition triggers (e.g. bootstrap,
cdtest) produce different readelf -Wa output.  The change appears to
affect accounting of space required for dynamic relocations.  Instead of
accounting them in check_relocs and later filtering them away in
allocate_dynrelocs, they would not get accounted in the first place:
The change in the expression would only have an effect if the following
conditions are all met in addition to PIE:  ALLOC, PC-relative
relocation, global symbol, not defined weak, and defined regular.  In
this specific case the accounting of the PC relative relocation in
h->dyn_relocs would be skipped for PIE.  But allocate_dynrelocs later
eliminates any PC-relative dynamic relocations if PIC (= PIE or shared
library) and SYMBOL_CALLS_LOCAL.

bfd/
PR ld/33141
* elf64-s390.c (elf_s390_relocate_section): Bind defined symbol
locally in PIE.

ld/testsuite/
PR ld/33141
* ld-s390/s390.exp: Add pr33141 tests.
* ld-s390/pr33141.rd: New file.
* ld-s390/pr33141a.s: Likewise.
* ld-s390/pr33141b.s: Likewise.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>

bfd/ELF: _bfd_elf_linker_x86_set_options() is exposed to ld

As a non-private function, it shouldn't have a "_bfd_" prefix, but merely
a "bfd_" one.

bfd/ELF: _bfd_elf_link_create_dynamic_sections() is exposed to ld

As a non-private function, it shouldn't have "_bfd_" prefixes, but merely
a "bfd_" one. Even if, sadly, it needs exposing just for the sake for
VxWorks.

bfd/ELF: mark functions exposed to ld as non-private

As non-private functions, these shouldn't have "_bfd_" prefixes,
but merely "bfd_" ones:
- _bfd_elf_size_group_sections(),
- _bfd_elf_match_sections_by_type(),
- _bfd_elf_strtab_{str,len}(),
- _bfd_elf_map_sections_to_segments(),
- _bfd_elf_tls_setup().

bfd/ELF: _bfd_elf{,32,64}_hppa_gen_reloc_type are exposed to gas

As non-private functions / macros, they shouldn't have "_bfd_" prefixes,
but merely "bfd_" ones.

bfd/ELF: _bfd_elf_large_com_section is exposed to gas and x86-only

As a non-private data item, it shouldn't have a "_bfd_" prefix, but merely
a "bfd_" one. Furthermore, as being x86-only (forever since its
introduction), it doesn't need to be present in libbfd.{a,so} at all for
other targets.

bfd/ELF: _bfd_elf_obj_attrs_arg_type() is exposed to gas

As a non-private function, it shouldn't have a "_bfd_" prefix, but merely
a "bfd_" one.