Mach-O: i18n enablement on some error messages.

* config/obj-macho.c (obj_mach_o_get_section_names): Wrap two
string literals within with gettext macro.

ld: fix NEWS typos

ld/ChangeLog:

* NEWS: Fix 2 typos.

Add a link to the NEWS files in the release announcement email.

gdb/csky support .reg2 for kernel 4.x and later

When kernel's version >= 4.x, the size of .reg2 section will be 400.
Contents of .reg2 are {
    unsigned long vr[96];
    unsigned long fcr;
    unsigned long fesr;
    unsigned long fid;
    unsigned long reserved;
};

VR[96] means: (vr0~vr15) + (fr16~fr31), each Vector register is
128-bits, each Float register is 64 bits, the total size is
(4*96).

In addition, for fr0~fr15, each FRx is the lower 64 bits of the
corresponding VRx. So fr0~fr15 and vr0~vr15 regisetrs use the same
offset.

Automatic date update in version.in

[gdb/build] Fix build with gcc 4.8.5

When building with gcc 4.8.5, I run into:
...
user-regs.c:85:1: error: could not convert \
  ‘{0l, (& builtin_user_regs.gdb_user_regs::first)}’ from \
  ‘<brace-enclosed initializer list>’ to ‘gdb_user_regs’
 };
 ^
...

Fix this by removing the initialization and handling regs.last == nullptr in
append_user_reg.

Tested on x86_64-linux.

[gdb/symtab] Fix assert in read_addrmap_from_aranges

