gdb/dwarf: remove existing_cu parameter of load_full_comp_unit

Following the previous patch, all callers now pass the same thing:

    per_objfile->get_cu (this_cu)

Remove that parameter and to the call in the function itself.

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

gdb/dwarf: assume that source_cu->dies is always set in follow_die_offset

After staring at the code for a while, I got convinced that it's not
possible for cu->dies to be nullptr in follow_die_offset.  It might be a
leftover from the psymtab days.

In most cases, we see that the dwarf2_cu passedas `*ref_cu` has been
obtained by doing:

    per_objfile->get_cu (per_cu);

The only way for a dwarf2_cu to end up in the per_objfile like this is
through load_full_comp_unit or read_signatured_type.  Both of these
functions call `reader.read_all_dies ()` (which loads the DIEs in memory
and assigns dwarf2_cu::dies) before transferring the newly created
dwarf2_cu to the per_objfile.  So any dwarf2_cu obtained through

   per_objfile->get_cu (per_cu)

... will have its DIEs set.

The only case today I'm aware of of a dwarf2_cu without DIEs is in the
cooked indexer.  It creates a cutu_reader, but does not call
read_all_dies.  Instead, it gets the info_ptr from the cutu_reader and
reads the DIEs from the section buffer directly, on its own.  But this
is an entirely different code path that doesn't assign dwarf2_cu
objects to per_objfile.

So, remove the code path in follow_die_offset that tests for
`source_cu->dies == NULL`.  I added an assert at the top of the function
to verify that `source_cu->dies` is always non-nullptr, as a way to
test my hypothesis.  We could probably get rid of it, but I left it
there because it doesn't cost much to have it.

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

gdb/dwarf: rename local variables in follow_die_offset

Rename some local variables to better make the distinction between the
source and target CUs.

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

gdb/dwarf: remove unnecessary per_objfile parameter in cooked_indexer::ensure_cu_exists

The per_objfile object can be obtained from the cutu_reader.  This is
actually how both callers get it in order to pass it as argument.

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

gdb/dwarf: remove some _1 suffixes

These methods don't have (or no longer have) a counterpart without the
_1 suffix, so remove the suffix.

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

gdb/dwarf: remove cutu_reader::keep, add cutu_reader::release_cu

This is a bit subjective, but I often struggle to understand what
cutu_reader::keep is meant to do (keep what, where).  Perhaps it's just
a question of bad naming, but I think it's a bit confusing for
cutu_reader to transfer the ownership of the dwarf2_cu to the
per_objfile directly.

Add the cutu::release_cu method and make the caller of cutu_reader
transfer the ownership to the per_objfile object.

Right now, it is theoretically possible for release_cu to return
nullptr, so I made callers check the return value.  A patch later in
this series will change release_cu to ensure it always return
non-nullptr, so those callers will get simplified.

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

gdb/dwarf: change cutu_reader::read_die_and_siblings to cutu_reader::read_all_dies

After construction of a cutu_reader, only the top-level DIE has been
read in memory.  If the caller wants to access the full DIE tree, it
does:

    reader.top_level_die ()->child
      = reader.read_die_and_siblings (reader.top_level_die ());

I don't really like this poking into cutu_reader's data structures from
the outside, I would prefer if that work was done by cutu_reader.
Rename the read_die_and_siblings method to read_all_dies, and do that
work inside cutu_reader.

I also moved these operations inside the read_all_dies method:

    gdb_assert (cu->die_hash.empty ());
    cu->die_hash.reserve (cu->header.get_length_without_initial () / 12);

    ...

    cu->dies = reader.top_level_die ();

The rationale for this is that read_all_dies (and the functions it
calls) is responsible for filling the die_hash set.  So I think it makes
sense for it to do the reserve.

It is also cutu_reader's job, currently, to create and fill the fields
of dwarf2_cu.  So I think it makes sense for it to set cu->dies, after
having read the DIEs in memory.

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

gdb/dwarf: access m_info_ptr directly instead of passing info_ptr around

The few methods of cutu_reader that read DIEs into memory generally
receive an info_ptr that says where to start reading and return another
one (either by return value or parameter) indicating where the caller
should continue reading.

We can avoid all this passing around by having these methods access
m_info_ptr directly.  This allows changing some methods that read DIEs
to return `die_info *`, instead of returning it by parameter, which just
makes the code simpler to read, I think.

The only method that meaningfully reads and writes m_info_ptr (except
the places that initially set it up) is read_full_die_1.  It reads and
increments m_info_ptr once to read the abbrev and once again to read
each attribute.  Other methods use it for logging.

The methods cutu_reader::read_attribute and
cutu_reader::read_attribute_value do not touch m_info_ptr directly,
because they are used in cooked-indexer.c, which appears to read some
things in a non-linear fashion, unlike cutu_reader's DIE-reading
methods.  The cooked indexer calls cutu_reader::info_ptr to get the
m_info_ptr value just after the top-level DIE, and then it does its own
attribute reading after that.

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

gdb/dwarf: factor out to cutu_reader::skip_one_attribute method

I was reading cutu_reader::skip_one_die, and thought that the code to
skip one attribute made it quite difficult to read.  Factor this code
out to a new method, to get it out of the way.

As a bonus, it transforms one goto in a recursion call, which is also
easier to follow.  Unfortunately, I have no idea how to test
DW_FORM_indirect, as it doesn't seem to appear anywhere in the
testsuite, and I don't think that compilers often emit that.

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

gdb/dwarf: remove pretend_language parameter from load_full_{comp,type}_unit

I noticed that load_full_comp_unit and load_full_type_unit didn't use
their pretend_language parameter.  Remove them, and then remove more
things that were needed to get the language value to that point,
including the dwarf2_queue_item field.

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

gprof: only process line numbers for intersection of vmas and histograms

Some programs like RTOS firmware may have a large number of symbols.
The profile information in the profile data file includes histogram
records, which capture low PC and high PC of program execution.  If all
histogram records come in the profile data file before any call-graph
records and basic-block records, we can look up only the line numbers
within low PC and high PC in histogram records, which reduces processing
time for such a firmware from ~2 minutes to ~2 seconds.

Add symbol table access function, get_symtab, get_symtab_direct and
set_symtab to delay loading the symbol table until its first use.

* aarch64.c (aarch64_find_call): Call get_symtab to get the
symbol table pointer
* alpha.c (alpha_find_call): Likewise.
* basic_blocks.c (bb_read_rec): Likewise.
(bb_write_blocks): Likewise.
(print_exec_counts): Likewise.
(print_annotated_source): Likewise.
* call_graph.c (cg_tally): Likewise.
(cg_write_arcs): Likewise.
* cg_arcs.c (cycle_link): Likewise.
(propagate_flags): Likewise.
(cg_assemble): Likewise.
* cg_print.c (cg_print): Likewise.
(cg_print_index): Likewise.
(cg_print_function_ordering): Likewise.
* corefile.c: Include "gmon_io.h".
(core_create_syms_from): Call get_symtab_direct to get the
symbol table pointer.
(core_create_function_syms): Likewise.
(core_create_line_syms): Likewise.  If all histogram records
come in the profile data file before any call-graph records and
basic-block records, we can look up only the line numbers within
low PC and high PC in histogram records.
* gmon_io.c (gmon_histograms_first): New.
(gmon_out_read): Set gmon_histograms_first to true if all
histogram records come first.
(gmon_out_write): Call get_symtab to get the symbol table
pointer.
* hist.c (scale_and_align_entries): Likewise.
(hist_assign_samples_1): Likewise.
(hist_print): Likewise.
* i386.c (i386_find_call): Likewise.
* mips.c (mips_find_call): Likewise.
* sparc.c (sparc_find_call): Likewise.
* sym_ids.c (sym_id_parse): Likewise.
* vax.c (vax_find_call): Likewise.
* gmon_io.h (gmon_histograms_first): New.
* gprof.c (man): Don't create profile info.
(symtab_init): New.
* gprof.h (symtab_init): New.
* symtab.c (symtab): Changed to static.
(get_symtab_direct): New.
(get_symtab): Likewise.
(set_symtab): Likewise.
* symtab.h (symtab): Removed.
(get_symtab_direct): New.
(get_symtab): Likewise.
(set_symtab): Likewise.

