PR29566, objdump -p considers an empty .gnu.version_r invalid

Allow and ignore an empty section.

PR 29566
* elf.c (bfd_section_from_shdr): Don't set elf_dynverdef or
elf_dynverref for empty sections.
(_bfd_elf_slurp_version_tables): Remove now redundant tests.

RISC-V: Set EF_RISCV_TSO also on .option arch

This is a minor fix to commit 96462b012988d35ebb1137a2ad9fd0a96547d79a
("RISC-V: Implement Ztso extension").  Currently, it sets EF_RISCV_TSO ELF
flag when initial ISA string contains the 'Ztso' extension.  However, GAS
has a way to update the ISA string: ".option arch".

When the architecture is updated by ".option arch", EF_RISCV_RVC ELF flag
is set when the 'C' extension is detected.  Analogously, this commit sets
the EF_RISCV_TSO when the 'Ztso' extension is detected.

gas/ChangeLog:

* config/tc-riscv.c (s_riscv_option): Set TSO ELF flag if the
'Ztso' extension is specified via ".option arch" directive.

PR29573, addr2line doesn't display file/line for local symbols

The DWARF standard is clear that DW_AT_linkage_name is optional.
Compilers may not provide the attribute on functions and variables,
even though the language mangles names.  g++ does not for local
variables and functions.  Without DW_AT_linkage_name, mangled object
file symbols can't be directly matched against the source-level
DW_AT_name in DWARF info.  One possibility is demangling the object
file symbols, but that comes with its own set of problems:
1) A demangler might not be available for the compiler/language.
2) Demangling doesn't give the source function name as stored in
   DW_AT_name.  Class and template parameters must be stripped at
   least.

So this patch takes a simpler approach.  A symbol matches DWARF info
if the DWARF address matches the symbol address, and if the symbol
name contains the DWARF name as a sub-string.  Very likely the name
matching is entirely superfluous.

PR 29573
* dwarf.c (lookup_symbol_in_function_table): Match a symbol
containing the DWARF source name as a substring.
(lookup_symbol_in_variable_table): Likewise.
(_bfd_dwarf2_find_nearest_line_with_alt): If stash_find_line_fast
returns false, fall back to comp_unit_find_line.

dwarf2.c: simplify best_fit_len tests

* dwarf2.c (lookup_address_in_function_table): Simplify
best_fit_len test.
(info_hash_lookup_funcinfo): Likewise.
(lookup_symbol_in_function_table): Likewise, also reorder tests
and check "file" is set.
(lookup_symbol_in_variable_table): Reorder tests.

dwarf2.c: mangle_style

non_mangled incorrectly returned "true" for Ada.  Correct that, and
add a few more non-mangled entries.  Return a value suitable for
passing to cplus_demangle to control demangling.

* dwarf2.c: Include demangle.h.
(mangle_style): Rename from non_mangled.  Return DMGL_* value
to suit lang.  Adjust all callers.

dwarf2.c remove varinfo and funcinfo sec field

The "sec" field in these structures is only set and used in lookup
functions.  It always starts off as NULL.  So the only possible effect
of the field is to modify the return of the lookup, which was its
purpose back in 2005 when HJ fixed PR990.  Since then we solved the
problem of relocatable object files with the fix for PR2338, so this
field is now redundant.

* dwarf.c (struct funcinfo, struct varinfo): Remove "sec" field.
(lookup_symbol_in_function_table): Don't set or test "sec".
(lookup_symbol_in_variable_table): Likewise.
(info_hash_lookup_funcinfo, info_hash_lookup_varinfo): Likewise.

configure: Pass CPPFLAGS_FOR_BUILD to subdirs

Because CPPFLAGS_FOR_BUILD is used in some subdirectories (through
bfd/warning.m4), not AC_SUBSTing the variable causes minor issues.

Fortunately, it didn't cause severe errors but error messages related to
@CPPFLAGS_FOR_BUILD@ (not AC_SUBSTed CPPFLAGS_FOR_BUILD variable passed
to subdirectories through Makefile) remain in config.log.

To avoid invalid invocation of preprocessor for build environment, we
need to set proper CPPFLAGS_FOR_BUILD (may be empty) and pass it to
subdirectories that need it.  This is what this commit does.

ChangeLog:

* configure.ac: Pass CPPFLAGS_FOR_BUILD to subdirectories.
* configure: Regenerate.

RISC-V: Implement Ztso extension

This patch support ZTSO extension. It will turn on the tso flag for elf_flags
once we have enabled Ztso extension.  This is intended to implement v0.1 of
the proposed specification which can be found in Chapter 25 of,
https://github.com/riscv/riscv-isa-manual/releases/download/draft-20220723-10eea63/riscv-spec.pdf.

bfd\ChangeLog:

        * elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Set TSO flag.
        * elfxx-riscv.c: Add Ztso's arch.

binutils\ChangeLog:

        * readelf.c (get_machine_flags): Set TSO flag.

gas\ChangeLog:

        * config/tc-riscv.c (riscv_set_tso): Ditto.
        (riscv_set_arch): Ditto.
        * testsuite/gas/riscv/ztso.d: New test.

include\ChangeLog:

        * elf/riscv.h (EF_RISCV_TSO): Ditto.

RISC-V: Always generate R_RISCV_CALL_PLT reloc for call in assembler.

Since we have the same behaviors of CALL and CALL_PLT relocs in linker for now,
https://github.com/bminor/binutils-gdb/commit/3b1450b38c644f99aa2e211747b428b9f8d15cca

And the psabi already deprecate the CALL reloc,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a0dced85018d7a0ec17023c9389cbd70b1dbc1b0