When loading the debug-names-duplicate-cu executable included in this
test-case, we run into:
...
(gdb) file debug-names-duplicate-cu^M
Reading symbols from debug-names-duplicate-cu...^M
src/gdb/dwarf2/read.c:2353: internal-error: read_addrmap_from_aranges: \
  Assertion `insertpair.second' failed.^M
...

This assert was added in recent commit 75337cbc147 ("[gdb/symtab] Fix
.debug_aranges duplicate offset warning").

The assert triggers because the CU table in the .debug_names section contains
a duplicate:
...
Version 5
Augmentation string: 47 44 42 00  ("GDB")
CU table:
[  0] 0x0
[  1] 0x0
...

Fix this by rejecting the .debug_names index:
...
(gdb) file debug-names-duplicate-cu^M
Reading symbols from debug-names-duplicate-cu...^M
warning: Section .debug_names has duplicate entry in CU table, \
  ignoring .debug_names.^M
...

Likewise for the case where the CU table is not sorted by increasing offset.

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

[gdb/testsuite] Add support for .debug_names in dwarf assembler

Add:
- support for a per-module .debug_names section in the dwarf assembler, and
- a test-case excercising this new functionality.

A per-module .debug_names section needs to have an entry in the CU list for
each CU in the module, which is made more difficult by two things:
- linking in other objects, which may contain additional CUs
  (typically the case on openSUSE), and
- adding dummy CUs in the dwarf assembler.
We handle this by:
- compiling with -nostartfiles (so the test-case contains _start rather than
  main), and
- disabling the dummy CU generation for the test-case.

I've kept things simple by having the test-case specify the hash value, rather
than adding that functionality in the dwarf assembler.

Also I've kept the bucket count to 1, which makes it trivial to satisfy the
requirement that "the symbol is entered into a bucket whose index is the hash
value modulo bucket_count".

The readelf dump of the .debug_names section from the test-case looks like:
...
Version 5
Augmentation string: 47 44 42 00  ("GDB")
CU table:
[  0] 0x0

TU table:

Foreign TU table:

Used 1 of 1 bucket.
Out of 2 items there are 1 bucket clashes (longest of 1 entries).

Symbol table:
[  0] #eddb6232 _start: <1> DW_TAG_subprogram DW_IDX_compile_unit=0
[  1] #0b888030 int: <2> DW_TAG_base_type DW_IDX_compile_unit=0
...

Tested on x86_64-linux.

Automatic date update in version.in

asan: heap buffer overflow in _bfd_error_handler

On coff_slurp_symbol_table printing "unrecognized storage class"
for a symbol error.  If the symbol name is the last string in its
section and not terminated, we run off the end of the buffer.

* coffgen.c (build_debug_section): Terminate the section with
an extra 0.

asan: segfault in coff_write_auxent_fname

More fuzzed input file nonsense.

* coffgen.c (coff_write_symbol): Don't call coff_write_auxent_fname
when extrap is NULL.

msan: bfd_mach_o_layout_commands use of uninitialised value

Catches fuzzed input with unterminated strings that later run off the
end of their buffers when calling strlen.

* mach-o.c: Use size_t vars where approprite.
(bfd_mach_o_alloc_and_read): Add "extra" param.  Allocate that
much extra and clear.  Update all callers, those that set up
strings with one extra byte.

objcopy section alignment

bfd_set_section_alignment currently always returns true.  This patch
changes it to return false on silly alignment values, avoiding yet
another way to trigger ubsan errors like coffcode.h:3192:12: runtime
error: shift exponent 299 is too large for 32-bit type 'int'.  We'll
catch that one in objcopy.c:setup_sections.  However, setup_sections
gives up on other setup operations that are necessary even after an
error of some sort.  Change that to keep going, which might change the
error message but that shouldn't matter in the least.

bfd/
* section.c (bfd_set_section_alignment): Return false and
don't set alignment_power for stupidly large alignments.
* bfd-in2.h: Regenerate.
* coffcode.h (coff_compute_section_file_positions): Don't use
an int constant when calculating alignment.
binutils/
* objcopy.c (setup_section): Keep on going after hitting
non-fatal errors.

ubsan: som.c undefined shift in som_set_reloc_info

Do the shift using unsigned variables to avoid UB on << 8.

* som.c (som_set_reloc_info): Make v unsigned.  Localise some
variables to their blocks.

Automatic date update in version.in

Get rid of BFD_VMA_FMT

Remove the BFD_VMA_FMT defines in bfd.h and configure support.

* bfd-in.h (BFD_VMA_FMT): Don't define.
* configure.ac (BFD_INT64_FMT): Remove configure test.
* configure.com: Likewise.
* Makefile.in: Regenerate.
* bfd-in2.h: Regenerate.
* configure: Regenerate.

Don't use BFD_VMA_FMT in gdb and sim

Like commit b82817674f, this replaces BFD_VMA_FMT "x" in sim/ with
PRIx64 and casts to promote bfd_vma to uint64_t.  The one file using
BFD_VMA_FMT in gdb/ instead now uses hex_string, and a typo in the
warning message is fixed.

[gdb/build] Fix build breaker in language.c with gcc 7.5.0

When building gdb on openSUSE Leap 15.3, using gcc 7.5.0, I run into:
...
gdb/language.c: In constructor ‘constexpr language_gdbarch::language_gdbarch()’:
gdb/language.c:921:8: error: use of deleted function \
  ‘language_arch_info::language_arch_info(const language_arch_info&)’
 struct language_gdbarch
        ^~~~~~~~~~~~~~~~
In file included from gdbsupport/common-defs.h:104:0,
                 from gdb/defs.h:28,
                 from gdb/language.c:31:
gdb/language.h:95:28: note: declared here
   DISABLE_COPY_AND_ASSIGN (language_arch_info);
                            ^
include/ansidecl.h:342:3: note: in definition of macro \
  ‘DISABLE_COPY_AND_ASSIGN’
   TYPE (const TYPE&) = delete;   \
   ^~~~
gdb/language.c: In function ‘language_gdbarch* get_language_gdbarch(gdbarch*)’:
gdb/language.c:936:22: note: synthesized method ‘constexpr \
  language_gdbarch::language_gdbarch()’ first required here
       l = new struct language_gdbarch;
                      ^~~~~~~~~~~~~~~~
...

This seems to be fixed by this change in the struct language_gdbarch
definition:
...
-  struct language_arch_info arch_info[nr_languages] {};
+  struct language_arch_info arch_info[nr_languages];
...

Tested on x86_64-linux.

[gdb] Add unit test for gdb::sequential_for_each

With commit 18a5766d09c ("[gdbsupport] Add sequential_for_each") I added a
drop-in replacement for gdb::parallel_for_each, but there's nothing making
sure that the two remain in sync.

Extend the unit test for gdb::parallel_for_each to test both.

Do this using a slightly unusual file-self-inclusion.  Doing so keep things
readable and maintainable, and avoids macrofying functions.

Tested on x86_64-linux.

[gdb/symtab] Use task size in parallel_for_each in dwarf2_build_psymtabs_hard

In dwarf2_build_psymtabs_hard, we use a parallel_for_each to distribute CUs
over threads.

Ensuring a fair distribution over the worker threads and main thread in terms
of number of CUs might not be the most efficient way, given that CUs can vary
in size.

Fix this by using per_cu->get_length () as the task size.

I've used this experiment to verify the performance impact:
...
$ for n in $(seq 1 10); do \
    time gdb -q -batch ~/firefox/libxul.so-93.0-1.1.x86_64.debug \
    2>&1 \
    | grep "real:"; \
  done
...
and without the patch got:
...
real: 4.71
real: 4.88
real: 4.29
real: 4.30
real: 4.65
real: 4.27
real: 4.27
real: 4.27
real: 4.75
real: 4.41
...
and with the patch:
...
real: 3.68
real: 3.81
real: 3.80
real: 3.68
real: 3.75
real: 3.69
real: 3.69
real: 3.74
real: 3.67
real: 3.74
...
so that seems a reasonable improvement.

With parallel_for_each_debug set to true, we get some more detail about
the difference in behaviour.  Without the patch we have:
...
Parallel for: n_elements: 2818
Parallel for: minimum elements per thread: 1
Parallel for: elts_per_thread: 704
Parallel for: elements on worker thread 0       : 705
Parallel for: elements on worker thread 1       : 705
Parallel for: elements on worker thread 2       : 704
Parallel for: elements on worker thread 3       : 0
Parallel for: elements on main thread           : 704
...
and with the patch:
...
Parallel for: n_elements: 2818
Parallel for: total_size: 1483674865
Parallel for: size_per_thread: 370918716
Parallel for: elements on worker thread 0       : 752   (size: 371811790)
Parallel for: elements on worker thread 1       : 360   (size: 371509370)
Parallel for: elements on worker thread 2       : 1130  (size: 372681710)
Parallel for: elements on worker thread 3       : 0     (size: 0)
Parallel for: elements on main thread           : 576   (size: 367671995)
...

Tested on x86_64-linux.

[gdbsupport] Add task size parameter in parallel_for_each

Add a task_size parameter to parallel_for_each, defaulting to nullptr, and use
the task size to distribute similarly-sized chunks to the threads.

Tested on x86_64-linux.

Introduce gdb::make_function_view

This adds gdb::make_function_view, which lets you create a function
view from a callable without specifying the function_view's template
parameter.  For example, this:

    auto lambda = [&] (int) { ... };
    auto fv = gdb::make_function_view (lambda);

instead of:

    auto lambda = [&] (int) { ... };
    gdb::function_view<void (int)> fv = lambda;

It is particularly useful if you have a template function with an
optional function_view parameter, whose type depends on the function's
template parameters.  Like:

    template<typename T>
    void my_function (T v, gdb::function_view<void(T)> callback = nullptr);

For such a function, the type of the callback argument you pass must
already be a function_view.  I.e., this wouldn't compile:

    auto lambda = [&] (int) { ... };
    my_function (1, lambda);

With gdb::make_function_view, you can write the call like so:

    auto lambda = [&] (int) { ... };
    my_function (1, gdb::make_function_view (lambda));

Unit tests included.

Tested by building with GCC 9.4, Clang 10, and GCC 4.8.5, on x86_64
GNU/Linux, and running the unit tests.

Change-Id: I5c4b3b4455ed6f0d8878cf1be189bea3ee63f626

Update following 2.39 release

asan: ppc64_elf_get_synthetic_symtab heap buffer overflow

Fuzzed input files with sizes of .dynamic not a multiple of dynamic
tag size can result in reading past the end of the buffer with the
current simple checks.  Fix that, and use the same check in other
files that process input object .dynamic section.  (There is no need
for buffer overflow checks in the linker's generated .dynamic
section.)

* elf32-ppc.c (ppc_elf_get_synthetic_symtab): Sanity check
.dynamic content buffer reads.
* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
* elf64-ia64-vms.c (elf64_vms_link_add_object_symbols): Likewise.
* elf.c (_bfd_elf_print_private_bfd_data): Simplify .dynamic
buffer sanity checks.
* elflink.c (elf_link_add_object_symbols): Avoid possible UB
subtracting sizeof_dyn from pointer.

Sanity check loc_offsets index

Fixes a segfault found by the fuzzers.

* dwarf.c (fetch_indexed_value): Return -1 on error.
(read_and_display_attr_value): Don't display string when
fetch_indexed_value returns an error.  Sanity check loc_offsets
index.

binutils/Dwarf: avoid "shadowing" of glibc function name

As before: Old enough glibc has an (unguarded) declaration of index()
in string.h, which triggers a "shadows a global declaration" warning.

gas: fix a testcase broken by new ZSTD support

The commit 1369522f36eece1b37139a81f7f2139ba3915172 ("Recognize the new ELF
compression type for ZSTD.") added the new ELF compression type but it
accidentally broke a GAS testcase.  Since testing for the section type
"2048" (SHF_COMPRESSED) is not going to be portable in the long term, it
now tests SHF_LINK_ORDER ("128") instead.

Using SHF_LINK_ORDER (with possibly sh_link == 0) is an idea by Jan Beulich.

gas/ChangeLog:

* testsuite/gas/elf/section10.s: Use SHF_LINK_ORDER to test
mixed numeric and alpha values.
* testsuite/gas/elf/section10.d: Reflect the change above.

When gas/read.c calls mbstowcs with a NULL destination, it should set size to 0

PR 29447
* read.c (read_symbol_name): Pass 0 as the length parameter when
invoking mbstowc in order to check the validity of a wide string.

[gdb] Add debug_{exp,val}

When debugging cc1 I heavily rely on simple one-parameter debug functions
that allow me to inspect a variable of a common type, like:
- debug_generic_expr
- debug_gimple_stmt
- debug_rtx
and I miss similar functions in gdb.

Add functions to dump variables of types 'value' and 'expression':
- debug_exp, and
- debug_val.

Tested on x86_64-linux, by breaking on varobj_create, and doing:
...
(gdb) call debug_exp (var->root->exp.get ())
&"Operation: OP_VAR_VALUE\n"
&" Block symbol:\n"
&"  Symbol: aaa\n"
&"  Block: 0x2d064f0\n"
(gdb)
...
and:
...
(gdb) call debug_val (value)
&"5"
(gdb)
...

Add gold support for --package-metadata option.

Following the same format as the implementation in ld:
9e2bb0cb5e74aed4158f08495534922d7108f928

Generate a .note.package FDO package metadata ELF note, following
the spec: https://systemd.io/ELF_PACKAGE_METADATA/

If the jansson library is available at build time (and it is explicitly
enabled), link ld to it, and use it to validate that the input is
correct JSON, to avoid writing garbage to the file. The
configure option --enable-jansson has to be used to explicitly enable
it (error out when not found). This allows bootstrappers (or others who
are not interested) to seamlessly skip it without issues.

elfcpp/
* elfcpp.h: Add FDO_PACKAGING_METADATA note type.

gold/
* Makefile.am: Add jansson flags and libraries.
* configure.ac: Check for jansson library.
* layout.cc (Layout::create_notes): Call create_package_metadata().
(Layout::create_package_metadata): New function.
* layout.h (Layout::create_package_metadata): New function.
(Layout::package_metadata_note_): New data member.
* options.h (class General_options): Add --package-metadata option.
* testsuite/Makefile.am (object_unittest): Add jansson libraries.
(binary_unittest): Likewise.
(leb128_unittest): Likewise.
(overflow_unittest): Likewise.
(package_metadata_test): New test.
* testsuite/package_metadata_main.c: New test source.

Recognize the new ELF compression type for ZSTD.

There is more work to be done to actually support compression and
decompression using the zstd library, but I will leave that to the
champions of the new compression option.

binutils/
* binutils/readelf.c (process_section_headers): Add support for
ELFCOMPRESS_ZSTD.

Automatic date update in version.in

Use registry in gdbarch

gdbarch implements its own registry-like approach.  This patch changes
it to instead use registry.h.  It's a rather large patch but largely
uninteresting -- it's mostly a straightforward conversion from the old
approach to the new one.

The main benefit of this change is that it introduces type safety to
the gdbarch registry.  It also removes a bunch of code.

One possible drawback is that, previously, the gdbarch registry
differentiated between pre- and post-initialization setup.  This
doesn't seem very important to me, though.

Allow registry to refer to const types

So far, the registry hasn't been used to refer to a 'const' type, but
this changes with the gdbarch change.  This patch arranges to let the
registry store a pointer-to-const, by removing const in the 'set'
method.

Use new and delete for gdbarch

This changes gdbarch to use new and delete.

Use bool in gdbarch

This changes gdbarch to use bool for initialized_p.

[gdb/testsuite] Fix .debug_aranges in gdb.dwarf2/fission-loclists.S

When running test-case gdb.dwarf2/fission-loclists.exp, I noticed:
...
warning: Section .debug_aranges in fission-loclists has duplicate \
  debug_info_offset 0x8f, ignoring .debug_aranges.^M
...

Fix this by removing the duplicate .debug_aranges entry.

Tested on x86_64-linux.

[gdb/testsuite] Fix ERROR in gdb.base/watchpoint-unaligned.exp

In PR23888 an error is reported:
...
ERROR: tcl error sourcing watchpoint-unaligned.exp.
ERROR: expected boolean value but got ""
    while executing
"if {$wpnum} {
...

This presumably happens when:
- skip_hw_watchpoint_tests returns 0 meaning hw watchpoints are supported
- gdb fails to set a hw watchpoint and instead sets a sw watchpoint

That particular situation is handled for arm:
...
    -re "Watchpoint (\[0-9\]+): .*\r\n$gdb_prompt $" {
        if {[istarget "arm*-*-*"]} {
            untested $test
            set wpnum 0
        }
    }
...
but not for any other targets so wpnum remains "", triggering the ERROR.

Possibly this has been fixed for powerpc by commit 8d4e4d13afb ("gdb Power 9
add test for HW watchpoint support."), but it's still possible for other
targets.

Fix this by:
- initializing wpnum to 0 instead of ""
- signalling the failure to set a hw watchpoint by a fail

Tested on x86_64-linux, also by adding:
...
gdb_test_no_output "set can-use-hw-watchpoints 0"
...
and verifying that it triggers the fail.

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

[gdb/tdep] Fix gdb.base/large-frame.exp for aarch64

On aarch64, I run into:
...
FAIL: gdb.base/large-frame.exp: optimize=-O0: backtrace
...

The problem is that the architecture-specific prologue analyzer fails to
handle the first two insns in the prologue properly:
...
0000000000400610 <func>:
  400610:       d2880210        mov     x16, #0x4010
  400614:       cb3063ff        sub     sp, sp, x16
  400618:       a9007bfd        stp     x29, x30, [sp]
  40061c:       910003fd        mov     x29, sp
  400620:       910043a0        add     x0, x29, #0x10
  400624:       97fffff0        bl      4005e4 <blah>
...
so we get:
...
$ gdb -q -batch ./outputs/gdb.base/large-frame/large-frame-O0 -ex "b func"
Breakpoint 1 at 0x400614
...

Fix this by:
- fixing the support for the first insn to extract the immediate operand, and
- adding support for the second insn,
such that we have:
...
Breakpoint 1 at 0x400624
...
Note that we're overshooting by one insn (0x400620 is the first insn after the
prologue), but that's a pre-existing problem.

Tested on aarch64-linux.

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

Don't use BFD_VMA_FMT in binutils

BFD_VMA_FMT can't be used in format strings that need to be
translated, because the translation won't work when the type of
bfd_vma differs from the machine used to compile .pot files.  We've
known about this for a long time, but patches slip through review.

So just get rid of BFD_VMA_FMT, instead using the appropriate PRId64,
PRIu64, PRIx64 or PRIo64 and SCN variants for scanf.  The patch is
mostly mechanical, the only thing requiring any thought is casts
needed to preserve PRId64 output from bfd_vma values, or to preserve
one of the unsigned output formats from bfd_signed_vma values.

Re: Get rid of fprintf_vma and sprintf_vma

Commit f493c2174e messed the formatting in linker map files,
particularly for 32-bit builds where a number of tests using map files
regressed.  I should have noticed the BFD64 conditional printing of
spaces to line up output due to the original %V printing hex vmas with
16 digits when BFD64 and 8 digits when not.  Besides that, it is nicer
to print 32-bit vmas for 32-bit targets.  So change %V back to be
target dependent, now using bfd_sprintf_vma.  Since minfo doesn't
return the number of chars printed, that means some places that
currently use %V must instead sprintf to a buffer in order to find the
length printed.

* ldmisc.h (print_spaces): Declare.
(print_space): Change to a macro.
* ldmisc.c (vfinfo): Use bfd_sprintf_vma for %V.  Tidy %W case.
(print_space): Delete.
(print_spaces): New function.
* emultempl/aix.em (print_symbol): Use print_spaces.
* ldctor.c (ldctor_build_sets): Likewise.
* ldmain.c (add_archive_element): Likewise.
* ldlang.c (print_one_symbol, lang_print_asneeded): Likewise.
(print_output_section_statement, print_data_statement): Likewise.
(print_reloc_statement, print_padding_statement): Likewise.
(print_assignment): Likewise.  Also replace %V printing of vmas
with printing to a buffer in order to properly format output.
(print_input_section, lang_one_common): Likewise.

MIPS: Use R_MIPS_REL16 for BFD_RELOC_16

R_MIPS_REL16 isn't a pc-relative reloc as the name might indicate.

* elf64-mips.c (mips_reloc_map): Map BFD_RELOC_16 to R_MIPS_REL16.
* elfn32-mips.c (mips_reloc_map): Likewise.

Automatic date update in version.in

elf: Reset alignment for each PT_LOAD segment

Reset alignment for each PT_LOAD segment to avoid using alignment from
the previous PT_LOAD segment.

bfd/

PR ld/29435
* elf.c (assign_file_positions_for_load_sections): Reset
alignment for each PT_LOAD segment.

ld/

PR ld/29435
* testsuite/ld-elf/pr29435.d: New file.
* testsuite/ld-elf/pr29435.s: Likewise.

Use unique_ptr to destroy per-bfd object

In some cases, the objfile owns the per-bfd object.  This is yet
another object that can sometimes be destroyed before the registry is
destroyed, possibly reslting in a use-after-free.  Also, I noticed
that the condition for deleting the object is not the same as the
condition used to create it -- so it could possibly result in a memory
leak in some situations.  This patch fixes the problem by introducing
a new unique_ptr that holds this object when necessary.

Use auto_obstack in objfile

This changes objfile to use an auto_obstack.  This helps prevent
use-after-free bugs, because it ensures that anything allocated on the
objfile obstack will live past the point at which the registry object
is destroyed.

Use gdb_bfd_ref_ptr in objfile

This changes struct objfile to use a gdb_bfd_ref_ptr.  In addition to
removing some manual memory management, this fixes a use-after-free
that was introduced by the registry rewrite series.  The issue there
was that, in some cases, registry shutdown could refer to memory that
had already been freed.  This help fix the bug by delaying the
destruction of the BFD reference (and thus the per-bfd object) until
after the registry has been shut down.

gprofng: fix bug 29410 - Argument "&nbsp;0." isn't numeric in numeric gt (>)

gprofng/Changelog:
2022-08-02  Ruud van der Pas  <ruud.vanderpas@oracle.com>

PR gprofng/29410
* gp-display-html/gp-display-html.in: Remove non-breaking spaces.

Fix a conflict between the linker's need to rename some PE format input libraries and the BFD library's file caching mechanism.

PR 29389
bfd * bfd.c (BFD_CLOSED_BY_CACHE): New bfd flag.
* cache.c (bfd_cache_delete): Set BFD_CLOSED_BY_DELETE on the
closed bfd.
(bfd_cache_lookup_worker): Clear BFD_CLOSED_BY_DELETE on the newly
reopened bfd.
* opncls.c (bfd_set_filename): Refuse to change the name of a bfd
that has been closed by bfd_cache_delete.  Mark changed bfds as
uncacheable.
* bfd-in2.h: Regenerate.

ld * ldlang.h (lang_input_statement_struct): Add sort_key field.
* emultempl/pe.em (after_open): If multiple import libraries refer
to the same bfd, store their names in the sort_key field.
* emultempl/pep.em (after_open): Likewise.
* ldlang.c (sort_filename): New function.  Returns the filename to
be used when sorting input files.
(wild_sort): Use the sort_filename function.

gdb/amd64: clean up unused variable

When building with clang 15, I got this,

  CXX    amd64-tdep.o
amd64-tdep.c:1410:13: error: variable 'insn' set but not used[-Werror,-Wunused-but-set-variable]
    gdb_byte *insn = insn_details->raw_insn + modrm_offset;
                ^
1 error generated.

The function that uses this variable has been removed in this commit,

commit 870f88f7551b0f2d6aaaa36fb684b5ff8f468107
Date:   Mon Apr 18 13:16:27 2016 -0400

    remove trivialy unused variables

Fix this by removing unused variable.

Tested by rebuilding on x86_64-linux with clang 15 and gcc 12.

gdb: Fix regression in varobj recreation

Commit bc20e562ec0 "Fix use after free in varobj" introduced a
regression.  This commit makes sure that the varobj object does not
keeps stale references to object being freed when we unload an objfile.
This includes the "valid_block" field which is reset to nullptr if the
pointed to block is tied to an objfile being freed.

However, at some point varobj_invalidate_iter might try to recreate
varobjs tracking either floating or globals.  Varobj tracking globals
are identified as having the "valid_block" field set nullptr, but as
bc20e562ec0 might clear this field, we have lost the ability to
distinguish between varobj referring to globals and non globals.

Fix this by introducing a "global" flag which tracks if a given varobj
was initially created as tracking a global.

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

Re: PE objdump -x

All of these buffer overrun tests are better written as a comparison
against size remaining, due to ISO C 9899 standard 6.5.2 para 8
regarding adding a constant to a pointer:

"If both the pointer operand and the result point to elements of the
same array object, or one past the last element of the array object,
the evaluation shall not produce an overflow; otherwise, the behavior
is undefined."

So "ex_dta + 4" might be undefined behaviour, if you interpret "the
array object" in this case to be the malloc'd section contents!

* pei-x86_64.c (pex64_get_unwind_info): Tidy sanity checks.
(pex64_xdata_print_uwd_codes): Likewise.

x86: improve/shorten vector zeroing-idiom optimization conditional

- Drop the rounding type check: We're past template matching, and none
  of the involved insns support embedded rounding.
- Drop the extension opcode check: None of the involved opcodes have
  variants with it being other than None.
- Instead check opcode space, even if just to be on the safe side going
  forward.
- Reduce the number of comparisons by folding two groups.

x86: properly mark i386-only insns

Just like all Size64 insns are marked Cpu64, all Size32 insns ought to
be marked Cpu386.

x86: also use D for MOVBE

First of all rename the meanwhile misleading Opcode_SIMD_FloatD, as it
has also been used for KMOV* and BNDMOV. Then simplify the condition
selecting which form if "reversing" to use - except for the MOV to/from
control/debug/test registers all extended opcode space insns use bit 0
(rather than bit 1) to indicate the direction (from/to memory) of an
operation. With that, D can simply be set on the first of the two
templates, while the other can be dropped.

Automatic date update in version.in

Add ELFCOMPRESS_ZSTD.

include/elf/
* common.h: Add ELFCOMPRESS_ZSTD.

fbsd-nat: Correct the return type of the have_regset method.

During the development of 40c23d880386d6e8202567eaa2a6b041feb1a652,
the return value of fbsd_nat_target::have_regset was changed from a
simple boolean to returning the size of the register set.  The
comments and callers were all updated for this change, but the actual
return type was accidentally left as a bool.  This change fixes the
return type to be a size_t.

Current callers of this only checked the value against 0 and thus
still worked correctly.

ELF: emit symbol table when there are relocations

Even when there are no symbols (e.g. all relocations being against
absolute values), a symbol table (with just the first placeholder entry)
needs to be emitted. Otherwise tools like objdump won't properly process
the relocations. The respective checks in assign_section_numbers() and
_bfd_elf_compute_section_file_positions() support also this view. Oddly
enough so far HAS_RELOC was only set when reading in an object file, but
not when generating one anew; the flag would only have been cleared when
no relocations were found (anymore).

While there also amend the affected function's leading comment to also
mention gas.

ld: aarch64: Adjust TLS relaxation condition

In aarch64_tls_transition_without_check and elfNN_aarch64_tls_relax we
choose whether to perform a relaxation to an IE access model or an LE
access model based on whether the symbol itself is marked as local (i.e.
`h == NULL`).

This is problematic in two ways.  The first is that sometimes a global
dynamic access can be relaxed to an initial exec access when creating a
shared library, and if that happens on a local symbol then we currently
relax it to a local exec access instead.  This usually does not happen
since we only relax an access if aarch64_can_relax_tls returns true and
aarch64_can_relax_tls does not have the same problem.  However, it can
happen when we have seen both an IE and GD access on the same symbol.
This case is exercised in the newly added testcase tls-relax-gd-ie-2.

The second problem is that deciding based on whether the symbol is local
misses the case when the symbol is global but is still non-interposable
and known to be located in the executable.  This happens on all global
symbols in executables.
This case is exercised in the newly added testcase tls-relax-ie-le-4.

Here we adjust the condition we base our relaxation on so that we relax
to local-exec if we are creating an executable and the relevant symbol
we're accessing is stored inside that executable.

-- Updating tests for new relaxation criteria

Many of the tests added to check our relaxation to IE were implemented
by taking advantage of the fact that we did not relax a global symbol
defined in an executable.

Since a global symbol defined in an executable is still not
interposable, we know that a TLS version of such a symbol will be in the
main TLS block.  This means that we can perform a stronger relaxation on
such symbols and relax their accesses to a local-exec access.

Hence we have to update all tests that relied on the older suboptimal
decision making.

The two cases when we still would want to relax a general dynamic access
to an initial exec one are:
1) When in a shared library and accessing a symbol which we have already
   seen accessed with an initial exec access sequence.
2) When in an executable and accessing a symbol defined in a shared
   library.

Both of these require shared library support, which means that these
tests are now only available on targets with that.

I have chosen to switch the existing testcases from a plain executable
to one dynamically linked to a shared object as that doesn't require
changing the testcases quite so much (just requires accessing a
different variable rather than requiring adding another code sequence).

The tls-relax-all testcase was an outlier to the above approach, since
it included a general dynamic access to both a local and global symbol
and inspected for the difference accordingly.

ld: aarch64: Update test linker scripts relocs.ld and relocs-ilp32.ld

The updates are to ensure that the .data section exists.  This means
that we always have a data section.  That means that we don't create a
RWX segment and avoid the corresponding warning.

We get this warning when testing aarch64-none-elf with -mcmodel=tiny.
N.b. this changes quite a few testcases from fail to pass.

arm: Add cfi expression support for ra_auth_code

This patch extends assembler support for the use of register names to
allow for pseudo-registers, e.g. ra_auth_code register.
This is done particularly with CFI directives in mind, allowing for
expressions of the type:

    .cfi_register ra_auth_code, 12

gas/Changelog:

* config/tc-arm.c (tc_arm_regname_to_dw2regnum): Add
REG_TYPE_PSEUDO handling.
* testsuite/gas/arm/cfi-pacbti-m-readelf.d: New.
* testsuite/gas/arm/cfi-pacbti-m.s: New.

arm: Use DWARF numbering convention for pseudo-register representation

This patch modifies the internal `struct reg_entry' numbering of DWARF
pseudo-registers to match values assigned in DWARF standards (see "4.1
DWARF register names" in [1])so ra_auth_code goes from 12 to 143 and
amends the unwinder .save directive-processing code to correctly handle
mixed register-type save directives.

The mechanism for splitting the register list is also re-written to
comply with register ordering on push statements, being that registers
are stored on the stack in numerical order, with the lowest numbered
register at the lowest address [2].

Consequently, the parsing of the hypothetical directive

        .save{r4-r7, r10, ra_auth_core, lr}

has been changed such as rather than producing

        .save{r4-r7, r10}
        .save{ra_auth_code}
        .save{lr}

as was the case with previous implementation, now produces:

        .save{lr}
        .save{ra_auth_code}
        .save{r4-r7, r10}

[1] <https://github.com/ARM-software/abi-aa/blob/main/aadwarf32/aadwarf32.rst>
[2] <https://developer.arm.com/documentation/dui0473/j/arm-and-thumb-instructions/push>

gas/Changelog:

* config/tc-arm.c (REG_RA_AUTH_CODE): New.
(parse_dot_save): Likewise.
(parse_reg_list): Remove obsolete code.
(reg_names): Set ra_auth_code to 143.
(s_arm_unwind_save): Handle core and pseudo-register lists via
parse_dot_save.
(s_arm_unwind_save_mixed): Deleted.
(s_arm_unwind_save_pseudo): Handle one register at a time.
* testsuite/gas/arm/unwind-pacbti-m-readelf.d: Fix test.
* testsuite/gas/arm/unwind-pacbti-m.d: Likewise.

PE objdump -x

objdump -x on PE executables produces lots of "xdata section corrupt"
and "corrupt unwind data" warnings, and refuses to dump that info.  It
turns out that the sanity checks were bad, not the data.  Fix them.

* pei-x86_64.c (pex64_get_unwind_info): Correct buffer overrun
sanity checks.
(pex64_xdata_print_uwd_codes): Similarly.

x86: XOP shift insns don't really allow B suffix

By mistake it was permitted to be used from the very introduction of XOP
support.

Automatic date update in version.in

ld: Support the -exclude-symbols option via COFF def files, with the EXCLUDE_SYMBOLS keyword

This was requested in review.

ld: Add support for a new option, -exclude-symbols, in COFF object file directives

This maps to the same as ld's --exclude-symbols command line option,
but allowing specifying the option via directives embedded in the
object files instead of passed manually on the command line.

[gdb/symtab] Fix .debug_aranges duplicate offset warning

The function read_addrmap_from_aranges contains code to issue a warning:
...
      if (!insertpair.second)
       {
         warning (_("Section .debug_aranges in %s has duplicate "
                    "debug_info_offset %s, ignoring .debug_aranges."),
                  objfile_name (objfile), sect_offset_str (per_cu->sect_off));
         return false;
       }
...
but the warning is in fact activated when all_comp_units has duplicate
entries, which is very misleading.

Fix this by:
- adding a test-case that should trigger the warning,
- replacing the current implementation of the warning with an
  assert that all_comp_units should not contain duplicates, and
- properly re-implementing the warning, such that it is triggered
  by the test-case.

Tested on x86_64-linux.

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

x86: SKINIT with operand needs IgnoreSize

Without it in 16-bit mode a pointless operand size prefix would be
emitted.

opcodes: LoongArch: add "ret" instruction to reduce typing

This syntactic sugar is present in both classical and emerging
architectures, like Alpha, SPARC and RISC-V, and assembler macros
doing the same thing can already be found in the wild e.g. [1], proving
the feature's popularity. It's better to provide support directly in the
assembler so downstream users wouldn't have to re-invent this over and
over again.

[1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/loongarch/sysdep.h;h=c586df819cd90;hb=HEAD#l28

opcodes: LoongArch: make all non-native jumps desugar to canonical b{lt/ge}[u] forms

Also re-order the jump/branch opcodes while at it, so that insns are
sorted in ascending order according to opcodes, and the label form
preceding the real definition.

Get rid of fprintf_vma and sprintf_vma

These two macros print either a 16 digit hex number or an 8 digit
hex number.  Unfortunately they depend on both target and host, which
means that the output for 32-bit targets may be either 8 or 16 hex
digits.

Replace them in most cases with code that prints a bfd_vma using
PRIx64.  In some cases, deliberately lose the leading zeros.
This change some output, notably in base/offset fields of m68k
disassembly which I think looks better that way, and in error
messages.  I've kept leading zeros in symbol dumps (objdump -t)
and in PE header dumps.

bfd/
* bfd-in.h (fprintf_vma, sprintf_vma, printf_vma): Delete.
* bfd-in2.h: Regenerate.
* bfd.c (bfd_sprintf_vma): Don't use sprintf_vma.
(bfd_fprintf_vma): Don't use fprintf_vma.
* coff-rs6000.c (xcoff_reloc_type_tls): Don't use sprintf_vma.
Instead use PRIx64 to print bfd_vma values.
(xcoff_ppc_relocate_section): Likewise.
* cofflink.c (_bfd_coff_write_global_sym): Likewise.
* mmo.c (mmo_write_symbols_and_terminator): Likewise.
* srec.c (srec_write_symbols): Likewise.
* elf32-xtensa.c (print_r_reloc): Similarly for fprintf_vma.
* pei-x86_64.c (pex64_dump_xdata): Likewise.
(pex64_bfd_print_pdata_section): Likewise.
* som.c (som_print_symbol): Likewise.
* ecoff.c (_bfd_ecoff_print_symbol): Use bfd_fprintf_vma.
opcodes/
* dis-buf.c (perror_memory, generic_print_address): Don't use
sprintf_vma.  Instead use PRIx64 to print bfd_vma values.
* i386-dis.c (print_operand_value, print_displacement): Likewise.
* m68k-dis.c (print_base, print_indexed): Likewise.
* ns32k-dis.c (print_insn_arg): Likewise.
* ia64-gen.c (_opcode_int64_low, _opcode_int64_high): Delete.
(opcode_fprintf_vma): Delete.
(print_main_table): Use PRIx64 to print opcode.
binutils/
* od-macho.c: Replace all uses of printf_vma with bfd_printf_vma.
* objcopy.c (copy_object): Don't use sprintf_vma.  Instead use
PRIx64 to print bfd_vma values.
(copy_main): Likewise.
* readelf.c (CHECK_ENTSIZE_VALUES): Likewise.
(dynamic_section_mips_val): Likewise.
(print_vma): Don't use printf_vma.  Instead use PRIx64 to print
bfd_vma values.
(dump_ia64_vms_dynamic_fixups): Likewise.
(process_version_sections): Likewise.
* rddbg.c (stab_context): Likewise.
gas/
* config/tc-i386.c (offset_in_range): Don't use sprintf_vma.
Instead use PRIx64 to print bfd_vma values.
(md_assemble): Likewise.
* config/tc-mips.c (load_register, macro): Likewise.
* messages.c (as_internal_value_out_of_range): Likewise.
* read.c (emit_expr_with_reloc): Likewise.
* config/tc-ia64.c (note_register_values): Don't use fprintf_vma.
Instead use PRIx64 to print bfd_vma values.
(print_dependency): Likewise.
* listing.c (list_symbol_table): Use bfd_sprintf_vma.
* symbols.c (print_symbol_value_1): Use %p to print pointers.
(print_binary): Likewise.
(print_expr_1): Use PRIx64 to print bfd_vma values.
* write.c (print_fixup): Use %p to print pointers.  Don't use
fprintf_vma.
* testsuite/gas/all/overflow.l: Update expected output.
* testsuite/gas/m68k/mcf-mov3q.d: Likewise.
* testsuite/gas/m68k/operands.d: Likewise.
* testsuite/gas/s12z/truncated.d: Likewise.
ld/
* deffilep.y (def_file_print): Don't use fprintf_vma.  Instead
use PRIx64 to print bfd_vma values.
* emultempl/armelf.em (gld${EMULATION_NAME}_finish): Don't use
sprintf_vma.  Instead use PRIx64 to print bfd_vma values.
* emultempl/pe.em (gld${EMULATION_NAME}_finish): Likewise.
* ldlang.c (lang_map): Use %V to print region origin.
(lang_one_common): Don't use sprintf_vma.
* ldmisc.c (vfinfo): Don't use fprintf_vma or sprintf_vma.
* pe-dll.c (pe_dll_generate_def_file): Likewise.
gdb/
* remote.c (remote_target::trace_set_readonly_regions): Replace
uses of sprintf_vma with bfd_sprintf_vma.

LoongArch: Set defaults to exec stack 0.

libctf: Avoid use of uninitialised variables

* ctf-link.c (ctf_link_add_ctf_internal): Don't free uninitialised
pointers.

PR29348, BFD_VMA_FMT wrong

There is a problem with my commit 0e3c1eebb2, which replaced
bfd_uint64_t with uint64_t: Some hosts typedef int64_t to long long
even when long is the same size as long long.  That confuses the code
choosing one of "l", "ll", or "I64" for BFD_VMA_FMT, and results in
warnings.

Write a direct configure test for the printf int64_t style instead.
This removes the last use of BFD_HOST_64BIT_LONG, so delete that.
Note that the changes to configure.com are pure guesswork.

PR 29348
* bfd-in.h (BFD_HOST_64BIT_LONG): Don't define.
(BFD_VMA_FMT): Define using BFD_INT64_FMT when 64-bit.
(bfd_vma, bfd_signed_vma): Move comments to 64-bit typedefs.
* configure.ac (BFD_HOST_64BIT_LONG): Delete.
(BFD_INT64_FMT): New config test.
* configure.com: Update similarly.
* Makefile.in: Regenerate.
* bfd-in2.h: Regenerate.
* configure: Regenerate.

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] Fix gdb.ada/literals.exp with aarch64

On aarch64-linux, I run into:
...
(gdb) print 16#ffffffffffffffff#^M
$7 = 18446744073709551615^M
(gdb) FAIL: gdb.ada/literals.exp: print 16#ffffffffffffffff#
...
while on x86_64-linux instead, I get:
...
(gdb) print 16#ffffffffffffffff#^M
$7 = -1^M
(gdb) PASS: gdb.ada/literals.exp: print 16#ffffffffffffffff#
...

We can easily reproduce this on x86_64-linux using:
...
$ gdb -q -batch -ex "set lang ada" -ex "set arch i386" \
  -ex "print 16#ffffffffffffffff#"
$1 = -1
$ gdb -q -batch -ex "set lang ada" -ex "set arch aarch64" \
  -ex "print 16#ffffffffffffffff#"
$1 = 18446744073709551615
...

With i386, we have:
...
(gdb) p int_bits
$3 = 32
(gdb) p long_bits
$4 = 32
(gdb) p long_long_bits
$5 = 64
...
and so in processInt we hit the fits-in-unsigned-long-long case where we use
as type long long:
...
      /* Note: Interprets ULLONG_MAX as -1.  */
      yylval.typed_val.type = type_long_long (par_state);
...

With aarch64, we have instead:
...
(gdb) p int_bits
$1 = 32
(gdb) p long_bits
$2 = 64
(gdb) p long_long_bits
$3 = 64
...
and so in processInt we hit the fits-in-unsigned-long case where we use
as type unsigned long:
...
      yylval.typed_val.type
        = builtin_type (par_state->gdbarch ())->builtin_unsigned_long;
...

It's not clear why for ada we're using long long for the
fits-in-unsigned-long-long case.

Fix this by using unsigned long long for the fits-in-unsigned-long-long case,
meaning the new reference output is 18446744073709551615 instead of -1.

Tested on x86_64-linux.

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

gdb/testsuite: add macros test for source files compiled in various ways

Using different ways of passing source file paths to compilers results n
different file and directory paths in the line header.  For example:

  - gcc foo.c
  - gcc ./foo.c
  - gcc ../cwd/foo.c
  - gcc $PWD/foo.c

Because of this, GDB sometimes failed to look up macros.  The previous
patch fixed that as much as possible.  This patch adds the corresponding
tests.

Add both a DWARF assembler-based test and a regular test.  The DWARF
assembled-based one tests some hard-coded debug info based on what I
have observed some specific versions of gcc and clang generate.  We want
to make sure that GDB keeps handling all these cases correctly, even if
it's not always clear whether they are really valid DWARF.  Also, they
will be tested no matter what the current target compiler is for a given
test run.

The regular test is compiled using the target compiler, so it may help
find bugs when testing against some other toolchains than what was used
to generate the DWARF assembler-based test.

For the DWARF assembler-based test, add to testsuite/lib/dwarf.exp the
necessary code to generate a DWARF5 .debug_macro section.  The design of
the new procs is based on what was done for rnglists and loclists.

To test against a specific compiler one can use this command, for
example:

    $ make check TESTS="gdb.base/macro-source-path.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang --target_board unix/gdb:debug_flags=-gdwarf-5"

Change-Id: Iab8da498e57d10cc2a3d09ea136685d9278cfcf6

gdb: remove code to prepend comp dir in buildsym_compunit::start_subfile

The bit of code removed by this patch was introduced to fix the same
kind of problem that the previous patch fixes.  That is, to try to match
existing subfiles when different name forms are used to refer to a same
file.

The thread for the patch that introduced this code is:

  https://pi.simark.ca/gdb-patches/45F8CBDF.9090501@hq.tensilica.com/

The important bits are that the compiler produced a compilation unit
with:

    DW_AT_name : test.c
    DW_AT_comp_dir : /home/maxim/W/BadgerPass/PR_14999

and DWARF v2 line table with:

    The Directory Table:
    /home/maxim/W/BadgerPass/PR_14999

    The File Name Table:
    Entry Dir Time Size Name
    1 1 1173897037 152 test.c

Because the main symtab was created with only DW_AT_name, it was named
"test.c".  And because the path built from the line header contained the
"directory" part, it was "/home/maxim/W/BadgerPass/PR_14999/test.c".
Because of this mismatch, thing didn't work, so they added this code to
prepend the compilation directory to the existing subfile names, so that
this specific case would work.

With the changes done earlier in this series, where subfiles are
identified using the "most complete path possible", this case would be
handled.  The main subfile's would be
"/home/maxim/W/BadgerPass/PR_14999/test.c" from the start
(DW_AT_comp_dir + DW_AT_name).  It's not so different from some DWARF 5
cases actually, which make the compilation directory explicit in the
line table header.

I therefore think that this code is no longer needed.  It does feel like
a quick hack to make one specific case work, and we have a more general
solution now.  Also, this code was introduced to work around a problem
in the DWARF debug info or the DWARF debug info reader.  In general, I
think it's preferable for these hacks to be located in the specific
debug info reader code, rather than in the common code.

Even though this code was added to work around a DWARF reader problem,
it's possible that some other debug info reader has started taking
advantage of this code in the mean time.  It's very difficult to
know or verify, but I think the likelyhood is quite small, so I'm
proposing to get rid of it to simplify things a little bit.

Change-Id: I710b8ec0d449d1b110d67ddf9fcbdb2b37108306

gdb: add "id" fields to identify symtabs and subfiles

Printing macros defined in the main source file doesn't work reliably
using various toolchains, especially when DWARF 5 is used.  For example,
using the binaries produced by either of these commands:

    $ gcc --version
    gcc (GCC) 11.2.0
    $ ld --version
    GNU ld (GNU Binutils) 2.38
    $ gcc test.c -g3 -gdwarf-5

    $ clang --version
    clang version 13.0.1
    $ clang test.c -gdwarf-5 -fdebug-macro

I get:

    $ ./gdb -nx -q --data-directory=data-directory a.out
    (gdb) start
    Temporary breakpoint 1 at 0x111d: file test.c, line 6.
    Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out

    Temporary breakpoint 1, main () at test.c:6
    6         return ZERO;
    (gdb) p ZERO
    No symbol "ZERO" in current context.

When starting to investigate this (taking the gcc-compiled binary as an
example), we see that GDB fails to look up the appropriate macro scope
when evaluating the expression.  While stopped in
macro_lookup_inclusion:

    (top-gdb) p name
    $1 = 0x62100011a980 "test.c"
    (top-gdb) p source.filename
    $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c"

`source` is the macro_source_file that we would expect GDB to find.
`name` comes from the symtab::filename field of the symtab we are
stopped in.  GDB doesn't find the appropriate macro_source_file because
the name of the macro_source_file doesn't match exactly the name of the
symtab.

The name of the main symtab comes from the compilation unit's
DW_AT_name, passed to the buildsym_compunit's constructor:

  https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630

The contents of DW_AT_name, in this case, is "test.c".  It is typically
(what I witnessed all compilers do) the same string that was passed to
the compiler on the command-line.

The name of the macro_source_file comes from the line number program
header's file table, from the call to the line_header::file_file_name
method:

  https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65

line_header::file_file_name prepends the directory path that the file
entry refers to, in the file table (if the file name is not already
absolute).  In this case, the file name is "test.c", appended to the
directory "/home/simark/build/binutils-gdb-one-target/gdb".

Because the symtab's name is not created the same way as the
macro_source_file's name is created, we get this mismatch.  GDB fails to
find the appropriate macro scope for the symtab, and we can't print
macros when stopped in that symtab.

To make this work, we must ensure that paths produced in these two ways
end up identical.  This can be tricky because of the different ways a
path can be passed to the compiler by the user.

Another thing to consider is that while the main symtab's name (or
subfile, before it becomes a symtab) is created using DW_AT_name, the
main symtab is also referred to using its entry in the line table
header's file table, when processing the line table.  We must therefore
ensure that the same name is produced in both cases, so that a call to
"start_subfile" for the main subfile will correctly find the
already-created subfile, created by buildsym_compunit's constructor.  If
we fail to do that, things still often work, because of a fallback: the
watch_main_source_file_lossage method.  This method determines that if
the main subfile has no symbols but there exists another subfile with
the same basename (e.g. "test.c") that does have symbols, it's probably
because there was some filename mismatch.  So it replaces the main
subfile with that other subfile.  I think that heuristic is useful as a
last effort to work around any bug or bad debug info, but I don't think
we should design things such as to rely on it.  It's a heuristic, it can
get things wrong.  So in my search for a fix, it is important that given
some good debug info, we don't end up relying on that for things to
work.