Signed-off-by: Richard Allen <rsaxvc@gmail.com>
Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>

gas: permit wider-than-byte operands for .cfi_escape

Some DW_CFA_* and DW_OP_* take wider than byte, but non-LEB128 operands.
Having to hand-encode such when needing to resort to .cfi_escape isn't
very helpful.

gas: permit LEB128 operands for .cfi_escape

Many DW_CFA_* and DW_OP_* take LEB128 operands. Having to hand-encode
such when needing to resort to .cfi_escape isn't very helpful.

gas: make NO_LISTING work again

Presumably since no target enables this and there's also no configure
control, builds with NO_LISTING defined didn't really work anymore.
Convert fallback functions to macros and add #ifndef in a few places.
(Behavior is different for affected command line options vs directives:
The former are rejected as unrecognized, while the latter are silently
ignored. I think that's fair enough.)

gas: include .cfi_* generated data in listing

These are data generating directives not overly different from e.g.
.byte and .long. Whatever (directly) results from should also be
represented in the listing, if one was requested. It's just that the
output data is generated much later than the parsing of the directive
arguments.

gas: deal with the need for relocations from .cfi_{escape,fde_data}

Ignoring return values often isn't a good idea. The Sparc assembler in
particular would report an internal error if an expression with
relocation specifier is used with .cfi_escape, when the same works fine
with .byte. Propagate the relocation indicator up from
do_parse_cons_expression(), and eventually into emit_expr_with_reloc().

dot_cfi_fde_data(), only retaining the expression's X_add_number, would
require further work. Simply report the lack of support there. While
there, also check that what we were dealt is actually a constant.

Automatic date update in version.in

gdb/testsuite: fix undefined variable in gdb.ada/scalar_storage.exp

Commit:

  commit be382ece165eefa3e65f61bfb6b2aa2ee95dd6b4
  Date:   Wed Feb 12 09:35:26 2025 -0700

      Check for compiler support in scalar_storage.exp

Introduced an undefined variable use in gdb.ada/scalar_storage.exp,
fixed by this commit.

gdb/dwarf: keep going even if reading macro information fails

On Debian 12, with gcc 12 and ld 2.40, I get some failures when running:

    $ make check TESTS="gdb.base/style.exp" RUNTESTFLAGS="--target_board=fission"

I think I stumble on this bug [1], preventing the test from doing
anything that requires expanding the compilation unit:

    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
    Reading symbols from testsuite/outputs/gdb.base/style/style...
    (gdb) p main
    DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
    (gdb)

The error is thrown here:

    #0  0x00007ffff693f0a1 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
    #1  0x0000555569ce6852 in throw_it(return_reason, errors, const char *, typedef __va_list_tag __va_list_tag *) (reason=RETURN_ERROR, error=GENERIC_ERROR, fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", ap=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:203
    #2  0x0000555569ce690f in throw_verror (error=GENERIC_ERROR, fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", ap=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:211
    #3  0x000055556879c0cb in verror (string=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", args=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdb/utils.c:193
    #4  0x0000555569cfa88d in error (fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:45
    #5  0x000055556667dbff in dwarf2_section_info::read_string (this=0x61b000042a08, objfile=0x616000055e80, str_offset=262811, form_name=0x555562886b40 "DW_FORM_strp") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/section.c:211
    #6  0x00005555662486b7 in dwarf_decode_macro_bytes (per_objfile=0x616000056180, builder=0x614000006040, abfd=0x6120000f4b40, mac_ptr=0x60300004f5be "", mac_end=0x60300004f5bb "\002\004", current_file=0x62100007ad70, lh=0x60f000028bd0, section=0x61700008ba78, section_is_gnu=1, section_is_dwz=0, offset_size=4, str_section=0x61700008bac8, str_offsets_section=0x61700008baf0, str_offsets_base=std::optional<unsigned long> = {...}, include_hash=..., cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:511
    #7  0x000055556624af0e in dwarf_decode_macros (per_objfile=0x616000056180, builder=0x614000006040, section=0x61700008ba78, lh=0x60f000028bd0, offset_size=4, offset=0, str_section=0x61700008bac8, str_offsets_section=0x61700008baf0, str_offsets_base=std::optional<unsigned long> = {...}, section_is_gnu=1, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:934
    #8  0x000055556642cb82 in dwarf_decode_macros (cu=0x61700008b600, offset=0, section_is_gnu=1) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:19435
    #9  0x000055556639bd12 in read_file_scope (die=0x6210000885c0, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6366
    #10 0x0000555566392d99 in process_die (die=0x6210000885c0, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:5310
    #11 0x0000555566390d72 in process_full_comp_unit (cu=0x61700008b600, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:5075

The exception is then only caught at the event-loop level
(start_event_loop), causing the whole debug info reading process to be
aborted.  I think it's a little harsh, considering that a lot of things
could work even if we failed to read macro information.

Catch the exception inside read_file_scope, print the exception, and
carry on.  We could go even more fine-grained: if reading the string for
one macro definition fails, we could continue reading the macro
information.  Perhaps it's just that one macro definition that is
broken.  However, I don't need this level of granularity, so I haven't
attempted this.  Also, my experience is that macro reading fails when
the compiler or linker has a bug, in which case pretty much everything
is messed up.

With this patch, it now looks like:

    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
    Reading symbols from testsuite/outputs/gdb.base/style/style...
    (gdb) p main
    While reading section .debug_macro.dwo: DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
    $1 = {int (int, char **)} 0x684 <main>
    (gdb)

In the test I am investigating (gdb.base/style.exp with the fission
board), it allows more tests to run:

    -# of expected passes           107
    -# of unexpected failures       17
    +# of expected passes           448
    +# of unexpected failures       19

Of course, we still see the error about the macro information, and some
macro-related tests still fail (those would be kfailed ideally), but
many tests that are not macro-dependent now pass.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

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

gdb/testsuite: fail less catastrophically in gdb.base/style.exp

On Debian 12, with gcc 12 and ld 2.40, I get some failures when running:

    $ make check TESTS="gdb.base/style.exp" RUNTESTFLAGS="--target_board=fission"

I think I stumble on this bug [1], preventing to do the
disassembling that the test needs:

    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
    Reading symbols from testsuite/outputs/gdb.base/style/style...
    (gdb) x/1i *main
    DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
    (gdb)

The regexp in get_single_disassembled_insn fails to match, the insn
variable doesn't get set, and we get one of those unreadable TCL stack
traces:

    ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/style.exp.
    ERROR: tcl error code TCL READ VARNAME
    ERROR: can't read "insn": no such variable
        while executing
    "return $insn"
        (procedure "get_single_disassembled_insn" line 4)
        invoked from within
    "get_single_disassembled_insn"
        ("uplevel" body line 18)
        invoked from within
    "uplevel 1 $body"
        invoked from within
    ...

Check the return value of the regexp call, return an empty string on
failure.  Log a failure, so that we have a trace that something went
wrong, in case the tests done by the caller happen to pass by change.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

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

gcore/doc: fix mistake in the gcore man page

The gcore man page says that the default prefix for a generated core
file will be 'gcore', i.e. we'll create files like 'gcore.pid'.  In
reality the default is 'core'.

As far as I can tell, the default has been 'core' for years, and the
docs used to say that the default was 'core', but the docs were
changed by mistake in commit:

  commit 129eb0f1f16dc7a49799a024a7bcb109d954a1e7
  Date:   Fri Jul 27 00:52:23 2018 -0400

      Improve gcore manpage and clarify "-o" option

So, lets bring the docs back inline with the code.

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

gcore: add -h|--help options, and improve help/usage message output

Like the previous commit, this copies a lot from:

  commit fb2ded33c1e519659743047ed7817166545b6d91
  Date:   Fri Dec 20 12:46:11 2024 -0800

      Add gstack script

And adds -h | --help options to the gcore script, and smartens up the
help and usage output messages.

The usage text is now split over several lines (as it was getting a
bit long), and an input error suggests using `--help` instead of
printing the full usage string.

These changes bring gcore and gstack closer in behaviour.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>

gcore: add -v or --version option to show version number

Based on the work in this commit:

  commit fb2ded33c1e519659743047ed7817166545b6d91
  Date:   Fri Dec 20 12:46:11 2024 -0800

      Add gstack script

This commit adds a '-v' or '--version' option to the existing gcore
script.  This new option causes the script to print its version
number, and then exit.

I needed to adjust the getopts handling a little in order to support
the long form '--version' argument, but as this makes gcore more
consistent with gstack, then this seems like a good thing.

The usage message is now getting a little long.  Don't worry, I plan
to clean that up in the next commit.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>

[gdb/record] Fix out-of-bounds write in aarch64_record_asimd_load_store

After compiling gdb with -fstack-protector-all, and running test-case
gdb.reverse/getrandom.exp on aarch64-linux, we run into
"Stack smashing detected" in function aarch64_record_asimd_load_store.

This is reported in PR record/32784.

This happens due to an out-of-bounds write to local array record_buf_mem:
...
  uint64_t record_buf_mem[24];
...
when recording insn:
...
B+>0xfffff7ff4d10  st1     {v0.16b-v3.16b}, [x0]
...

We can fix this by increasing the array size to 128, but rather than again
hardcoding a size, reimplement record_buf_mem as std::vector.

Tested on aarch64-linux.

Approved-By: Guinevere Larsen <guinevere@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32784

[gdb/record] Support recording syscall accept4

While reviewing the enum gdb_syscall entries with values >= 500, I noticed
that gdb_sys_accept exists, but gdb_sys_accept4 doesn't, while recording
support is essentially the same, given that the difference in interface is
only an extra int parameter:
...
int accept (int sockfd, struct sockaddr *addr, socklen_t *addrlen);
int accept4 (int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags);
...

Fix this by:
- adding gdb_sys_accept4,
- supporting it in record_linux_system_call alongside gdb_sys_accept, and
- mapping to gdb_sys_accept4 in various syscall canonicalization functions.

The usual thing to do before the rewrite of i386_canonicalize_syscall would
have been to use the value from arch/x86/entry/syscalls/syscall_32.tbl:
...
  gdb_sys_accept4 = 364,
...
but that's no longer necessary, so instead we use some >= 500 value:
...
  gdb_sys_accept4 = 533,
...
to steer clear of the space where ppc_canonicalize_syscall and
s390_canonicalize_syscall do hard-coded number magic.

Tested on x86_64-linux, with and without target board unix/-m32, and
aarch64-linux.

Approved-By: Guinevere Larsen <guinevere@redhat.com>

[gdb/tdep] Rewrite i386_canonicalize_syscall

On openSUSE Tumbleweed x86_64, with target board unix/-m32 and test-case
gdb.reverse/recvmsg-reverse.exp, I run into:
...
(gdb) continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 360^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0xf7fc5575 in __kernel_vsyscall ()^M
(gdb) FAIL: $exp: continue to breakpoint: marker2
...

The syscall number 360 in i386 is for syscall socketpair, as we can see in
arch/x86/entry/syscalls/syscall_32.tbl:
...
<number>  <abi>  <name>      <entry point>
360       i386   socketpair  sys_socketpair
...

Function i386_canonicalize_syscall assumes that any syscall below 500 maps to
an identically valued enum in enum gdb_syscall:
...
static enum gdb_syscall
i386_canonicalize_syscall (int syscall)
{
  enum { i386_syscall_max = 499 };

  if (syscall <= i386_syscall_max)
    return (enum gdb_syscall) syscall;
  else
    return gdb_sys_no_syscall;
}
...

However, that's not the case.  The value of gdb_sys_socketpair is not 360,
but 512:
...
enum gdb_syscall {
  ...
  gdb_sys_getrandom = 355,
  gdb_sys_statx = 383,
  ...
  gdb_sys_socketpair = 512,
...

Consequently, when record_linux_system_call is called with
syscall == i386_canonicalize_syscall (360), we hit the default case here:
....
  switch (syscall)
    {
    ...
    default:
      gdb_printf (gdb_stderr,
                  _("Process record and replay target doesn't "
                    "support syscall number %d\n"), syscall);
      return -1;
      break;
    }
...
rather than hitting the case for gdb_sys_socketpair.

I initially wrote a trivial fix for this, changing the value of
gdb_sys_socketpair to 360.  However, Andreas Schwab pointed out that there are
other functions (ppc_canonicalize_syscall and s390_canonicalize_syscall) that
make assumptions about specific values of enum gdb_syscall, and fixing this
for i386 may break things for ppc or s390.

So instead, I decided to rewrite i386_canonicalize_syscall to match the
approach taken in aarch64_canonicalize_syscall, which allows
gdb_sys_socketpair to keep the same value.

So, fix this by:
- adding a new table file gdb/i386-syscalls.def, using a SYSCALL entry for
  each syscall, generated from arch/x86/entry/syscalls/syscall_32.tbl,
- using gdb/i386-syscalls.def to define enum i386_syscall, and
- using macros SYSCALL_MAP, SYSCALL_MAP_RENAME and UNSUPPORTED_SYSCALL_MAP to
  define the mapping from enum i386_syscall to enum gdb_syscall in
  i386_canonicalize_syscall.

I've created the mapping as follows:
- I used arch/x86/entry/syscalls/syscall_32.tbl to generate an initial mapping
  using SYSCALL_MAP for each syscall,
- I attempted to compile this and used the compilation errors about
  non-existing gdb_sys_ values to change those entries to
  UNSUPPORTED_SYSCALL_MAP, which got me a compiling version,
- I reviewed the UNSUPPORTED_SYSCALL_MAP entries, changing to
  SYSCALL_MAP_RENAME where necessary,
- I then reviewed syscalls below 500 that mapped to a gdb_syscall value below
  500, but not the same, and fixed those using SYSCALL_MAP_RENAME, and
- reviewed the mapping for gdb_syscall entries >= 500.

On the resulting mapping, I was able to do the following sanity check:
...
  for (int i = 0; i < 500; ++i)
    {
      int res = i386_canonicalize_syscall (i);
      if (res == i)
continue;
      if (res == -1)
continue;
      if (res >= 500)
continue;
      gdb_assert_not_reached ("");
    }
}
...
to make sure that any syscall below 500 either:
- maps to the same number,
- is unsupported, or
- maps to a number >= 500.

Coming back to our original problem, the socket pair syscall is addressed by
an entry:
...
      SYSCALL_MAP (socketpair);
...
which maps i386_sys_socketpair (360) to gdb_sys_socketpair (512).

Tested on x86_64-linux with target board unix/-m32.

Approved-By: Guinevere Larsen <guinevere@redhat.com>
PR tdep/32770
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32770

gdb/dwarf: use all_units_range in dwarf2_base_index_functions::expand_all_symtabs

Commit 292041562289 ("gdb/dwarf: use ranged for loop in some spots")
broke some tests notably gdb.base/maint.exp with the fission board.

    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/maint/maint -ex start -ex "maint expand-sym" -batch
    ...
    Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/break.c:43
    43          if (argc == 12345) {  /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */
    /usr/include/c++/14.2.1/debug/safe_iterator.h:392:
    In function:
        gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>&
        gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::operator++()
        [with _Iterator = gnu_cxx::
        normal_iterator<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>*,
        std::vector<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>,
        std::allocator<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter> > >
        >; _Sequence = std::debug::vector<std::unique_ptr<dwarf2_per_cu,
        dwarf2_per_cu_deleter> >; _Category = std::forward_iterator_tag]

    Error: attempt to increment a singular iterator.

Note that this is caught because I build with -D_GLIBCXX_DEBUG=1.
Otherwise, it might crash more randomly, or just not crash at all (but
still be buggy).

While iterating on the all_units vector, some type units get added
there:

    #0  add_type_unit (per_bfd=0x51b000044b80, section=0x50e0000c2280, sect_off=0, length=74, sig=4367013491293299229) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2576
    #1  0x00005555618a3a40 in lookup_dwo_signatured_type (cu=0x51700009b580, sig=4367013491293299229) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2664
    #2  0x00005555618ee176 in queue_and_load_dwo_tu (dwo_unit=0x521000120e00, cu=0x51700009b580) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8329
    #3  0x00005555618eeafe in queue_and_load_all_dwo_tus (cu=0x51700009b580) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8366
    #4  0x00005555618966a6 in dw2_do_instantiate_symtab (per_cu=0x50f0000043c0, per_objfile=0x516000065a80, skip_partial=true) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1695
    #5  0x00005555618968d4 in dw2_instantiate_symtab (per_cu=0x50f0000043c0, per_objfile=0x516000065a80, skip_partial=true) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1719
    #6  0x000055556189ac3f in dwarf2_base_index_functions::expand_all_symtabs (this=0x502000024390, objfile=0x516000065780) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1977

This invalidates the iterator in
dwarf2_base_index_functions::expand_all_symtabs, which is caught by the
libstdc++ debug mode.

I'm not entirely sure that it is correct to append type units from dwo
files to the all_units vector like this.  The
dwarf2_find_containing_comp_unit function expects a precise ordering of
the elements of the all_units vector, to be able to do a binary search.
Appending a type unit at the end at this point certainly doesn't respect
that ordering.

For now I'd just like to undo the regression.  Do that by using
all_units_range in the ranged for loop.  I will keep in mind to
investigate whether this insertion of type units in all_units after the
fact really makes sense or not.

Change-Id: Iec131e59281cf2dbd12d3f3d163b59018fdc54da

gdb/dwarf: remove unused parameter of create_dwo_cu_reader

Change-Id: I0c5b7591eab8e6616b653be7c04bc75159427ad6

gdb/dwarf: remove unnecessary braces

Change-Id: I3cd6b932d0dfb4cc07b6d48a1dc9ec35e7bfa03e

gdb/dwarf: use ranged for loop in some spots

I noticed that these loops could be written to avoid the iteration
variable `i`.

Change-Id: I8b58eb9913b6ac8505ee45eb8009ef7027236cb9

Automatic date update in version.in

gprofng: regenerate Makefile.in

Needed after 90803ffdcc4d8c3d17566bf8dccadbad312f07a9.

gprofng/ChangeLog
* src/Makefile.in: Regenerate.

gprofng: Fix cross-compilation binary name.

commit d25ba4596e85da6d8af78c88b5917e14763afbe1 create symbolic link
no care cross-compilation prefix.

gprofng/ChangeLog
2025-02-10  Zheng Junjie  <zhengjunjie@iscas.ac.cn>
* src/Makefile.am: create symbolic link respect cross-compilation.
* src/Makefile.in: Rebuild.

Use correct types in string-set.h

My earlier patch to introduce string-set.h used the wrong type in the
hash functions.  This patch fixes the error.

gdb: remove unused includes in exceptions.c

These are reported as unused by clangd.

Change-Id: I54b3fba4d7a73c955a9a26c0d340a384b2d37b32

gdb: remove trailing whitespaces in exceptions.c

Change-Id: Icc7b468b85c09a9721fc9580892c9ad424e0a29a

gdb: remove include from process-stratum-target.h

It is reported as unused by clangd.

Change-Id: I73c03577c521c1b71128409b5cf085a4d1785080

Automatic date update in version.in

Use gdb map in mi-cmds.c

This changes mi-cmds.c to use gdb::unordered_map.

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

Use gdb map in py-connection.c

This changes py-connection.c to use gdb::unordered_map.

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

Use gdb set in dwarf2/aranges.c

This changes dwarf2/aranges.c to use gdb::unordered_set.

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

Use gdb set in all_non_exited_process_targets

This changes all_non_exited_process_targets to return
gdb::unordered_set.

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

Use gdb set and map in remote.c

This changes remote.c to use gdb::unordered_set and
gdb::unordered_map.

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

Use gdb set and map in mi-main.c

This changes mi-main.c to use gdb::unordered_set and
gdb::unordered_map.

this may change the order of core ids that are emitted, but that seems
fine as MI generally doesn't guarantee ordering.

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

Use gdb::function_view in iterate_over_threads

This C++-ifies iterate_over_threads, changing it to accept a
gdb::function_view and to return bool.

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

Use gdb set and map in TUI

This changes the TUI to use gdb::unordered_map and gdb::unordered_set
rather than the std:: variants.

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

Use gdb set and map in source_cache

This changes source_cache to use gdb::unordered_map and
gdb::unordered_set rather than the std:: variants.

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

[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with glibc 2.41

On openSUSE Tumbleweed, with glibc 2.41, when running test-case
gdb.base/step-over-syscall.exp I run into:
...
(gdb) stepi^M
0x00007ffff7cfd09b in __abort_lock_rdlock () from /lib64/libc.so.6^M
1: x/i $pc^M
=> 0x7ffff7cfd09b <__abort_lock_rdlock+29>:     syscall^M
(gdb) p $eax^M
$1 = 14^M
(gdb) FAIL: $exp: fork: displaced=off: syscall number matches
FAIL: $exp: fork: displaced=off: find syscall insn in fork (timeout)
...

We're stepi-ing through fork trying to find the fork syscall, but encounter
another syscall.

The test-case attempts to handle this:
...
      gdb_test_multiple "stepi" "find syscall insn in $syscall" {
            -re ".*$syscall_insn.*$gdb_prompt $" {
                # Is the syscall number the correct one?
if {[syscall_number_matches $syscall]} {
                    pass $gdb_test_name
                } else {
    exp_continue
                }
            }
            -re "x/i .*=>.*\r\n$gdb_prompt $" {
                incr steps
                if {$steps == $max_steps} {
                    fail $gdb_test_name
                } else {
                    send_gdb "stepi\n"
                    exp_continue
                }
            }
        }
...
but fails to do so because it issues an exp_continue without issuing a new
stepi command, and consequently the "find syscall insn in fork" test times
out.

Also, the call to syscall_number_matches produces a PASS or FAIL, so skipping
one syscall would produce:
...
FAIL: $exp: fork: displaced=off: syscall number matches
PASS: $exp: fork: displaced=off: syscall number matches
DUPLICATE: $exp: fork: displaced=off: syscall number matches
...

Fix this by:
- not producing PASS or FAIL in syscall_number_matches, and
- issuing stepi when encountering another syscall.

While we're at it, fix indentation in syscall_number_matches.

Tested on x86_64-linux, specifically:
- openSUSE Tumbleweed (glibc 2.41), and
- openSUSE Leap 15.6 (glibc 2.38).

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

Automatic date update in version.in

Remove pid from test name in gcore-memory-usage.exp

The new gcore-memory-usage.exp test puts a PID into a test case name,
causing spurious comparison failures.  This patch changes the test
name to avoid this.

Add string cache and use it in cooked index

The cooked index needs to allocate names in some cases -- when
canonicalizing or when synthesizing Ada package names.  This process
currently uses a vector of unique_ptrs to manage the memory.

Another series I'm writing adds another spot where this allocation
must be done, and examining the result showed that certain names were
allocated multiple times.

To clean this up, this patch introduces a string cache object and
changes the cooked indexer to use it.  I considered using bcache here,
but bcache doesn't work as nicely with string_view -- because bcache
is fundamentally memory-based, a temporary copy of the contents must
be made to ensure that bcache can see the trailing \0.  Furthermore,
writing a custom class lets us avoid another copy when canonicalizing
C++ names.

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

Revert past commits

I accidentally pushed my work-in-progress branch... revert that.  Sorry
for the noise :(.

The list of commits reverted are:

    ae2a50a9ae15 attempt to revamp to the CU/TU list
    e9386435c94f gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles"
    6cbd64aa3eb0 gdb/dwarf: add dwarf_source_language_name
    32a187da7622 libiberty: move DW_LANG_* definitions to dwarf2.def
    b3fa38aef59d gdb/dwarf: move index unit vectors to debug names reader and use them
    30ba74418982 gdb/dwarf: track comp and type units count
    bedb4e09f292 gdb/dwarf: remove unnecessary braces
    b4f18de12c77 gdb/dwarf: use ranged for loop in some pots

Change-Id: I80aed2847025f5b15c16c997680783b39858a703

attempt to revamp to the CU/TU list

Change-Id: I1c8214413583d540c10c9a2322ef2a21f8bb54e7

gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles"

This was useful to me, to debug some problems.

Before printing cooked index entries, print a list of CUs and TUs.  The
information printed for each is a bit arbitrary, I took a look at the
types and printed what seemed relevant.

An example of output for a CU:

    [0] ((dwarf2_per_cu_data *) 0x50f000007840)
    type:       DW_UT_compile
    offset:     0x0
    size:       0x1bff
    artificial: false
    GDB lang:   c++
    DWARF lang: DW_LANG_C_plus_plus

And for a TU:

    [2] ((signatured_type *) 0x511000040000)
    type:      DW_UT_type
    offset:    0x0
    size:      0x94
    signature: 0x2e966c0dc94b065b

I moved the call to cooked_index_functions::wait before printing the
CU/TU list, otherwise trying to call "maint print objfiles" quickly,
like this, would lead to an internal error:

  $ ./gdb  -nx -q --data-directory=data-directory testsuite/outputs/gdb.dwarf2/struct-with-sig/struct-with-sig -ex "maint print objfiles"

This is because dwarf2_per_cu_data::m_unit_type was not yet set, when
trying to read it.  Waiting for the index to be built ensures that it is
set, since setting the unit type is done as a side-effect somewhere.

Change-Id: Ic810ec3bb4d3f5abb481cf1cee9b2954ff4f0874

gdb/dwarf: add dwarf_source_language_name

Add dwarf_source_language_name, to convert a DW_LANG_* constant to
string.  This will be used in a following patch.

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

libiberty: move DW_LANG_* definitions to dwarf2.def

In order to get a "DW_LANG_* to string" function:

  - move the "DW_LANG_*" definitions from dwarf2.h to dwarf2.def
  - add the necessary macros in dwarf2.h to generate the enumeration
  - add the necessary macros in dwarfnames.c to generate the "to string"
    function

include/ChangeLog:

* dwarf2.h (DW_LANG, DW_FIRST_LANG, DW_END_LANG): Define then
undefine.
(enum dwarf_source_language): Remove.
(get_DW_LANG_name): Declare.
* dwarf2.def: Define DW_LANG_* constants.

libiberty/ChangeLog:

* dwarfnames.c (DW_FIRST_LANG, DW_END_LANG, DW_LANG): Define
then undefine.

Change-Id: I440aa2b1f55c7585d7e44c8fa7c41310b0ef2b3a
Cc: binutils@sourceware.org

gdb/dwarf: move index unit vectors to debug names reader and use them

Since these vectors contain the CU and TU lists as found in the
.debug_names header, it seems like they are meant to be used by the
.debug_names reader when handling a DW_IDX_compile_unit or
DW_IDX_type_unit attribute.  The value of the attribute would translate
directly into an index into one of these vectors.

However there's something fishy: it looks like these vectors aren't
actually used in practice.  They are used in the
dwarf2_per_bfd::get_index_{c,t}u methods, which in turn aren't used
anywhere.

The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the
dwarf2_per_bfd::get_cu method, assuming that all compile units are
placed before type units in the dwarf2_per_bfd::all_units vector.  I see
several problems with that:

 1. I found out [1] that the dwarf2_per_bfd::all_units didn't always
    have the CUs before the TUs.  So indexing dwarf2_per_bfd::all_units
    with that assumption will not work.

 2. The dwarf2_find_containing_comp_unit function assumes an ordering of
    units by section offset (among other criteria) in order to do a
    binary search.  Even though it's probably commonly the case, nothing
    guarantees that the order of CUs and TUs in the .debug_names header
    (which defines the indices used to refer to them) will be sorted by
    section offset.  It's not possible to make
    dwarf2_find_containing_comp_unit (assuming it wants to do a binary
    search by section offset) and the DW_IDX_compile_unit /
    DW_IDX_type_unit handlers use the same vector.

 3. I have not tested this, but in the presence of a dwz supplementary
    file, the .debug_names reader should probably not put the units from
    the main and dwz files in the same vectors to look them up by index.
    Presumably, if both the main and dwz files have a .debug_names
    index, they have distinct CU / TU lists.  So, an CU index of 1 in an
    index entry in the main file would refer to a different CU than an
    index of 1 in an index entry in the dwz file.  The current code
    doesn't seem to account for that, it just indexes
    dwarf2_per_bfd::all_units.

Since those vectors are kind of specific to the .debug_names reader,
move them there, in the mapped_debug_names_reader struct.  Then, update
the handlers of DW_IDX_compile_unit and DW_IDX_type_unit to use them.

[1] https://inbox.sourceware.org/gdb-patches/87a5ab5i5m.fsf@tromey.com/T/#mbdcfe35f94db33e59500eb0d3d225661cab016a4

Change-Id: I3958d70bb3875268143471da745aa09336ab2500

gdb/dwarf: track comp and type units count

A subsequent commit will remove the all_comp_units and all_type_units
array views, since the all_units vector will no longer be segmented
between comp and type units.  Some callers still need to know the number
of each kind, so track that separately.

Change-Id: I6ef184767a96e5be095bbf9142aa850adbb083ac

gdb/dwarf: remove unnecessary braces

Change-Id: If0b38b860e79771a16ea914af3e337fca0ee3a7d

gdb/dwarf: use ranged for loop in some pots

I noticed that these loops could be written to avoid the iteration
variable `i`.

Change-Id: Ia3717acbbf732f0337870d35ac60fe6400383324

gdb/dwarf: save DWARF version in dwarf2_loclist_baton, remove it from dwarf2_per_cu

When running:

    $ make check TESTS="gdb.cp/cpexprs-debug-types.exp" RUNTESTFLAGS="--target_board=fission"

I get:

    (gdb) break -qualified main
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.h:295: internal-error: version: Assertion `m_dwarf_version != 0' failed.

The problem is that dwarf2_per_cu objects created in the
read_cutu_die_from_dwo code path never have their DWARF version set.  A
seemingly obvious solution would be to add a call to
dwarf2_per_cu::set_version in there (there's a patch in the referenced
PR that does that).  However, this comment in
read_comp_units_from_section is a bit scary:

      /* Init this asap, to avoid a data race in the set_version in
 cutu_reader::cutu_reader (which may be run in parallel for the cooked
 index case).  */
      this_cu->set_version (cu_header.version);

I don't know if a DWO file can be read while the cooked indexer runs, so
if it would be a problem here, but I prefer to be safe than sorry.  This
patch side-steps the problem by deleting the DWARF version from
dwarf2_per_cu.

The only users of dwarf2_per_cu::version are the loclists callbacks in
`loc.c`.  Add the DWARF version to dwarf2_loclist_baton and modify those
callbacks to get the version from there instead.  Initialize that new
field in fill_in_loclist_baton.

I like this approach because there is no version field that is possibly
unset now.

I wasn't keen on doing this at first because I thought it would waste
space, but the dwarf2_loclist_baton has 7 bytes of padding at the end
anyway, so we might as well use that.

Cc: Ricky Zhou <ricky@rzhou.org>
Cc: Tom de Vries <tdevries@suse.de>
Cc: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32309
Change-Id: I30d4ede7d67da5d80ff65c6122f5868e1098ec52
Approved-By: Tom Tromey <tom@tromey.com>

Use flags enum for cooked_index_entry::full_name

I found a small bug coming from a couple of  recent patches of mine for
cooked_index_entry::full_name.

First, commit aab26529b30 (Add "Ada linkage" mode to
cooked_index_entry::full_name) added a small hack to optionally
compute the Ada linkage name.

Then, commit aab2ac34d7f (Avoid excessive CU expansion on failed
matches) changed the relevant expand_symtabs_matching implementation
to use this feature.

However, the feature was used unconditionally, causing a bad side
effect: the non-canonical name is now used for all languages, not just
Ada.  But, for C++ this is wrong.

Furthermore, consider the declaration of full_name:

   const char *full_name (struct obstack *storage,
 bool for_main = false,
 bool for_ada_linkage = false,
   const char *default_sep = nullptr) const;

... and then consider this call in cooked_index::dump:

       gdb_printf ("    qualified:  %s\n",
  entry->full_name (&temp_storage, false, "::"));

Oops!  The "::" is silently converted to 'true' here.

To fix both of these problems, this patch changes full_name to accept
a flags enum rather than booleans.  This avoids the type-safety
problem.

Then, full_name is changed to remove the "Ada" flag when the entry is
not in fact an Ada symbol.

Regression tested on x86-64 Fedora 40.

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

Remove eval_op_scope

eval_op_scope is very similar to
scope_operation::evaluate_for_address.  This patch combines the two
into a single method of scope_operation.

Regression tested on x86-64 Fedora 40.

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

gdb/dwarf: rename comp_unit_die to top_level_die

The name "comp_unit_die" is a bit misleading, because it can also
represent a type unit (DW_TAG_type_unit).  I think that "top_level_die"
is clear.

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

gdb/dwarf: add doc for cutu_reader::is_dummy

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

Fix check-include-guards.py

I noticed that check-include-guards.py doesn't error in certain
situations -- but in situations where the --update flag would cause a
file to be changed.

This patch changes the script to issue an error for any discrepancy.
It also fixes the headers that weren't correct.

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

gprof: Append -l to tst-gmon-gprof-l.sh data files

Append -l to tst-gmon-gprof-l.sh data files to avoid conflicts with
tst-gmon-gprof.sh data files.

* testsuite/tst-gmon-gprof-l.sh (actual): Append -l.
(expected): Likewise.
(expected_dot): Likewise.

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

gprof: Add a simple test for gprof -l

Verify that "gprof -l" works properly.

* testsuite/Makefile.am (check_SCRIPTS): Add tst-gmon-gprof-l.sh.
* testsuite/Makefile.in: Regenerated.
* testsuite/tst-gmon-gprof-l.sh: New.

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

meaningless p_offset for zero p_filesz PT_LOAD

This patch avoids generating PT_LOAD segments that trip a bug in
glibc's loader.

PR 25237
PR 32763
* elf.c (assign_file_positions_for_load_sections): Don't put
p_offset zero for empty PT_LOAD.

Further tidies to bed->p_align code

align_pagesize was used for two things, reducing p->p_align from
maxpagesize to the bed->p_align value (section alignment permitting),
and increasing p->p_align above maxpagesize if section alignment
required that.  This patch untangles those two, making align_pagesize
only do the former.  p->p_align is set directly for the latter.  I've
made that change to p->p_align only when D_PAGED to keep things
consistent with other early assignments to p->p_align.  p->p_align is
set later according to section alignment when not D_PAGED.

I've also moved the place where align_pagesize adjusts p->p_align to
be with other code setting p->p_align.  That seemed better to me than
leaving it until the last possible moment.  Note that it isn't
necessary to have this adjustment done inside a test for a PT_LOAD
header, since we never set align_pagesize non-zero outside a PT_LOAD
test.

* elf.c (assign_file_positions_for_load_sections): Clear
align_pagesize whenever we have a section alignment more than
bed->p_align.  Set p->p_align rather than align_pagesize
when section alignment exceeds maxpagesize.  Assign p->p_align
from align_pagesize earlier.

Tidy code handling bed->p_align a little.

No functional changes here, just preparation for the next patch.

* elf.c (assign_file_positions_for_load_sections): Replace
p_align_p and p_align with align_pagesize.  Revise comments
on code handling bed->p_align.

ld: Cleanup sframe_decoder_init_func_bfdinfo use of reloc cookie

The loop did set cookie->rel to the i-th relocation twice.  At the
beginning using the loop counter.  At the end by incrementing.  One
approach is sufficient.

Change cookie to pointer-to-const, replace cookie->rel by rel,
initialize before the loop and increment at the end, and merge the
two assertions (for cookie->rel) into one.

While at it change sec to pointer-to-const.

bfd/
* elf-sframe.c (sframe_decoder_init_func_bfdinfo): Cleanup use
of relocation cookie.

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

gas: Use SFrame header and FDE field sizes when generating .sframe

The use of SFRAME_RELOC_SIZE in generation of SFrame stack trace
information from CFI directives erroneously suggested that this could
be used to configure a different relocation size.  But in practice it
is tied to the SFrame field sizes it is used for and therefore cannot
be changed.

Replace the uses of SFRAME_RELOC_SIZE by the size of the respective
SFrame header and FDE fields when emitting SFrame information.  While
at it enhance some comments.

gas/
* gen-sframe.c (SFRAME_RELOC_SIZE): Delete.
(sizeof_member): Define.
(output_sframe_funcdesc): Use size of SFrame FDE fields instead
of SFRAME_RELOC_SIZE.
(output_sframe_internal): Use size of SFrame header fields
instead of SFRAME_RELOC_SIZE.

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

Automatic date update in version.in

RISC-V: PR32772, fixed segfault caused by the accidental removal of `h != NULL'

bfd/
PR 32772
* elfnn-riscv.c (riscv_elf_relocate_section): Fixed segfault caused by
the accidental removal of `h != NULL' when handling a call to an
undefined weak function.

Fix segfault if target_fileio_read_alloc fails

Check for target_fileio_read_alloc failure in linux_fill_prpsinfo
before dereferencing buffer. This fixes a segfault in the 'gcore'
command when attached to certain remote targets.

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

Automatic date update in version.in

bfd_elf_parse_attr_section_v1 buffer overflow

This function has a misleading parameter "contents", which usually
means an entire section contents is passed.  However in this case the
actual sections contents plus one is passed, leading to miscalculating
the end of the buffer.

* elf-attrs.c (bfd_elf_parse_attr_section_v1): Delete hdr and
contents param.  Add p and p_end as params.
(_bfd_elf_parse_attributes): Adjust to suit.

gprof: Compile tst-gmon.c with -O2 -fno-omit-frame-pointer

Compile tst-gmon.c with -O2 -fno-omit-frame-pointer to ensure proper call
graph generation.

PR gprof/32768
* configure.ac: Compile tst-gmon.c with -fno-omit-frame-pointer.
* configure: Regenerated.
* testsuite/Makefile.am (GPROF_FLAGS): Add -O2
-fno-omit-frame-pointer.
(AM_CFLAGS): Removed.
(COMPILE): Append $(GPROF_FLAGS).
(LINK): Likewise.
* testsuite/Makefile.in: Regenerated.

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

[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with -m32 for AMD

When running test-case gdb.base/step-over-syscall.exp with target board
unix/-m32 on an AMD processor, I run into:
...
(gdb) x/2i $pc^M
=> 0xf7fc9575 <__kernel_vsyscall+5>:    syscall^M
   0xf7fc9577 <__kernel_vsyscall+7>:    int    $0x80^M
(gdb) PASS: $exp: fork: displaced=off: pc before/after syscall instruction
stepi^M
[Detaching after fork from child process 65650]^M
0xf7fc9579 in __kernel_vsyscall ()^M
1: x/i $pc^M
=> 0xf7fc9579 <__kernel_vsyscall+9>:    pop    %ebp^M
(gdb) $exp: fork: displaced=off: stepi fork insn
print /x $pc^M
$2 = 0xf7fc9579^M
(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: pc after stepi
FAIL: $exp: fork: displaced=off: pc after stepi matches insn addr after syscall
...

The problem is that the syscall returns at the "pop %ebp" insn, while the
test-case expects it to return at the "int $0x80" insn.

This is similar to the problem I fixed in commit 14852123287 ("[gdb/testsuite]
Fix gdb.base/step-over-syscall.exp with -m32"), just that the syscall sequence
used there used the "sysenter" insn instead of the "syscall" insn.

Fix this by extending the fix for commit 14852123287 to also handle the
"syscall" insn.

Tested on x86_64-linux, both using an AMD and Intel processor.

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

gdb/dwarf: call other cutu_reader constructor in ensure_lang and dw2_get_file_names

PR 32742 shows this failing:

    $ make check TESTS="gdb.ada/access_to_unbounded_array.exp" RUNTESTFLAGS="--target_board=fission"
    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.ada/access_to_unbounded_array.exp ...
    FAIL: gdb.ada/access_to_unbounded_array.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:23 (GDB internal error)

Or, interactively:

    $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.ada/access_to_unbounded_array/foo-all -ex 'b foo.adb:23' -batch
    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:19567: internal-error: set_lang: Assertion `old_value == language_unknown || old_value == language_minimal || old_value == lang' failed.

The symptom is that for a given dwarf2_per_cu, the language gets set
twice.  First, set to `language_ada`, and then, to `language_minimal`.
It's unexpected for the language of a CU to get changed like this.

The CU at offset 0x0 in the main file looks like:

    0x00000000: Compile Unit: length = 0x00000030, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000034)

    0x0000000b: DW_TAG_compile_unit
                  DW_AT_low_pc [DW_FORM_addr]       (0x000000000000339a)
                  DW_AT_high_pc [DW_FORM_data8]     (0x0000000000000432)
                  DW_AT_stmt_list [DW_FORM_sec_offset]      (0x00000000)
                  DW_AT_GNU_dwo_name [DW_FORM_strp] ("b~foo.dwo")
                  DW_AT_comp_dir [DW_FORM_strp]     ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array")
                  DW_AT_GNU_pubnames [DW_FORM_flag_present] (true)
                  DW_AT_GNU_addr_base [DW_FORM_sec_offset]  (0x00000000)
                  DW_AT_GNU_dwo_id [DW_FORM_data8]  (0x277aee54e7bd47f7)

This refers to the DWO file b~foo.dwo, whose top-level DIE is:

    .debug_info.dwo contents:
    0x00000000: Compile Unit: length = 0x00000b63, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000b67)

    0x0000000b: DW_TAG_compile_unit
                  DW_AT_producer [DW_FORM_GNU_str_index]    ("GNU Ada 14.2.1 20250207 -fgnat-encodings=minimal -gdwarf-4 -fdebug-types-section -fuse-ld=gold -gnatA -gnatWb -gnatiw -gdwarf-4 -gsplit-dwarf -ggnu-pubnames -gnatws -mtune=generic -march=x86-64")
                  DW_AT_language [DW_FORM_data1]    (DW_LANG_Ada95)
                  DW_AT_name [DW_FORM_GNU_str_index]        ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array/b~foo.adb")
                  DW_AT_comp_dir [DW_FORM_GNU_str_index]    ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array")
                  DW_AT_GNU_dwo_id [DW_FORM_data8]  (0xdbeffefab180a2cb)

The thing to note is that the language attribute is only present in the
DIE in the DWO file, not on the DIE in the main file.

The first time the language gets set is here:

    #0  dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_ada, dw_lang=DW_LANG_Ada95) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788
    #1  0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff10bf2b0, cu=0x51700008e000, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029
    #2  0x000055556159f740 in cutu_reader::cutu_reader (this=0x7ffff10bf2b0, this_cu=0x50f0000044b0, per_objfile=0x516000066080, abbrev_table=0x510000004640, existing_cu=0x0, skip_partial=false, pretend_language=language_minimal, cache=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3371
    #3  0x00005555615a547a in process_psymtab_comp_unit (this_cu=0x50f0000044b0, per_objfile=0x516000066080, storage=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3799
    #4  0x00005555615a9292 in cooked_index_worker_debug_info::process_cus (this=0x51700008dc80, task_number=0, first=std::unique_ptr<dwarf2_per_cu> = {...}, end=std::unique_ptr<dwarf2_per_cu> = {...}) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4122

In this code path (particularly this specific cutu_reader constructir),
the work is done to find and read the DWO file.  So the language is
properly identifier as language_ada, all good so far.

The second time the language gets set is:

    #0  dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_minimal, dw_lang=0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788
    #1  0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff0f42730, cu=0x517000091b80, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029
    #2  0x00005555615a1822 in cutu_reader::cutu_reader (this=0x7ffff0f42730, this_cu=0x50f0000044b0, per_objfile=0x516000066080, pretend_language=language_minimal, parent_cu=0x0, dwo_file=0x0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3464
    #3  0x000055556158c850 in dw2_get_file_names (this_cu=0x50f0000044b0, per_objfile=0x516000066080) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1956
    #4  0x000055556158f4f5 in dw_expand_symtabs_matching_file_matcher (per_objfile=0x516000066080, file_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2157
    #5  0x00005555616329e2 in cooked_index_functions::expand_symtabs_matching (this=0x50200002ab50, objfile=0x516000065780, file_matcher=..., lookup_name=0x0, symbol_matcher=..., expansion_notify=..., search_flags=..., domain=..., lang_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:15912
    #6  0x0000555562ca8a14 in objfile::map_symtabs_matching_filename (this=0x516000065780, name=0x50200002ad90 "break pck.adb", real_path=0x0, callback=...) at /home/smarchi/src/binutils-gdb/gdb/symfile-debug.c:207
    #7  0x0000555562d68775 in iterate_over_symtabs (pspace=0x513000005600, name=0x50200002ad90 "break pck.adb", callback=...) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:727

Here, we use the other cutu_reader constructor, the one that does not
look up the DWO file for the passed CU.  If a DWO file exists for this
CU, the caller is expected to pass it as a parameter.  That cutu_reader
constructor also ends up setting the language of the CU.  But because it
didn't read the DWO file, it didn't figure out the language is
language_ada, so it tries to set the language to the default,
language_minimal.

A question is: why do we end up trying to set the CU's language is this
context.  This is completely unrelated to what we're trying to do, that
is get the file names from the line table.  Setting the language is a
side-effect of just constructing a cutu_reader, which we need to look up
attributes in dw2_get_file_names_reader.  There are probably some
cleanups to be done here, to avoid doing useless work like looking up
and setting the CU's language when all we need is an object to help
reading the DIEs and attributes.  But that is future work.

The same cutu_reader constructor is used in
`dwarf2_per_cu::ensure_lang`.  Since this is the version of cutu_reader
that does not look up the DWO file, it will conclude that the language
is language_minimal and set that as the CU's language.  In other words,
`dwarf2_per_cu::ensure_lang` will get the language wrong, pretty ironic.

Fix this by using the other cutu_reader constructor in those two spots.
Pass `per_objfile->get_cu (this_cu)`, as the `existing_cu` parameter.  I
think this is necessary, because that constructor has an assert to check
that if `existing_cu` is nullptr, then there must not be an existing
`dwarf2_cu` in the per_objfile.

To avoid getting things wrong like this, I think that the second
cutu_reader constructor should be reserved for the spots that do pass a
non-nullptr dwo_file.  The only spot at the moment in
create_cus_hash_table, where we read multiple units from the same DWO
file.  In this context, I guess it makes sense for efficiency to get the
dwo_file once and pass it down to cutu_reader.  For that constructor,
make the parameters non-optional, add "non-nullptr" asserts, and update
the code to assume the passed values are not nullptr.

What I don't know is if this change is problematic thread-wise, if the
functions I have modified to use the other cutu_reader constructor can
be called concurrently in worker threads.  If so, I think it would be
problematic.

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

Avoid excessive CU expansion on failed matches

PR symtab/31010 points out that something like "ptype INT" will expand
all CUs in a typical program.  The OP further points out that the
original patch for PR symtab/30520:

    https://sourceware.org/pipermail/gdb-patches/2024-January/205924.html

... did solve the problem, but the patch changed after (my) review and
reintroduced the bug.

In cooked_index_functions::expand_symtabs_matching, the final
component of a split name is compared with the entry's name using the
usual method of calling get_symbol_name_matcher.

This code iterates over languages and tries to split the original name
according to each style.  But, the Ada splitter uses the decoded name
-- "int".  This causes every C or C++ CU to be expanded.

Clearly this is wrong.  And, it seems to me that looping over
languages and trying to guess the splitting style for the input text
is probably bad.  However, fixing the problem is not so easy (again
due to Ada).  I've filed a follow-up bug, PR symtab/32733, for this.

Meanwhile, this patch changes the code to be closer to the
originally-submitted patch.  This works because the comparison is now
done between the full name and the "lookup_name_without_params"
object, which is a less adulterated variant of the original input.

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

Use wild matching for lookup_name_info::match_any

Currently, lookup_name_info::match_any symbol_name_match_type::FULL.
However, this seems wrong.  Consider the expand_symtabs_matching
implementation of the cooked index: it compares name components, and
then if all the components match, it checks:

  if ((match_type == symbol_name_match_type::FULL
       || (lang != language_ada
   && match_type == symbol_name_match_type::EXPRESSION)))
    {
      if (parent != nullptr)
continue;

That is, if the component-matching loop did not finish, and a full
match is requested, then fail to match.  This handles cases where the
index is asked to look up "b::c" but finds "a::b::c".

However, match_any should match, well, any.  So, it seems to me that
checking any parent matches is irrelevant -- and therefore this should
use wild matching.

Automatic date update in version.in

Handle ">>" in cp-name-parser.y

I noticed that a certain name didn't work correctly when trying to
remove the parameters.  I put this into lookup_name_info-selftests.c.

I tracked this down to the fact that cp-name-parser.y doesn't handle
">>" to end templates.  This patch fixes this in a simple way --
accepting the "RSH" token where appropriate and then un-pushing a ">".

Minor cleanups to cpname_state

This changes cpname_state to have a constructor and some inline
initializers.

gdb/dwarf: move cooked_indexer to cooked-indexer.{h,c}

Move the cooked_indexer class declaration to a new cooked-indexer.h
file, and the implementation to cooked-indexer.c.

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

gdb/dwarf: move cooked_index_storage to cooked-index-storage.{h,c}

cooked_index_storage is currently declared in `cooked-index.h` and
implemented in `read.c`.  Move all that to new
`cooked-index-storage.{h,c}` files.

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

gdb/dwarf: move cutu_reader to read.h

In order to move some things outside of read.c, cutu_reader needs to be
in a header file.

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

AVR: gas/32704 - Improve code generation for __gcc_isr.

The prologue generated by __gcc_isr can be improved in
situations where:

* ZERO_REG is needed, and
* SREG is not clobbered by the ISR, and
* avr-gcc provides a GPR >= R16 with the Done chunk, and
* Code generation is for ordinary AVRs (not AVRrc).

For example, the prologue for

volatile char var;

__attribute__((signal)) void __vector_1 (void)
{
    var = 1;
    var = 0;
}

may be

00000000 <__vector_1>:
   0: 8f 93        push r24
   2: 1f 92        push r1
   4: 80 e0        ldi r24, 0
   6: 18 2e        mov r1, r24

instead of the code as currently generated by GAS:

00000000 <__vector_1>:
   0: 1f 92        push r1
   2: 1f b6        in r1, SREG
   4: 1f 92        push r1
   6: 11 24        clr r1
   8: 8f 93        push r24

which consumes more stack, time and code than needed.

gas/
PR gas/32704
PR gas/21683
* config/tc-avr.c (avr_isr): bool-ize.
(avr_emit_insn): Emit "mov" code as  MOV R1,<reg>.
(avr_isr_stack_t): New typedef.
(avr_emit_push, avr_emit_pop): New static functions.
(avr_patch_gccisr_frag): Overhaul prologue and epilogue
generation.

Fix imm20 range check in MSP430 port of gas

gas: don't permit "repeat" expressions with .cfi_{escape,fde_data}

Repeat counts greater than 1 will emit data directly into the current
(sub-)section. That's wrong with .cfi_*, which defer data emission until
much later: N-1 instances of the specified data would not end up in
.eh_frame (or whatever the section that CFI data was specified to go
into). Simply disallow "repeat" expressions in such cases.

gas/listing: drop forward declarations

These aren't needed (anymore); all static functions are defined before
their first use.

gas: centralize declaration of listing_tail

Besides it being somewhat off to have three decls scattered across the
code base, it is generally bad practice for the definition of a symbol
to not also observe its declaration (making sure the two won't go out of
sync).

objdump: permit disassembling multiple individual functions

Compilers may split functions, e.g. into a "hot" and "cold" part, or
they may emit special case instantiations (e.g. as a result of IPA). It
can be helpful to be able to disassemble all of the parts or clones in
one go. Permit using "--disassemble=" multiple times.

objdump: properly disassemble successive functions of the same name

... when only their symbol was requested for disassembly. Addressing the
respective FIXME is as easy as coverting the "else" there to an if()
with the opposite condition, thus accounting for the disabling the
original if() may have effected.

Fix missing int argument warning

This warning (per -Werror) breaks the build using a recent GCC
with recent userland.

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

[gdb/tdep] Support REX2 and EVEX prefix

The following amd64 insn:
...
   0: 67 d5 44 8d 3d 00 00 00 00 lea 0x0(%eip),%r31d
...
uses the REX2 prefix [1], which is currently not supported in
amd64_get_insn_details.

Add the missing support in amd64_get_insn_details, as well as a corresponding
unit test.

Likewise for an amd64 insn using an EVEX prefix [2]:
...
   0: 62 f1 7c 48 28 05 00 fc ff ff vmovaps -0x400(%rip),%zmm0
...

Tested on x86_64-linux.

PR tdep/32725
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32725

[1] https://en.wikipedia.org/wiki/VEX_prefix
[2] https://en.wikipedia.org/wiki/EVEX_prefix

[gdb/tdep] Fix vmovdqu decoding

PR tdep/31952 reports that displaced stepping over an instruction pointer
relative insn "vmovdqu 0x20(%rip),%ymm1" gives the wrong results.

This is caused by misclassification of the insn in amd64_get_insn_details,
which results in details.modrm_offset == -1, while the instruction in fact
does have a modrm byte.

The instruction is encoded as follows:
...
  400557:       c5 fe 6f 0d 20 00 00 00    vmovdqu 0x20(%rip),%ymm1
...
where:
- "0xc5 0xfe" is the vex2 prefix,
- "0x6f" is the opcode,
- "0x0d" is the modrm byte, and
- "0x20 0x00 0x00 0x00" is a 32-bit displacement.

The problem is related to details.opcode_len, which is 1.

While it is true that the length of the opcode in the insn (0x6f) is 1 byte,
the vex2 prefix implies that we're encoding an 2-byte opcode beginnning
with 0x0f [1].

Consequently, we should be using the twobyte_has_modrm map rather than the
onebyte_has_modrm map.

Fix this in amd64_get_insn_details, and add a selftest to check this.

Tested on x86_64-linux.

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

[1] https://en.wikipedia.org/wiki/VEX_prefix

[gdb/tdep] Make amd64_get_insn_details more regular

In amd64_get_insn_details, I found this code with a comment explaining why
enc_prefix_offset is not set:
...
  else if (vex2_prefix_p (*insn))
    {
      /* Don't record the offset in this case because this prefix has
 no REX.B equivalent.  */
       insn += 2;
     }
...
which I didn't understand until I looked at the only use of enc_prefix_offset,
in fixup_riprel:
...
  /* REX.B should be unset (VEX.!B set) as we were using rip-relative
     addressing, but ensure it's unset (set for VEX) anyway, tmp_regno
     is not r8-r15.  */
  if (insn_details->enc_prefix_offset != -1)
    {
      gdb_byte *pfx = &dsc->insn_buf[insn_details->enc_prefix_offset];
      if (rex_prefix_p (pfx[0]))
pfx[0] &= ~REX_B;
      else if (vex3_prefix_p (pfx[0]))
pfx[1] |= VEX3_NOT_B;
      else
gdb_assert_not_reached ("unhandled prefix");
    }
...

Fix this by:
- setting enc_prefix_offset for the vex2 case in amd64_get_insn_details,
  making the function more regular and easier to understand, and
- handling the vex2 case in the "enc_prefix_offset != -1" clause in
  fixup_riprel.

Tested on x86_64-linux.