Therefore, we should always generate R_RISCV_CALL_PLT reloc for call, even if
it has @plt postfix.  I believe LLVM (https://reviews.llvm.org/D132530) already
support this, so GNU as should do the same thing.

gas/
* config/tc-riscv.c (riscv_ip): Always generate CALL_PLT reloc for
call, even if it has @plt postfix.
* testsuite/gas/riscv/no-relax-reloc.d: Updated CALL to CALL_PLT.
* testsuite/gas/riscv/relax-reloc.d: Likewise.
ld/
* testsuite/ld-riscv-elf/variant_cc-r.d: Updated CALL to CALL_PLT.

Automatic date update in version.in

Re: PowerPC64 pcrel got relocs against local symbols

The last patch wasn't all that shiny.  There are rather a lot more
relocations that can hit the assertion in md_apply_fix if the symbol
is local or absolute.  Fix them all.

* config/tc-ppc.c (ppc_force_relocation): Add all relocs that
expect a symbol in md_apply_fix.  Remove tls pcrel relocs
already covered in general tls match range.

looping in alpha_vms_slurp_relocs

The direct cause for the looping was failing to test for error return
from _bfd_vms_get_object_record inside a while(1) loop.  Fix that.
Also record status of first alpha_vms_slurp_relocs call and return
that for all subsequent calls.  (The object format has one set of
relocation records for all sections.)  If the first call fails, all
others should too.

* vms-alpha.c (struct vms_private_data_struct): Make reloc_done
a tri-state int.
(alpha_vms_slurp_relocs): Set reloc_done to 1 on success, -1 on
failure.  Return that status on subsequent calls.  Check
_bfd_vms_get_object_record return status.
(alpha_vms_get_reloc_upper_bound): Return status from
alpha_vms_slurp_relocs.
(alpha_vms_write_exec): Exclude sections with contents NULL due
to previous errors from layout, and don't try to write them.

ppc/svp64: test setvl ms operand

Make stdin_event_handler static

I noticed that stdin_event_handler is only used in event-top.c, so
this patch changes it to be 'static'.

Constify some target_so_ops instances

This changes some target_so_ops instances to be const.  This makes
their use a little more obvious (they can't be mutated) and also
allows for the removal of some initialization code.

Move solib_ops into gdbarch

This changs solib_ops to be an ordinary gdbarch value and updates all
the uses.  This removes a longstanding FIXME and makes the code
somewhat cleaner as well.

Remove current_target_so_ops

current_target_so_ops is only set in a single place.  It seems better
to simply remove it.

gdb/testsuite: add a debuginfod-support.exp helper library

We currently have a single test for GDB's debuginfod support, this is
gdb.debuginfod/fetch_src_and_symbols.exp, this script does all the
setup, starts debuginfod, and then does the testing.

This commit tries to split the existing script in two, there is a new
library lib/debuginfod-support.exp, which contains a helper functions
related to running debuginfod tests.  All the code in the new library
is basically copied from the existing test case (which is why I
retained the copyright date range on the new library), with some minor
adjustments to try and make the code a little more generic.

One change I made, for example, is the library offers functions to
shut down debuginfod, previously we just relied on expect shutting
down debuginfod when dejagnu completed.

The existing test script is updated to make use of the new library
code, and this test is still passing for me.  The only change in the
test results is a single test where I changed the name to remove the
port number from the test name - the port number can change from run
to run, so could make it hard to compare test results.

I have also done a little light house keeping on the original test
script, updating and adding new comments, and making use of
proc_with_prefix in a couple of places.

LoongArch: Set macro SUB_SEGMENT_ALIGN to 0.

Stop strip from complaining about empty note sections when stripping a binary for a second time.

* objcopy.c (copy_object): Do not issue a warning message when
encountering empty .gnu.build.attribute sections.

New Serbian translations for various binutils sub-directories.

Bug 29580 - typo in warning message: .note.gnu.build-id data size is too bug

LoongArch: Fix R_LARCH_IRELATIVE insertion after elf_link_sort_relocs

loongarch_elf_finish_dynamic_symbol is called after elf_link_sort_relocs
if -z combreloc.  elf_link_sort_relocs redistributes the contents of
.rela.* sections those would be merged into .rela.dyn, so the slot for
R_LARCH_IRELATIVE may be out of relplt->contents now.

To make things worse, the boundary check

    dyn < dyn + relplt->size / sizeof (*dyn)

is obviously wrong ("x + 10 < x"? :), causing the issue undetected
during the linking process and the resulted executable suddenly crashes
at runtime.

The issue was found during an attempt to add static-pie support to the
toolchain.

Fix it by iterating through the inputs of .rela.dyn to find the slot.

LoongArch: Don't write into GOT for local ifunc

Local ifuncs are always resolved at runtime via R_LARCH_IRELATIVE, so
there is no need to write anything into GOT.  And when we write the GOT
we actually trigger a heap-buffer-overflow: If a and b are different
sections, we cannot access something in b with "a->contents + (offset
from a)" because "a->contents" and "b->contents" are heap buffers
allocated separately, not slices of a large buffer.

So stop writing into GOT for local ifunc now.

Automatic date update in version.in

gprofng: build documentation only if BUILD_MAN is true

gprofng/ChangeLog
2022-09-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29476
* gprofng/Makefile.am: Build documentation only if BUILD_MAN is true
* gprofng/Makefile.in: Rebuild.
* gprofng/configure: Rebuild.

gdb: add ATTRIBUTE_PRINTF to gdb_bfd_error_handler

I see this error when building with clang,

  CXX    gdb_bfd.o
gdb_bfd.c:1180:43: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
  const std::string str = string_vprintf (fmt, ap_copy);
                                          ^~~
1 error generated.

This patch adds missing ATTRIBUTE_PRINTF to fix the error.

Tested on x86_64-linux with gcc 12 and clang 14.

Automatic date update in version.in

Automatic date update in version.in

[gdb/symtab] Fix "file index out of range" complaint

With the test-case included in this commit, we run into this FAIL:
...
(gdb) p var^M
During symbol reading: file index out of range^M
$1 = 0^M
(gdb) FAIL: gdb.dwarf2/dw2-no-code-cu.exp: p var with no complaints
...

This is a regression since commit 6d263fe46e0 ("Avoid bad breakpoints with
--gc-sections"), which contains this change in read_file_scope:
...
-  handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
+  if (lowpc != highpc)
+    handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
...

The change intends to avoid a problem with a check in
lnp_state_machine::check_line_address, but also prevents the file and dir
tables from being read, which causes the complaint.

Fix the FAIL by reducing the scope of the "lowpc != highpc" condition to the
call to dwarf_decode_lines in handle_DW_AT_stmt_list.

Tested on x86_64-linux.

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

Automatic date update in version.in

BFD error message suppression test case

This commit adds a GDB test case which tests GDB's BFD error handler
hook for suppressing output of all but the first identical messages.

See the comment at the beginning of bfd-errors.exp for details about
this new test.

I've tested this test for both 32- and 64-bit ELF files and also
on both little endian and big endian machines.  It also works for
both native and remote targets.  The only major restriction is that
it only works for ELF targets.

Suppress printing of superfluous BFD error messages

This commit adds a hook to the BFD error handler for suppressing
identical messages which have been output once already.

It's motivated by this Fedora bug...

https://bugzilla.redhat.com/show_bug.cgi?id=2083315

...in which over 900,000 BFD error messages are output when attaching
to firefox.  From the bug report, the messages all say:

BFD: /usr/lib/debug/usr/lib64/firefox/libxul.so-100.0-2.fc35.x86_64.debug: attempt to load strings from a non-string section (number 38)

Since there's no (additional) context which might assist the user in
determining what's wrong, there's really no point in outputting more
than one message.  Of course, if BFD should output some
other/different message, it should be output too, but all future
messages identical to those already output should be suppressed.

For the firefox problem, it turned out that there were only 37
sections, but something was referring to section #38.  I haven't
investigated further to find out how this came to be.

Despite this problem, useful debugging might still be done, especially
if the user doesn't care about debugging the problematic library.

If it turns out that knowing the quantity of messages might be useful,
I've implemented the suppression mechanism by keeping a count of each
identical message.  A new GDB command, perhaps a 'maintenance'
command, could be added to print out each message along with the
count.  I haven't implemented this though because I'm not convinced of
its utility.  Also, the BFD message printer has support for BFD-
specific format specifiers.  The BFD message strings that GDB stores
in its map are sufficient for distinguishing messages from each
other, but are not identical to those output by BFD's default error
handler.  So, that problem would need to be solved too.

[gdb/symtab] Handle named DW_TAG_unspecified_type DIE

With the test-case included in the patch, we run into:
...
(gdb) info types -q std::nullptr_t^M
During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'^M
^M
File /usr/include/c++/7/x86_64-suse-linux/bits/c++config.h:^M
2198:   typedef decltype(nullptr) std::nullptr_t;^M
(gdb) FAIL: gdb.dwarf2/nullptr_t.exp: info types -q std::nullptr_t \
  without complaint
...

Fix the complaint by handling DW_TAG_unspecified_type in new_symbol, and verify
in the test-case using "maint print symbols" that the symbol exists.

Tested on x86_64-linux, with gcc 7.5.0 and clang 13.0.

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

[gdb/tdep] Fix PowerPC IEEE 128-bit format arg passing

On a powerpc system with gcc 12 built to default to 128-bit IEEE long double,
I run into:
...
(gdb) print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)^M
$8 = 0 + 0i^M
(gdb) FAIL: gdb.base/varargs.exp: print \
  find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)