A first attempt at fixing this was to try to prepend the compilation
directory here or not prepend it there.  In practice, because of all the
possible combinations of debug info the compilers produce, it was not
possible to get something that would produce reliable, consistent paths.

Another attempt at fixing this was to make both macro_source_file
objects and symtab objects use the most complete form of path possible.
That means to prepend directories at least until we get an absolute
path.  In theory, we should end up with the same path in all cases.
This generally worked, but because it changed the symtab names, it
resulted in user-visible changes (for example, paths to source files in
Breakpoint hit messages becoming always absolute).  I didn't find this
very good, first because there is a "set filename-display" setting that
lets the user control how they want the paths to be displayed, and that
would suddenly make this setting completely ineffective (although even
today, it is a bit dependent on the debug info).  Second, it would
require a good amount of testsuite tweaks to make tests accept these
suddenly absolute paths.

This new patch is a slight variation of that: it adds a new field called
"filename_for_id" in struct symtab and struct subfile, next to the
existing filename field. The goal is to separate the internal ids used
for finding objects from the names used for presentation.  This field is
used for identifying subfiles, symtabs and macro_source_files
internally.  For DWARF symtabs, this new field is meant to contain the
"most complete possible" path, as discussed above.  So for a given file,
it must always be in the same form, everywhere.  The existing
symtab::filename field remains the one used for printing to the user, so
there shouldn't be any change in how paths are printed.