...

This is due to incorrect handling of the argument in ppc64_sysv_abi_push_param.

Fix this and similar cases, and expand the test-case to test handling of
homogeneous aggregates.

Tested on ppc64le-linux, power 10.

Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com>
Tested-by: Carl Love <cel@us.ibm.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29543

[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for aarch64

[ Another attempt at fixing the problem described in commit cd919f5533c
("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"). ]

When running the test-case gdb.dwarf2/dw2-dir-file-name.exp with
aarch64-linux, we run into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, compdir_missing__ldir_missing__file_basename () at \
  tmp-dw2-dir-file-name.c:999^M
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \
  compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
  compdir_missing__ldir_missing__file_basename
...

The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
address 0x400608 starts at a line entry:
...
CU: tmp-dw2-dir-file-name.c:
File name                    Line number    Starting address    View    Stmt
tmp-dw2-dir-file-name.c              999            0x400608               x
tmp-dw2-dir-file-name.c             1000            0x40062c               x
tmp-dw2-dir-file-name.c                -            0x40062c
...
and therefore the breakpoint is printed without instruction address.

In contrast, for x86_64-linux, we have the breakpoint printed with instruction
address:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x004004c1 in compdir_missing__ldir_missing__file_basename () \
  at tmp-dw2-dir-file-name.c:999^M
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
  compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
  compdir_missing__ldir_missing__file_basename
...

The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
address 0x004004c1 doesn't start at a line entry:
...
CU: tmp-dw2-dir-file-name.c:
File name                    Line number    Starting address    View    Stmt
tmp-dw2-dir-file-name.c              999            0x4004bd               x
tmp-dw2-dir-file-name.c             1000            0x4004d3               x
tmp-dw2-dir-file-name.c                -            0x4004d3
...

Fix this by:
- unifying behaviour between the archs by adding an explicit line number entry
  for the address compdir_missing__ldir_missing__file_basename_label, making
  the FAIL reproducible on x86_64-linux.
- expecting the breakpoint to be printed without instruction address.

Tested on x86_64-linux and aarch64-linux.

[gdb] Handle pending ^C after rl_callback_read_char

In completion tests in various test-cases, we've been running into these
"clearing input line" timeouts:
...
(gdb) $cmd^GPASS: gdb.gdb/unittest.exp: tab complete "$cmd"
FAIL: gdb.gdb/unittest.exp: tab complete "$cmd" (clearing input line) (timeout)
...
where $cmd == "maintenance selftest name_that_does_not_exist".

AFAIU, the following scenario happens:
- expect sends "$cmd\t"
- gdb detects the stdin event, and calls rl_callback_read_char until it
  comes to handle \t
- readline interprets the \t as completion, tries to complete, fails to do so,
  outputs a bell (^G)
- expect sees the bell, and proceeds to send ^C
- readline is still in the call to rl_callback_read_char, and stores the
  signal in _rl_caught_signal
- readline returns from the call to rl_callback_read_char, without having
  handled _rl_caught_signal
- gdb goes to wait for the next event
- expect times out waiting for "Quit", the expected reaction for ^C

Fix this by handling pending signals after each call to rl_callback_read_char.

The fix is only available for readline 8.x, if --with-system-readline provides
an older version, then the fix is disabled due to missing function
rl_check_signals.

Tested on x86_64-linux.

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

PowerPC64 pcrel got relocs against local symbols

Not that anyone would want to indirect via the GOT when an address can
be loaded directly with pla, the following:

 pld 3,x@got@pcrel
x:

leads to "Internal error in md_apply_fix", because the generic parts
of assembler fixup handling convert the fx_pcrel fixup to one without
a symbol.  Stop that happening.

* config/tc-ppc.c (ppc_force_relocation): Add PLT_PCREL34 and
assorted GOT_PCREL34 relocs.

pdb sanity check block_size

* pdb.c (pdb_get_elt_at_index): Only allow block_size to be
512, 1024, 2048, or 4096.

RISC-V: Make g imply zmmul extension.

bfd/
* elfxx-riscv.c (riscv_implicit_subset): Moved entry of m after g,
so that g can imply zmmul.
gas/
* testsuite/gas/riscv/attribute-01.d: Updated.
* testsuite/gas/riscv/attribute-02.d: Likewise.
* testsuite/gas/riscv/attribute-03.d: Likewise.
* testsuite/gas/riscv/attribute-04.d: Likewise.
* testsuite/gas/riscv/attribute-05.d: Likewise.
* testsuite/gas/riscv/attribute-10.d: Likewise.
* testsuite/gas/riscv/march-imply-g.d: Likewise.
* testsuite/gas/riscv/march-imply-unsupported.d: Likewise.

Automatic date update in version.in

bfd, binutils, gas: Remove/mark unused variables

Clang generates a warning on unused (technically, written but not read
thereafter) variables.  By the default configuration (with "-Werror"), it
causes a build failure (unless "--disable-werror" is specified).

This commit adds ATTRIBUTE_UNUSED attribute to some of them, which means
they are *possibly* unused (can be used but no warnings occur when
unused) and removes others.

bfd/ChangeLog:

* elf32-lm32.c (lm32_elf_size_dynamic_sections): Mark unused
rgot_count variable.
* elf32-nds32.c (elf32_nds32_unify_relax_group): Remove unused
count variable.
* mmo.c (mmo_scan): Mark unused lineno variable.

binutils/ChangeLog:

* windmc.c (write_rc): Remove unused i variable.

gas/ChangeLog:

* config/tc-riscv.c (riscv_ip): Remove unused argnum variable.

ld/ChangeLog:

* pe-dll.c (generate_reloc): Remove unused bi and page_count
variables.

gprofng: fix build issues on musl

gprofng/ChangeLog
2022-09-14  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29477
* configure.ac: Set __MUSL_LIBC.
* configure: Rebuild.
* common/config.h.in: Rebuild.
* src/collector_module.h: Fix compiler errors because mmap64, open64,
pwrite64 are macros and getcontext() is absent on musl.
* libcollector/collector.c: Likewise.
* libcollector/hwprofile.c: Likewise.
* libcollector/iolib.c: Likewise.
* libcollector/libcol_util.c: Likewise.
* libcollector/linetrace.c: Likewise.
* libcollector/memmgr.c: Likewise.
* libcollector/profile.c: Likewise.
* libcollector/unwind.c: Likewise.
* libcollector/dispatcher.c: Likewise.
* src/Experiment.cc: Likewise.
* libcollector/collector.h: Use dlsym() because dlvsym() is not defined
on musl.
* libcollector/iotrace.c: Remove interposition of versioned functions.
* libcollector/mmaptrace.c: Likewise.
* libcollector/libcol_util.h: Fix -Wint-to-pointer-cast warnings.
* libcollector/jprofile.c: Likewise.
* libcollector/synctrace.c: Include "collector.h".
* src/Print.cc: Use get_basename() because basename() is not defined
on musl.
* common/hwcdrv.c: Fix -Wformat= warnings.

Automatic date update in version.in

Binutils: Readelf testcase failing with clang

* testsuite/binutils-all/readelf.exp (readelf_wi_test): Extend
regexps to allow for output genreated by the Clang compiler.

looping in bfd_mach_o_fat_openr_next_archived_file

mach-o.c doesn't sanity check mach-o-fat archives, making it easy for
fuzzers to create an archive with mach_o_fat_archentry headers that
point to the same offset.  bfd_mach_o_fat_openr_next_archived_file
uses the previous element offset to find its header, and thus the next
element.  If two offsets are the same, any tool reading the archive
will get stuck.  This patch rejects such archives, and any with
overlapping elements.

* mach-o.c (overlap_previous): New function.
(bfd_mach_o_fat_archive_p): Sanity check that elements do not
overlap each other or the file and archive headers.

regen pofiles

bfd: Stop using -Wstack-usage=262144 when built with Clang

Some components of GNU Binutils will pass "-Wstack-usage=262144" when
"GCC >= 5.0" is detected.  However, Clang does not support "-Wstack-usage",
despite that related configuration part in bfd/warning.m4 handles the latest
Clang (15.0.0 as of this writing) as "GCC >= 5.0".

The option "-Wstack-usage" was ignored when the first version of Clang is
released but even this "ignoring" behavior is removed before Clang 4.0.0.
So, if we give Clang "-Wstack-usage=262144", it generates a warning, making
the build failure.

This commit checks "__clang__" macro to prevent adding the option if the
compiler is identified as Clang.

bfd/ChangeLog:

* warning.m4: Stop appending "-Wstack-usage=262144" option when
compiled with Clang.
* configure: Regenerate.

binutils/ChangeLog:

* configure: Regenerate.

gas/ChangeLog:

* configure: Regenerate.

gold/ChangeLog:

* configure: Regenerate.

gprof/ChangeLog:

* configure: Regenerate.

ld/ChangeLog:

* configure: Regenerate.

opcodes/ChangeLog:

* configure: Regenerate.

Modify ld-ctf test files to suit ARM

The "@" char starts a comment on ARM.

* testsuite/ld-ctf/diag-ctf-version-0.s: Replace @progbits with
%progbits.
* testsuite/ld-ctf/diag-ctf-version-2-unsupported-feature.s: Likewise.
* testsuite/ld-ctf/diag-ctf-version-f.s: Likewise.
* testsuite/ld-ctf/diag-cttname-invalid.s: Likewise.
* testsuite/ld-ctf/diag-cttname-null.s: Likewise.
* testsuite/ld-ctf/diag-cuname.s: Likewise.
* testsuite/ld-ctf/diag-decompression-failure.s: Likewise.
* testsuite/ld-ctf/diag-parlabel.s: Likewise.
* testsuite/ld-ctf/diag-parname.s: Likewise.
* testsuite/ld-ctf/diag-strlen-invalid.s: Likewise.
* testsuite/ld-ctf/diag-unsupported-flag.s: Likewise.
* testsuite/ld-ctf/diag-wrong-magic-number.s: Likewise.

asan: som_set_reloc_info heap buffer overflow

Also a bugfix.  The first time the section was read, the contents
didn't supply an addend.

* som.c (som_set_reloc_info): Sanity check offset.  Do process
contents after reading.  Tidy section->contents after freeing.

ubsan: som_is_space null dereference

On objcopy of fuzzed file.

* som.c (som_write_fixups): Exit loop if space sections all
processed.

msan: vms-alpha use-of-uninitialized-value in dst_retrieve_location

* vms-alpha.c (dst_define_location): Init any unused entries.

ubsan: arm-dis.c index out of bounds

We are way off in the weeds with this one, and will be printing
<UNPREDICTABLE> for S > 10.

* arm-dis.c (print_insn_cde): Wrap 'T' value.

PR29540, R_PPC64_NONE in .rela.dyn when linking Linux vdso

PR 29540
* elf64-ppc.c (allocate_dynrelocs): Don't alloc space for relocs
against discarded sections.
(ppc64_elf_size_dynamic_sections): Use standard test for discarded
sections.
* elf32-ppc.c (allocate_dynrelocs): Don't alloc space for relocs
against discarded sections.
(ppc_elf_size_dynamic_sections): Use standard test for discarded
sections.

Automatic date update in version.in

objdump: '-S' should trigger search for separate debuginfo.

Add with_source_code to the command line options that trigger
might_need_separate_debug_info and dump_any_debugging.  This helps
'objdump -S' download missing files via debuginfod without the need for
specifying extra command line options like '-L'.

gdb/testsuite: Update gdb.base/so-impl-ld.exp

gdb.base/so-impl-ld.exp was setup assuming that the compiler would add
epilogue information and that GDB would stop in the } line.  This would
make clang tests fail like so:

 step^M
 solib_main (arg=10000) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/solib1.c:7^M
 7|__  return arg*arg;|__|___/* HERE */^M
 (gdb) PASS: gdb.base/so-impl-ld.exp: step into solib call
 next^M
 main () at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.c:22^M
 22|_  return 0;^M
 (gdb) FAIL: gdb.base/so-impl-ld.exp: step in solib call
 next^M
 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6^M
 (gdb) FAIL: gdb.base/so-impl-ld.exp: step out of solib call

This patch changes it so solib_main has 2 lines where GDB can stop
regardless of compiler choices, and updates the exp file to
generically deal with unknown number of steps until leaving that
function.

gdb/testsuite: introduce gdb_step_until

Currently, GDB's testsuite uses a set amount of step commands to exit
functions. This is a problem if a compiler emits different epilogue
information from gcc, or emits no epilogue information at all. It was
most noticeable if Clang was used to test GDB.

To fix this unreliability, this commit introduces a new proc that will
step the inferior until it is stopped at a line that matches the given
regexp, or until it steps too many times - defined as an optional
argument. If the line is found, it shows up as a single PASS in the
test, and if the line is not found, a single FAIL is emitted.

This patch only introduces this proc, but does not add it to any
existing tests, these will be introduced in the following commit.

explicitly test for stderr in gdb.base/dprintf.exp

Not all compilers add stderr debug information when compiling a
program. Clang, for instance, prefers to add nothing from standard
libraries and let an external debug package have this information.
Because of this, gdb.base/dprintf.exp was failing when GDB attempted to
use dprintf as a call to fprintf(stderrr, ...), like this:

 (gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call
 continue
 Continuing.
 kickoff 1234
 also to stderr 1234
 'stderr' has unknown type; cast it to its declared type
 (gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout)

To avoid this false positive, we explicitly test to see if
the compiler has added information about stderr at all, and abort
testing dprintf as an fprintf call if it is unavailable.

Add pdb archive format

Resubmitted with changes in
https://sourceware.org/pipermail/binutils/2022-September/122791.html
made.

gdb/csky rm csky_print_registers_info

The reason for implementing this interface is that we want to print
GPR, PC, EPC, PSR and EPSR when the "info register" command
is executed.

A prev patch has added PC, EPC, PSR and EPSR to reggroup
general_group, the purpose has been achieved, so this function is
no longer required.

gdb/csky rm csky_memory_insert/remove_breakpoint

Software breakpoints are inserted or removed by the gdb stub via
remote protocol, these two functions are no longer needed.

gdb/csky add unwinder for long branch cases

There are two sequences of instructions for long branch:
1. jmpi [pc+4]    //insn code: 0xeac00001
   .long addr

2. lrw t1, [pc+8] //insn code: 0xea8d0002
   jmp t1         //insn code: 0x7834
   nop            //insn code: 0x6c03
   .long addr

gdbserver/csky add csky gdbserver support

Add new files:
  gdb/arch/csky.c
  gdb/arch/csky.h
  gdb/features/cskyv2-linux.c
  gdbserver/linux-csky-low.cc

1. In gdb/arch/csky.c file, add function "csky_create_target_description()"
for csky_target::low_arch_setup(). later, it can be used for csky native gdb.

2. In gdb/features/cskyv2-linux.c file, create target_tdesc for csky, include
gprs, pc, hi, lo, float, vector and float control registers.

3. In gdbserver/linux-csky-low.cc file, using PTRACE_GET/SET_RGESET to
get/set registers. The main data structures in asm/ptrace.h are:
struct pt_regs {
    unsigned long   tls;
    unsigned long   lr;
    unsigned long   pc;
    unsigned long   sr;
    unsigned long   usp;

    /*
     * a0, a1, a2, a3:
     * r0, r1, r2, r3
     */
    unsigned long   orig_a0;
    unsigned long   a0;
    unsigned long   a1;
    unsigned long   a2;
    unsigned long   a3;

    /*
     * r4 ~ r13
     */
    unsigned long   regs[10];

    /* r16 ~ r30 */
    unsigned long   exregs[15];

    unsigned long   rhi;
    unsigned long   rlo;
    unsigned long   dcsr;
};

struct user_fp {
    unsigned long   vr[96];
    unsigned long   fcr;
    unsigned long   fesr;
    unsigned long   fid;
    unsigned long   reserved;
};

Automatic date update in version.in

Use checked_static_cast in more places

I went through all the uses of dynamic_cast<> in gdb, looking for ones
that could be replaced with checked_static_cast.  This patch is the
result.  Regression tested on x86-64 Fedora 34.

ppc: Document the -mfuture and -Mfuture options and make them usable

The -mfuture and -Mfuture options which are used for adding potential
new ISA instructions were not documented.  They also lacked a bitmask
so new instructions could not be enabled by those options.  Fixed.

binutils/
* doc/binutils.texi: Document -Mfuture.

gas/
* config/tc-ppc.c: Document -mfuture
* doc/c-ppc.texi: Likewise.

include/
* opcode/ppc.h (PPC_OPCODE_FUTURE): Define.

opcodes/
* ppc-dis.c (ppc_opts) <future>: Use it.
* ppc-opc.c (FUTURE): Define.

add xfails to gdb.base/complex-parts.exp when testing with clang

clang doesn't add encoding to the name of complex variables, only says
that the type name is complex, making the relevant tests fail.
This patch adds the xfails to the tests that expect the variable name to
include it.

Fix gdb.base/call-ar-st to work with Clang

When running gdb.base/call-ar-st.exp against Clang, we see one FAIL,
like so:

 print_all_arrays (array_i=<main.integer_array>, array_c=<main.char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa
 ZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<main.float_array>, array_d=<main.double_array>) at ../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
 274       print_int_array(array_i);     /* -step1- */
 (gdb) FAIL: gdb.base/call-ar-st.exp: step inside print_all_arrays

With GCC we instead see:

 print_all_arrays (array_i=<integer_array>, array_c=<char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<float_array>, array_d=<double_array>) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
 274       print_int_array(array_i);     /* -step1- */
 (gdb) PASS: gdb.base/call-ar-st.exp: step inside print_all_arrays

The difference is that with Clang we get:

 array_i=<main.integer_array>, ...

instead of

 array_i = <integer_array>, ...

These symbols are local static variables, and "main" is the name of
the function they are defined in.  GCC instead appends a sequence
number to the linkage name:

 $ nm -A call-ar-st.gcc | grep integer_
 call-ar-st/call-ar-st:00000000000061a0 b integer_array.3968

 $ nm -A call-ar-st.clang | grep integer_
 call-ar-st:00000000004061a0 b main.integer_array

This commit changes the testcase to accept both outputs, as they are
functionally identical.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Iaf2ccdb9d5996e0268ed12f595a6e04b368bfcb4

fix gdb.base/access-mem-running.exp for clang testing

Clang was optimizing global_var away because it was not being used
anywhere. this commit fixes that by adding the attribute used it.

update gdb.base/info-program.exp to not fail with clang

The test specifically mentions that it doesn't care where the program
stops, however it was still testing for a specific location.  The clang
compiler emits different line information for epilogue, so GDB reports a
different stopping location, depending on the used compiler.  With this
patch the test works even with clang.

gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang

Clang organizes the variables differently to gcc in the original version
of this code, leading to the following differences when testing
p (int*) &dataglobal + 1

gcc:
$16 = (int *) 0x404034 <datalocal>

clang:
$16 = (int *) 0x404034 <dataglobal8>

However, since the important part of this test doesn't seem to be which
symbol is linked, but rather if GDB is correctly increasing the
address. This test was changed to actually measure address changes,
instead of assuming the ordering and naming of symbols.

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

ld: pe: Apply review suggestions on the existing exports/imports arrays

Use a separate explicit max_exports/imports field, instead of
deducing it from the number of allocated elements. Use a named
constant for the incremental growth of the array.

Use bool instead of int for boolean values.

Remove an unnecessary if statement/scope in the def_file_free
function.

Add more verbose comments about parameters, and about insertion
into an array of structs.

Generally use unsigned integers for all array indices and sizes.
The num_exports/imports fields are kept as is as signed integers,
since changing them to unsigned would require a disproportionate
amount of changes ti pe-dll.c to avoid comparisons between signed
and unsigned.

Simply use xrealloc instead of a check and xmalloc/xrealloc;
xrealloc can take NULL as the first parameter (and does a similar
check internally). (This wasn't requested in review though,
but noticed while working on the code.)

ld: pe: Improve performance of object file exclude symbol directives

Store the list of excluded symbols in a sorted list, speeding up
checking for duplicates when inserting new entries.

This is done in the same way as is done for exports and imports
(while the previous implementation was done with a linked list,
based on the implementation for aligncomm).

When linking object files with excluded symbols, there can potentially
be very large numbers of excluded symbols (just like builds with
exports can have a large number of exported symbols).

This improves the link performance somewhat, when linking with large
numbers of excluded symbols.

The later actual use of the excluded symbols within pe-dll.c
handles them via an unordered linked list still, though.

[gdb] Fix abort in selftest run_on_main_thread with ^C

When running selftest run_on_main_thread and pressing ^C, we can run into:
...
Running selftest run_on_main_thread.
terminate called without an active exception

Fatal signal: Aborted
...

The selftest function looks like this:
...
static void
run_tests ()
{
  std::thread thread;

  done = false;

  {
    gdb::block_signals blocker;

    thread = std::thread (set_done);
  }

  while (!done && gdb_do_one_event () >= 0)
    ;

  /* Actually the test will just hang, but we want to test
     something.  */
  SELF_CHECK (done);

  thread.join ();
}
...

The error message we see is due to the destructor of thread being called while
thread is joinable.

This is supposed to be taken care of by thread.join (), but the ^C prevents
that one from being called, while the destructor is still called.

Fix this by ensuring thread.join () is called (if indeed required) before the
destructor using SCOPE_EXIT.

Tested on x86_64-linux.

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

[gdb/symtab] Support .gdb_index section with TUs in .debug_info

The .gdb_index variant of commit d878bb39e41 ("[gdb/symtab] Support
.debug_names section with TUs in .debug_info").

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for ppc64le

In commit cd919f5533c ("[gdb/testsuite] Fix
gdb.dwarf2/dw2-dir-file-name.exp"), I made gdb.dwarf2/dw2-dir-file-name.exp
independent of prologue analyzers, using this change:
...
-       gdb_breakpoint $func
+       gdb_breakpoint *$func
...

That however caused a regression on ppc64le.  For PowerPC, as described in the
ELFv2 ABI, a function can have a global and local entry point.

Setting a breakpoint on *$func effectively creates a breakpoint for the global
entry point, so if the function is entered through the local entry point, the
breakpoint doesn't trigger.

Fix this by reverting commit cd919f5533c, and setting the breakpoint on
${func}_label instead.

Tested on x86_64-linux and ppc64le-linux.

[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp with clang

When running test-case gdb.dwarf2/dw2-dir-file-name.exp with clang, we run
into:
...
(gdb) break *compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400580^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x0000000000400580 in \
  compdir_missing.ldir_missing.file_basename ()^M
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \
  compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
  compdir_missing__ldir_missing__file_basename
...

The problem is that the test-case uses labels outside functions, which is know
to cause problem with clang, as documented in the comment for proc
function_range.

Fix this by using get_func_info instead.

Tested on x86_64-linux, with both gcc 7.5.0 and clang 13.0.0.

x86: avoid i386_dis_printf()'s staging area for a fair part of output

While PR binutils/29483 has now been addressed differently, this
originally proposed change still has its merits: Avoiding vsnprintf()
for typically far more than half of the overall output results in a 2-3%
performance gain in my testing (with debug builds of objdump, libbfd,
and libopcodes).

With that part of output no longer using staging_area[], the array also
doesn't need to be quite as large anymore (the largest presently used
size is 27, from "64-bit address is disabled").

While limiting the scope of "res" it became apparent that
- no caller cares about the function's return value,
- the comment about the return value was wrong,
- a particular positive return value would have been meaningless to the
  caller.
Therefore convert the function to return "void" at the same time.

RISC-V: PR28509, the default visibility symbol cannot be referenced by R_RISCV_JAL.

When generating the shared object, the default visibility symbols may bind
externally, which means they will be exported to the dynamic symbol table,
and are preemptible by default.  These symbols cannot be referenced by the
non-pic R_RISCV_JAL and R_RISCV_RVC_JUMP.  However, consider that linker
may relax the R_RISCV_CALL relocations to R_RISCV_JAL or R_RISCV_RVC_JUMP,
if these relocations are relocated to the plt entries, then we won't report
error for them.  Perhaps we also need the similar checks for the
R_RISCV_BRANCH and R_RISCV_RVC_BRANCH relocations.

After applying this patch, and revert the following glibc patch,
riscv: Fix incorrect jal with HIDDEN_JUMPTARGET
https://sourceware.org/git/?p=glibc.git;a=commit;h=68389203832ab39dd0dbaabbc4059e7fff51c29b

I get the expected errors as follows,
ld: relocation R_RISCV_RVC_JUMP against `__sigsetjmp' which may bind externally can not be used when making a shared object; recompile with -fPIC
ld: relocation R_RISCV_JAL against `exit' which may bind externally can not be used when making a shared object; recompile with -fPIC

Besides, we also have similar changes for libgcc,
RISC-V: jal cannot refer to a default visibility symbol for shared object
https://github.com/gcc-mirror/gcc/commit/45116f342057b7facecd3d05c2091ce3a77eda59

bfd/
pr 28509
* elfnn-riscv.c (riscv_elf_relocate_section): Report errors when
makeing a shard object, and the referenced symbols of R_RISCV_JAL
relocations are default visibility.  Besides, we should handle most
of the cases here, so don't need the unresolvable check later for
R_RISCV_JAL and R_RISCV_RVC_JUMP.
ld/
pr 28509
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/lib-nopic-01a.s: Removed.
* testsuite/ld-riscv-elf/lib-nopic-01b.d: Likewise.
* testsuite/ld-riscv-elf/lib-nopic-01b.s: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-01.d: New testcase.
* testsuite/ld-riscv-elf/shared-lib-nopic-01.s: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-02.d: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-02.s: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-03.d: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-03.s: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-04.d: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-04.s: Likewise.

Automatic date update in version.in

[gdb/symtab] Fix handling of DW_TAG_unspecified_type

Currently, the test-case contained in this patch fails:
...
(gdb) p (int) foo ()^M
Invalid cast.^M
(gdb) FAIL: gdb.dwarf2/dw2-unspecified-type.exp: p (int) foo ()
...
because DW_TAG_unspecified_type is translated as void.

There's some code in read_unspecified_type that marks the type as stub, but
that's only active for ada:
...
  if (cu->lang () == language_ada)
    type->set_is_stub (true);
...

Fix this by:
- marking the type as a stub for all languages, and
- handling the stub return type case in call_function_by_hand_dummy.

Tested on x86_64-linux.

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

Automatic date update in version.in

Re: PR29466, APP/NO_APP with linefile

It looks like I copied the SIZE init across from
binutils/testsuite/config/default.exp without some necessary editing.

* testsuite/config/default.exp (SIZE): Adjust relative path.

Automatic date update in version.in

Support debuginfo files with empty group sections.

PR 29532
bfd * elf.c (setup_group): Do not return false if there is no group
information available.

bionutils* objcopy.c (setup_section): Leave group sections intact when
creating separate debuginfo files.

RISC-V: Fix vector CSR requirements

Vector CSRs are also required on smaller vector subsets.

Not only that the most of vector CSRs are general purpose (and must be
accessible for every vector subsets), current minimum vector subset 'Zve32x'
requires fixed point arithmetic, making remaining non-general purpose
(fixed point arithmetic only) CSRs mandatory for such subsets.

So, those CSRs must be accessible from 'Zve32x', not just from 'V'.
This commit fixes this issue which caused CSR accessibility warnings.

gas/ChangeLog:

* config/tc-riscv.c (riscv_csr_address): Change vector CSR
requirement from 'V' to 'Zve32x'.
* testsuite/gas/riscv/csr-version-1p9p1.l: Change vector CSR
requirement from 'V' to 'Zve32x'.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.

Automatic date update in version.in

Fix hardware watchpoint check in test gdb.base/watchpoint-reuse-slot.exp

This test generates 48 failures on Power 9 when testing with HW watchpoints
enabled.  Note HW watchpoint support is disabled on Power 9 due to a HW bug.
The skip_hw_watchpoint_tests proc must be used to correctly determine
if the processor supports HW watchpoints.

This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
with the skip_hw_watchpoint_tests check.

This patch was tested on Power 9, Power 10 and X86-64 with no regressions.

Gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)

PR 29559
* dwarf2dbg.c (out_debug_info): Place DW_TAG_unspecified_type at
the end of the list of children, not at the start of the CU
information.
* testsuite/gas/elf/dwarf-3-func.d: Update expected output.
* testsuite/gas/elf/dwarf-5-func-global.d: Likewise.
* testsuite/gas/elf/dwarf-5-func-local.d: Likewise.
* testsuite/gas/elf/dwarf-5-func.d: Likewise.

gdbsupport: Fix config.status dependency

Commit 171fba11ab27 ("Make GDBserver abort on internal error in development mode")
created a new substitution CONFIG_STATUS_DEPENDENCIES but this is used by
Makefile.in (which is not regenerated by that commit).  After regenerating
it, it is found that CONFIG_STATUS_DEPENDENCIES value is not valid, making
gdbsupport fail to build.

Since the CONFIG_STATUS_DEPENDENCIES value is used in the Makefile, macro
substitution must have a Makefile format but commit 171fba11ab27 used shell
format "$srcdir/../bfd/development.sh".

This commit fixes this issue by substituting "$srcdir" (shell format) to
"$(srcdir)" (Makefile format).  It preserves the dependency as Pedro
intended and fixes the build problem.

It also regenerates corresponding files with the maintainer mode.

gdbsupport/ChangeLog:

* configure.ac: Fix config.status dependency.
* Makefile.in: Regenerate.
* configure: Regenerate.

Maintainer mode: wrong gettext version?

* README-maintainer-mode: Update minimum version  of gettext
required.

i686-w64-mingw32-objdump -WL returns incorrect file paths

PR 29523
* dwarf.c (display_debug_lines_decoded): Correctly handle DWARF-5
directory and filename tables.

Automatic date update in version.in

[gdb/testsuite] xfail gdb.ada/O2_float_param.exp for aarch64 and gcc 7.5.0

On aarch64-linux, with gcc 7.5.0, we run into:
...
 (gdb) frame^M
 #0  callee.increment (val=99.0, val@entry=9.18340949e-41, msg=...) at \
   callee.adb:21^M
 21            if Val > 200.0 then^M
 (gdb) FAIL: gdb.ada/O2_float_param.exp: scenario=all: frame
...

The problem is a GCC bug, filed as "PR98148 - [AArch64] Wrong location
expression for function entry values" (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148 ).

Xfail the test for aarch64 and gcc 7.

Tested on x86_64-linux and aarch64-linux.

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

[gdb/testsuite] Fix gdb.ada/access_tagged_param.exp for aarch64

On aarch64-linux, I run into:
...
Breakpoint 2, pck.inspect (obj=0x430eb0 \
  <system.pool_global.global_pool_object>, <objL>=0) at pck.adb:17^M
17         procedure Inspect (Obj: access Top_T'Class) is^M
(gdb) FAIL: gdb.ada/access_tagged_param.exp: continue
...
while on x86_64-linux, I see:
...
Breakpoint 2, pck.inspect (obj=0x62b2a0, <objL>=2) at pck.adb:19^M
19            null;^M
(gdb) PASS: gdb.ada/access_tagged_param.exp: continue
...
Note the different line numbers, 17 vs 19.

The difference comes from the gdbarch_skip_prologue implementation.

The amd64_skip_prologue implementation doesn't use gcc line numbers, and falls
back to the architecture-specific prologue analyzer, which correctly skips
past the prologue, to address 0x4022f7:
...
00000000004022ec <pck__inspect>:
  4022ec:       55                      push   %rbp
  4022ed:       48 89 e5                mov    %rsp,%rbp
  4022f0:       48 89 7d f8             mov    %rdi,-0x8(%rbp)
  4022f4:       89 75 f4                mov    %esi,-0xc(%rbp)
  4022f7:       90                      nop
  4022f8:       90                      nop
  4022f9:       5d                      pop    %rbp
  4022fa:       c3                      ret
...

The aarch64_skip_prologue implementation does use gcc line numbers, which are:
...
File name                    Line number    Starting address    View    Stmt
pck.adb                               17            0x402580               x
pck.adb                               17            0x402580       1       x
pck.adb                               19            0x40258c               x
pck.adb                               20            0x402590               x
...
and which are represented like this internally in gdb:
...
INDEX  LINE   ADDRESS            IS-STMT PROLOGUE-END
0      17     0x0000000000402580 Y
1      17     0x0000000000402580 Y
2      19     0x000000000040258c Y
3      20     0x0000000000402590 Y
4      END    0x00000000004025a0 Y
...

The second entry is interpreted as end-of-prologue, so 0x402580 is used, while
the actual end of the prologue is at 0x40258c:
...
0000000000402580 <pck__inspect>:
  402580:       d10043ff        sub     sp, sp, #0x10
  402584:       f90007e0        str     x0, [sp, #8]
  402588:       b90007e1        str     w1, [sp, #4]
  40258c:       d503201f        nop
  402590:       d503201f        nop
  402594:       910043ff        add     sp, sp, #0x10
  402598:       d65f03c0        ret
  40259c:       d503201f        nop
...

Note that the architecture-specific prologue analyzer would have gotten this
right:
...
(gdb) p /x aarch64_analyze_prologue (gdbarch, pc, pc + 128, 0)
$2 = 0x40258c
...

Fix the FAIL by making the test-case more robust against problems in prologue
skipping, by setting the breakpoint on line 19 instead.

Likewise in a few similar test-cases.

Tested on x86_64-linux and aarch64-linux.

Fix endianness handling for arm record self tests

v2:

- Add 32-bit Arm instruction selftest
- Refactored abstract memory reader into abstract instruction reader
- Adjusted code to use templated type and to use host endianness as
  opposed to target endianness.

The arm record tests handle 16-bit and 32-bit thumb instructions, but the
code is laid out in a way that handles the 32-bit thumb instructions as
two 16-bit parts.

This is fine, but it is prone to host-endianness issues given how the two
16-bit parts are stored and how they are accessed later on. Arm is
little-endian by default, so running this test with a GDB built with
--enable-targets=all and on a big endian host will run into the following:

Running selftest arm-record.
Process record and replay target doesn't support syscall number -2036195
Process record does not support instruction 0x7f70ee1d at address 0x0.
Self test failed: self-test failed at ../../binutils-gdb/gdb/arm-tdep.c:14482

It turns out the abstract memory reader class is more generic than it needs to
be, and we can simplify the code a bit by assuming we have a simple instruction
reader that only reads up to 4 bytes, which is the length of a 32-bit
instruction.

Instead of returning a bool, we return instead the instruction that has been
read. This way we avoid having to deal with the endianness conversion, and use
the host endianness instead. The Arm selftests can be executed on non-Arm
hosts.

While at it, Tom suggested adding a 32-bit Arm instruction selftest to increase
the coverage of the selftests.

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

Co-authored-by: Tom de Vries <tdevries@suse.de>

[gdb/testsuite] Use prototype to call libc functions

On openSUSE Tumbleweed (using glibc 2.36), I run into:
...
(gdb) print /d (int) munmap (4198400, 4096)^M
Invalid cast.^M
(gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: \
  get integer valueof "(int) munmap (4198400, 4096)"
...

The problem is that after starting the executable, the symbol has type
"void (*) (void)":
...
(gdb) p munmap
$1 = {<text variable, no debug info>} 0x401030 <munmap@plt>
(gdb) start
  ...
(gdb) p munmap
$2 = {void (void)} 0x7ffff7feb9a0 <__GI_munmap>
...
which causes the "Invalid cast" error.

Looking at the debug info for glibc for symbol __GI_munmap:
...
 <0><189683>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <189691>   DW_AT_name        : ../sysdeps/unix/syscall-template.S
    <189699>   DW_AT_producer    : GNU AS 2.39.0
<1><1896ae>: Abbrev Number: 2 (DW_TAG_subprogram)
    <1896af>   DW_AT_name        : __GI___munmap
    <1896b3>   DW_AT_external    : 1
    <1896b4>   DW_AT_low_pc      : 0x10cad0
    <1896bc>   DW_AT_high_pc     : 37
...
that's probably caused by this bit (or similar bits for other munmap aliases).

This is fixed in gas on trunk by commit 5578fbf672e ("GAS: Add a return type
tag to DWARF DIEs generated for function symbols").

Work around this (for say gas 2.39) by explicitly specifying the prototype for
munmap.

Likewise for getpid in a couple of other test-cases.

Tested on x86_64-linux.

LoongArch: fix gas BFD_RELOC_8/16/24 bug

If fixP->fx_subsy is NULL, BFD_RELOC_8/16/24 can't convert to
BFD_RELOC_LARCH_xxx.

gas/config/tc-loongarch.c

Automatic date update in version.in