Changes in the core symtab files are:

 - Add "name_for_id" and "filename_for_id" fields to "struct subfile"
   and "struct symtab", next to existing "name" and "filename" fields.
 - Make buildsym_compunit::buildsym_compunit and
   buildsym_compunit::start_subfile accept a "name_for_id" parameter
   next to the existing "name" ones.
 - Make buildsym_compunit::start_subfile use "name_for_id" for looking
   up existing subfiles.  This is the key thing for making calls
   to start_subfile for the main source file look up the existing
   subfile successfully, and avoid relying on
   watch_main_source_file_lossage.
 - Make sal_macro_scope pass "filename_for_id", rather than "filename",
   to macro_lookup_inclusion.  This is the key thing to making the
   lookup work and macro printing work.

Changes in the DWARF files are:

 - Make line_header::file_file_name return the "most complete possible"
   name.  The only pre-existing user of this method is the macro code,
   to give the macro_source_file objects their name.  And we now want
   them to have this "most complete possible" name, which will match the
   corresponding symtab's "filename_for_id".
 - Make dwarf2_cu::start_compunit_symtab pass the "most complete
   possible" name for the main symtab's "filename_for_id".  In this
   context, where the info comes from the compilation unit's DW_AT_name
   / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if
   DW_AT_name is not already absolute.
 - Change dwarf2_start_subfile to build a name_for_id for the subfile
   being started.  The simplest way is to re-use
   line_header::file_file_name, since the callers always have a
   file_entry handy.  This ensures that it will get the exact same path
   representation as the macro code does, for the same file (since it
   also uses line_header::file_file_name).
 - Update calls to allocate_symtab to pass the "name_for_id" from the
   subfile.

Tests exercising all this are added by the following patch.

Of all the cases I tried, the only one I found that ends up relying on
watch_main_source_file_lossage is the following one:

    $ clang --version
    clang version 13.0.1
    Target: x86_64-pc-linux-gnu
    Thread model: posix
    InstalledDir: /usr/bin
    $ clang  ./test.c -g3 -O0 -gdwarf-4
    $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1"  a.out
    ...
    [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c
    [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c
    [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c
    [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c)
    [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile

As we can see, there are two forms used for "test.c", one with a "." and
one without.  This comes from the fact that the compilation unit DIE
contains:

    DW_AT_name ("test.c")
    DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb")

without a ".", and the line table for that file contains:

    include_directories[  1] = "."
    file_names[  1]:
               name: "test.c"
          dir_index: 1

When assembling the filename from that entry, we get a ".".

It is a bit unexpected that the main filename resulting from the line
table header does not match exactly the name in the compilation unit.
For instance, gcc uses "./test.c" for the DW_AT_name, which gives
identical paths in the compilation unit and in the line table header.

Similarly, with DWARF 5:

    $ clang  ./test.c -g3 -O0 -gdwarf-5

clang create two entries that refer to the same file but are of in a different
form.

    include_directories[  0] = "/home/simark/build/binutils-gdb-one-target/gdb"
    include_directories[  1] = "."
    file_names[  0]:
               name: "test.c"
          dir_index: 0
    file_names[  1]:
               name: "test.c"
          dir_index: 1

The first file name produces a path without a "." while the second does.
This is not caught by watch_main_source_file_lossage, because of
dwarf_decode_lines that creates a symtab for each file entry in the line
table.  It therefore appears as "non-empty" to
watch_main_source_file_lossage.  This results in two symtabs:

    (gdb) maintenance info symtabs
    { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00)
      { ((struct compunit_symtab *) 0x62100011aca0)
        debugformat DWARF 5
        producer clang version 13.0.1
        name test.c
        dirname /home/simark/build/binutils-gdb-one-target/gdb
        blockvector ((struct blockvector *) 0x621000129ec0)
        user ((struct compunit_symtab *) (null))
            { symtab test.c ((struct symtab *) 0x62100011ad20)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
            { symtab ./test.c ((struct symtab *) 0x62100011ad60)
              fullname (null)
              linetable ((struct linetable *) 0x621000129ef0)
            }
      }
    }

I am not sure what is the consequence of this, but this is also what
happens before my patch, so I think its acceptable to leave it as-is.

To handle these two cases nicely, I think we will need a function that
removes the unnecessary "." from path names, something that can be done
later.

Finally, I made a change in find_file_and_directory is necessary to
avoid breaking test

    gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42

Without that change, we would get:

    (gdb) info source
    Current source file is /dir/d/dw2-compdir-oldgcc42.S
    Compilation directory is /dir/d

whereas the expected result is:

    (gdb) info source
    Current source file is dw2-compdir-oldgcc42.S
    Compilation directory is /dir/d

This test was added here:

  https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html

Long story short, GCC <= 4.2 apparently had a bug where it would
generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S")
and no DW_AT_comp_dir.  The line table has one entry with filename
"dw2-compdir-oldgcc42.S", which refers to directory 0.  Directory 0
normally refers to the compilation unit's comp dir, but it is
non-existent in this case.

This caused some symtab lookup problems, and to work around them, some
workaround was added, which today reads as:

    if (res.get_comp_dir () == nullptr
        && producer_is_gcc_lt_4_3 (cu)
        && res.get_name () != nullptr
        && IS_ABSOLUTE_PATH (res.get_name ()))
      res.set_comp_dir (ldirname (res.get_name ()));

Source: https://gitlab.com/gnutools/binutils-gdb/-/blob/6577f365ebdee7dda71cb996efa29d3714cbccd0/gdb/dwarf2/read.c#L9428-9432

It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no
DW_AT_comp_dir and DW_AT_name is absolute.

Prior to my patch, a subfile would get created with filename
"/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get
created with filename "dw2-compdir-oldgcc42.S" from the line table's
file table.  Then watch_main_source_file_lossage would kick in and merge
them, keeping only the "dw2-compdir-oldgcc42.S" one:

    [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S
    [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S
    [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S
    [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S)
    [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile

And so "info source" would show "dw2-compdir-oldgcc42.S" as the
filename.

With my patch applied, but without the change in
find_file_and_directory, both DW_AT_name and the line table would try to
start a subfile with the same filename_for_id, and there was no need for
watch_main_source_file_lossage - which is what we want:

[symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S
[symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S
[symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S)
[symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S
[symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S)

But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming
from DW_AT_name, gets created first, it wins, and the symtab ends up
with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows
"/dir/d/dw2-compdir-oldgcc42.S" and the test breaks.

This is not wrong per-se, after all DW_AT_name is
"/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the
current source file as "/dir/d/dw2-compdir-oldgcc42.S".  If you compile
a file passing "/an/absolute/path.c", DW_AT_name typically contains (at
least with GCC) "/an/absolute/path.c" and GDB tells you that the source
file is "/an/absolute/path.c".  But we can also keep the existing
behavior fairly easily with a little change in find_file_and_directory.
When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now
modify the name to just keep the file part.  The result is coherent with
what compilers do when you compile a file by just passing its filename
("gcc path.c -g"):

      DW_AT_name        ("path.c")
      DW_AT_comp_dir    ("/home/simark/build/binutils-gdb-one-target/gdb")

With this change, filename_for_id is still the full name,
"/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile /
symtab (what ends up shown by "info source") is just
"dw2-compdir-oldgcc42.S", and that makes the test happy.

Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307

gdb/dwarf: pass a file_entry to line_header::file_file_name

In the following patch, there will be some callers of file_file_name
that will already have access to the file_entry object for which they
want the file name.  It would be inefficient to have them pass an index,
only for line_header::file_file_name to re-lookup the same file_entry
object.  Change line_header::file_file_name to accept a file_entry
object reference, instead of an index to look up.

I think this change makes sense in any case.  Callers that have an index
can first obtain a file_entry using line_header::file_name_at or
line_header::file_names.

When passing a file_entry object, we can assume that the file_entry's
index is valid, unlike when passing an index.  So, push the special case
about an invalid index to the sole current caller of file_file_name,
macro_start_file.  I think that error belongs there anyway, since it
specifically talks about "bad file number in macro information".

This requires recording the file index in the file_entry structure, so
add that.

Change-Id: Ic6e44c407539d92b7863d7ba82405ade17f384ad

gdb/dwarf: pass compilation directory to line header

The following patch changes line_header::file_file_name to prepend the
compilation directory to the file name, if needed.  For that, the line
header needs to know about the compilation directory.  Prepare for that
by adding a constructor that takes it as a parameter, and passing the
value down everywhere needed.  Add a second constructor for the special
case of building a line_header for doing a hash table lookup, since that
case doesn't require a compilation directory value.

Change-Id: Iba3ba0293e4e2d13a64b257cf9a3094684d54330

gdb: add debug prints in buildsym.c

Add a few debug prints in buildsym.c that were helpful to me in writing
this series.

Change-Id: If10a818feaee3ce1b78a2a254013b62dd578002b

gdb: introduce symtab_create_debug_printf

Introduce symtab_create_debug_printf and symtab_create_debug_printf_v,
to print the debug messages enabled by "set debug symtab-create".

Change-Id: I442500903f72d4635c2dd9eaef770111f317dc04

Automatic date update in version.in

[gdb/testsuite] Fix gdb.ada/convvar_comp.exp with broken debug info

On aarch64-linux I run into this failure with gcc 7.5.0:
...
(gdb) print $item.started^M
$1 = (-5312, 65535, 4202476)^M
(gdb) FAIL: gdb.ada/convvar_comp.exp: print $item.started
...

The test-case expects (0, 0, 0), but we're getting another value due to
incorrect location information.

Work around this by:
- first printing the value, and then
- verifying that the convenience variable matches the printed value.

I've verified that the test-case still checks what it should by disabling
the fix from commit cc0e770c0d0 ("memory error printing component of record
from convenience variable") and observing the test-case fail.

Tested on x86_64-linux and aarch64-linux.

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

Re: PR16005, avr linker crash on a particular instruction sequence with --relax

The last patch wasn't so clever.  The contents in fact have already
been read, just not cached where relax_delete_bytes expects them.
relax_delete_bytes also modifies relocs and syms, so they should be
cached too.

PR 16005
* elf32-avr.c (elf32_avr_relax_delete_bytes): Revert last change.
(elf32_avr_relax_section): Cache contents, relocs and syms
before calling relax_delete_bytes.

libopcodes/aarch64: add support for disassembler styling

This commit enables disassembler styling for AArch64.  After this
commit it is possible to have objdump style AArch64 disassembler
output (using --disassembler-color option).  Once the required GDB
patches are merged, GDB will also style the disassembler output.

The changes to support styling are mostly split between two files
opcodes/aarch64-dis.c and opcodes/aarch64-opc.c.

The entry point for the AArch64 disassembler can be found in
aarch64-dis.c, this file handles printing the instruction mnemonics,
and assembler directives (e.g. '.byte', '.word', etc).  Some operands,
mostly relating to assembler directives are also printed from this
file.  This commit changes all of this to pass through suitable
styling information.

However, for most "normal" instructions, the instruction operands are
printed using a two step process.  From aarch64-dis.c, in the
print_operands function, the function aarch64_print_operand is called,
this function is in aarch64-opc.c, and converts an instruction operand
into a string.  Then, back in print_operands (aarch64-dis.c), the
operand string is printed.

Unfortunately, the string returned by aarch64_print_operand can be
quite complex, it will include syntax elements, like '[' and ']', in
addition to register names and immediate values.  In some cases, a
single operand will expand into what will appear (to the user) as
multiple operands separated with a ','.

This makes the task of styling more complex, all these different
components need to by styled differently, so we need to get the
styling information out of aarch64_print_operand in some way.

The solution that I propose here is similar to the solution that I
used for the i386 disassembler.

Currently, aarch64_print_operand uses snprintf to write the operand
text into a buffer provided by the caller.

What I propose is that we pass an extra argument to the
aarch64_print_operand function, this argument will be a structure, the
structure contains a callback function and some state.

When aarch64_print_operand needs to format part of its output this can
be done by using the callback function within the new structure, this
callback returns a string with special embedded markers that indicate
which mode should be used for each piece of text.  Back in
aarch64-dis.c we can spot these special style markers and use this to
split the disassembler output up and apply the correct style to each
piece.

To make aarch64-opc.c clearer a series of new static functions have
been added, e.g. 'style_reg', 'style_imm', etc.  Each of these
functions formats a piece of text in a different style, 'register' and
'immediate' in this case.

Here's an example taken from aarch64-opc.c of the new functions in
use:

    snprintf (buf, size, "[%s, %s]!",
              style_reg (styler, base),
              style_imm (styler, "#%d", opnd->addr.offset.imm));

The aarch64_print_operand function is also called from the assembler
to aid in printing diagnostic messages.  Right now I have no plans to
add styling to the assembler output, and so, the callback function
used in the assembler ignores the styling information and just returns
an plain string.

I've used the source files in gas/testsuite/gas/aarch64/ for testing,
and have manually gone through and checked that the styling looks
reasonable, however, I'm not an AArch64 expert, so it is possible that
the odd piece is styled incorrectly.  Please point out any mistakes
I've made.

With objdump disassembler color turned off, there should be no change
in the output after this commit.

Stop the linker from complaining about unrecognised DW_FORM-rnglistx and DW_FORM_loclistx format attributes.

PR 29424
* dwarf2.c (read_attribute_value): Handle DW_FORM_rnglistx and
DW_FORM_loclistx.

PR16005, avr linker crash on a particular instruction sequence with --relax

It's possible for relax_delete_bytes to be called with section
contents NULL, as demonstrated by the testcase in this PR.

PR 16005
* elf32-avr.c (elf32_avr_relax_delete_bytes): Get section contents
if not already available.

x86: drop stray NoRex64 from KeyLocker insns

It's entirely unclear why some of the KeyLocker insns had NoRex64 on
them - there's nothing here which could cause emission of REX.W (except
of course a user-specified "rex.w", which we ought to honor anyway).

Arm64: re-work PR gas/27217 fix

The original approach has resulted in anomalies when . is involved in an
operand of one of the affected insns. We cannot leave . unresolved, or
else it'll be resolved at the end of assembly, then pointing to the
address of a section rather than at the insn of interest. Undo part of
the original change and instead check whether a relocation cannot be
omitted in md_apply_fix().

By resolving the expressions again, equates (see the adjustment of the
respective testcase) will now be evaluated, and hence relocations
against absolute addresses be emitted. This ought to be okay as long as
the equates aren't global (and hence can't be overridden). If a need
for such arises, quite likely the only way to address this would be to
invent yet another expression evaluation mode, leaving everything
_except_ . un-evaluated.

There's a further anomaly in how transitive equates are handled. In

.set x, 0x12345678
.eqv bar, x
foo:
adrp x0, x
add x0, x0, :lo12:x

adrp x0, bar
add x0, x0, :lo12:bar

the first two relocations are now against *ABS*:0x12345678 (as said
above), whereas the latter two relocations would be against x. (Before
the change here, the first two relocations are against x and the latter
two against bar.) But this is an issue seen elsewhere as well, and would
likely require adjustments in the target-independent parts of the
assembler instead of trying to hack around this for every target.

ld: Extend ac_default_ld_warn_rwx_segments to all SPARC targets [PR29411]

As discussed in PR ld/29411, the ld warning

[...] has a LOAD segment with RWX permissions

needs to be disabled on all SPARC targets, not just Solaris/SPARC: the
.plt section is required to be RWX by the 32-bit SPARC ELF psABI and the
64-bit SPARC Compliance Definition 2.4.1.  Given that ld only supports
SPARC ELF targets, this patch implements this.

Tested on sparc64-unknown-linux-gnu and sparc-sun-solaris2.11.

2022-07-28  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

ld:
PR ld/29411
* configure.tgt (ac_default_ld_warn_rwx_segments): Extend to all
sparc targets.  Expand comment.

[gdb/testsuite] Fix gdb.threads/killed-outside.exp on aarch64

On aarch64 (and likewise on arm), I run into:
...
(gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior
Executing on target: kill -9 11516    (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 11516^M
continue^M
Continuing.^M
Unable to fetch general registers: No such process.^M
(gdb) [Thread 0xfffff7d511e0 (LWP 11518) exited]^M
^M
Program terminated with signal SIGKILL, Killed.^M
The program no longer exists.^M
FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)
...
due to a mismatch between the actual "No such process" line and the expected
one:
...
set no_such_process_msg "Couldn't get registers: No such process\."
...

Fix this by updating the regexp.

Tested on aarch64-linux, and x86_64-linux.

RISC-V: Add `OP_V' to .insn named opcodes

This commit adds `OP_V' (OP-V: vector instruction opcode for now
ratified `V' extension) to .insn opcode name list.  Although vector
instruction encoding is not implemented in `.insn' directive, it will
help future implementation of custom vector `.insn'.

gas/ChangeLog:

* config/tc-riscv.c (opcode_name_list): Add `OP_V'.
* testsuite/gas/riscv/insn.s: Add testcase.
* testsuite/gas/riscv/insn.d: Likewise.
* testsuite/gas/riscv/insn-dwarf.d: Reflect insn.s update.

Automatic date update in version.in

Remove some unneeded checks in Guile code

The Guile code generally checks to see if an htab is non-null before
destroying it.  However, the registry code already ensures this, so we
can change these checks to asserts and simplify the code a little.

Change registry to use less memory

The registry code creates "registry_data" objects that hold the free
function and the index; then the registry keys refer to this object.
However, only the index is really useful, and now that registries have
a private implementation, just the index can be stored and we can
reduce the memory use of registries a little bit.  This also
simplifies the code somewhat.