Recognize FreeBSD core dump note for x86 segment base registers.

This core dump note contains the value of the base address of the %fs
and %gs segments for both i386 and amd64 core dumps.  It is primarily
useful in resolving the address of TLS variables in core dumps.

binutils/ChangeLog:

* readelf.c (get_freebsd_elfcore_note_type): Handle
NT_FREEBSD_X86_SEGBASES.

include/ChangeLog:

* elf/common.h (NT_FREEBSD_X86_SEGBASES): Define.

elfcore_grok_freebsd_note: Remove checks of note->namesz.

This function is only called if the note name is "FreeBSD", so
checking the name size is unnecessary.

bfd/ChangeLog:

* elf.c (elfcore_grok_freebsd_note): Remove checks for namesz.

gdb/testing/tui: add new _csi_{L,S,T}

This patch was original part of this series:

  https://sourceware.org/pipermail/gdb-patches/2022-March/186429.html
  https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html

I've pulled this out as it might be useful ahead of the bigger series
being merged.

This commit adds:

  _csi_L - insert line
  _csi_S - pan down
  _csi_T - pan up

x86: Remove bfd_arch_l1om and bfd_arch_k1om

Remove bfd_arch_l1om and bfd_arch_k1om since L1OM/K1OM support has been
removed from gas, ld and opcodes.

bfd/

* Makefile.am (ALL_MACHINES): Remove cpu-l1om.lo and cpu-k1om.lo.
(ALL_MACHINES_CFILES): Remove cpu-l1om.c and cpu-k1om.c.
* archures.c (bfd_mach_l1om): Removed.
(bfd_mach_l1om_intel_syntax): Likewise.
(bfd_mach_k1om): Likewise.
(bfd_mach_k1om_intel_syntax): Likewise.
(bfd_k1om_arch): Likewise.
(bfd_l1om_arch): Likewise.
(bfd_archures_list): Remove bfd_k1om_arch and bfd_l1om_arch
references.
* config.bfd (targ_selvecs): Remove l1om_elf64_vec.
l1om_elf64_fbsd_vec, k1om_elf64_vec and k1om_elf64_fbsd_vec.
(targ_archs): Remove bfd_l1om_arch and bfd_k1om_arch.
* configure.ac (k1om_elf64_vec): Removed.
(k1om_elf64_fbsd_vec): Likewise.
(l1om_elf64_vec): Likewise.
(l1om_elf64_fbsd_vec): Likewise.
* cpu-k1om.c: Removed.
* cpu-l1om.c: Likewise.
* elf64-x86-64.c (elf64_l1om_elf_object_p): Removed.
(elf64_k1om_elf_object_p): Likewise.
(l1om_elf64_vec): Removed.
(l1om_elf64_fbsd_vec): Likewise.
(k1om_elf64_vec): Likewise.
(k1om_elf64_fbsd_vec): Likewise.
(ELF_TARGET_OS): Undefine.
* targets.c (_bfd_target_vector): Remove k1om_elf64_vec,
k1om_elf64_fbsd_vec, l1om_elf64_vec and l1om_elf64_fbsd_vec.
* Makefile.in: Regenerate.
* bfd-in2.h: Likewise.
* configure: Likewise.

opcodes/

* configure.ac: Remove bfd_arch_l1om/bfd_arch_k1om references.
* disassemble.c (disassembler): Likewise.
* configure: Regenerate.

gdb/ctf: pass partial symtab's filename to buildsym_compunit

I noticed that the CTF symbol reader passes the objfile's name to all
buildsym_compunit instances it creates.  The result is that all
compunit_symtabs created have the same name, that of the objfile:

    { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
      { ((struct compunit_symtab *) 0x621000286760)
        debugformat ctf
        producer (null)
        name libbabeltrace2.so.0.0.0
        dirname (null)
        blockvector ((struct blockvector *) 0x6210003911d0)
        user ((struct compunit_symtab *) (null))
            { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003911f0)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }
      { ((struct compunit_symtab *) 0x621000275c10)
        debugformat ctf
        producer (null)
        name libbabeltrace2.so.0.0.0
        dirname (null)
        blockvector ((struct blockvector *) 0x621000286710)
        user ((struct compunit_symtab *) (null))
            { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x621000286730)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }

Notice the two "name libbabeltrace2.so.0.0.0".

Change it to pass the partial_symtab's filename instead.  The output
becomes:

    { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
      { ((struct compunit_symtab *) 0x621000295610)
        debugformat ctf
        producer (null)
        name libbabeltrace2.so.0.0.0
        dirname (null)
        blockvector ((struct blockvector *) 0x6210003a15d0)
        user ((struct compunit_symtab *) (null))
            { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003a15f0)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }
      { ((struct compunit_symtab *) 0x621000288700)
        debugformat ctf
        producer (null)
        name current-thread.c
        dirname (null)
        blockvector ((struct blockvector *) 0x6210002955c0)
        user ((struct compunit_symtab *) (null))
            { symtab /home/simark/src/babeltrace/src/lib/current-thread.c ((struct symtab *) 0x6210002955e0)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }

Note that the first compunit_symtab still has libbabeltrace2.so.0.0.0 as
its name.  This is because the CTF symbol reader really creates a
partial symtab named like this.  It appears to be because the debug info
contains information that has been factored out of all CUs and is at the
"top-level" of the objfile, outside any real CU.  So it creates a
partial symtab and an artificial CU that's named after the objfile.

Change-Id: I576316bab2a3668adf87b4e6cebda900a8159b1b

gdb: print compunit_symtab name in "maint info symtabs"

I think it would make sense to print a compunit_symtab's name in "maint
info symtabs".  If you are looking for a given CU in the list, that's
probably the field you will be looking at.  As the doc of
compunit_symtab::name says, it is not meant to be a reliable file name,
it is for debugging purposes (and "maint info symtabs" exists for
debugging purposes).

Sample output with the new field:

    (gdb) maintenance info symtabs
    { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00)
      { ((struct compunit_symtab *) 0x621000131630)
        debugformat DWARF 5
        producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
        name test.c
        dirname /home/simark/build/binutils-gdb-one-target/gdb
        blockvector ((struct blockvector *) 0x621000131d10)
        user ((struct compunit_symtab *) (null))
            { symtab test.c ((struct symtab *) 0x6210001316b0)
              fullname (null)
              linetable ((struct linetable *) 0x621000131d40)
            }
            { symtab /home/simark/build/binutils-gdb-one-target/gdb/test.h ((struct symtab *) 0x6210001316e0)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
            { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000131710)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }
      { ((struct compunit_symtab *) 0x6210001170a0)
        debugformat DWARF 5
        producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
        name foo.c
        dirname /home/simark/build/binutils-gdb-one-target/gdb
        blockvector ((struct blockvector *) 0x621000131580)
        user ((struct compunit_symtab *) (null))
            { symtab foo.c ((struct symtab *) 0x621000117120)
              fullname (null)
              linetable ((struct linetable *) 0x6210001315b0)
            }
            { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000117150)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }
    }

Change-Id: I17b87adfac2f6551cb5bda30d59f6c6882789211

gdb/ctf: don't create a buildsym_compunit when building partial symbols

I am trying to do some changes to buildsym_compunit, so I am auditing
the current uses.  Something seems odd with this use of
buildsym_compunit (that this patch removes).

A buildsym_compunit is normally used when building a compunit_symtab.
That is, when expanding a partial symtab into a full compunit symtab.
In ctfread.c, a buildsym_compunit is created in ctf_start_archive, which
is only used when creating partial symtabs.  At this moment, I don't
see how that's useful.  ctf_start_archive creates a new
buildsym_compunit and starts a subfile.  But that buildsym_compunit is
never used again.  It's just overriden in ctf_start_symtab, which means
we leak the old buildsym_compunit, I suppose.

Remove ctf_start_archive completely.  Add an assert in
ctf_start_symtab to verify that we are not overwriting an existing
buildsym_compunit (meaning we'd leak the existing one).  This assert
triggers without the other part of the fix.  When doing:

  $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
  ...
  (gdb) maintenance expand-symtabs
  /home/simark/src/binutils-gdb/gdb/ctfread.c:1255: internal-error: ctf_start_symtab: Assertion `!ccp->builder' failed.

Change-Id: I666d146454a019f08e7305f3a1c4a974d27b4592

Style URLs in GDB output

I noticed that GDB will display URLs in a few spots.  This changes
them to be styled.  Originally I thought I'd introduce a new "url"
style, but there aren't many places to use this, so I just reused
filename styling instead.  This patch also changes the debuginfod URL
list to be printed one URL per line.  I think this is probably a bit
easier to read.

Automatic date update in version.in

gdb: initialize ctf_context::builder in create_partial_symtab

I built a random project with -gctf, in order to test the CTF support in
GDB.  With my ASan/UBSan/etc-enabled build of GDB, I get:

    $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
    ...
    Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0...
    /home/simark/src/binutils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebebe for type 'struct buildsym_compunit', which requires 8 byte alignment
    0xbebebebebebebebe: note: pointer points here

The 0xbebebebebebebebe value is a sign that the ctf_context::builder
field is uninitialized.  The problem probably goes under the radar if
the field happens to be zero-initialized, because ctf_start_archive
contains this code:

  if (ccx->builder == nullptr)
    {
      ccx->builder = new buildsym_compunit (of,
      of->original_name, nullptr, language_c, 0);

If the field was zero-initialized (by chance), this will create a new
buildsym_compunit.  But if the field was purposely filled with random
bytes by one of the sanitizers, we won't create a buildsym_compunit here
and we'll continue with ccx->builder equal to 0xbebebebebebebebe.

Fix this the easy way by initializing ccx->builder where the other
ctf_context fields are initialized (yeah, this code could be made nicer
C++, but I am going for the obvious fix here).

With this patch, this passes cleanly on my system:

  $ make check TESTS="gdb.ctf/*.exp" RUNTESTFLAGS="CC_FOR_TARGET=/opt/gcc/git/bin/gcc"
  # of expected passes            40

... where /opt/gcc/git/bin/gcc is a gcc with CTF support, given my
system gcc does not have it.

Change-Id: Idea1b0cf3e3708b72ecb16b1b60222439160f9b9

Remove dbx mode

This patch removes gdb's dbx mode.  Regression tested on x86-64 Fedora
34.

gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xml

1. Since 32bit-pkeys.xml and 64bit-pkeys.xml are identical, consolidate
them into a single keys.xml.
2. Enable PKU for x32 to fix:

$ gdbserver :123456 x32-program
...
.../gdbserver/regcache.cc:255: A problem internal to GDBserver has been detected
.
Unknown register pkru requested

on Tiger Lake.

gdb/linux-nat: remove check based on current_inferior in linux_handle_extended_wait

The check removed by this patch, using current_inferior, looks wrong.
When debugging multiple inferiors with the Linux native target and
linux_handle_extended_wait is called, there's no guarantee about which
is the current inferior.  The vfork-done event we receive could be for
any inferior.  If the vfork-done event is for a non-current inferior, we
end up wrongfully ignoring it.  As a result, the core never processes a
TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed
is never cleared, and breakpoints are never reinserted.  However,
because the Linux native target decided to ignore the event, it resumed
the thread - while breakpoints out.  And that's bad.

The proposed fix is to remove this check.  Always report vfork-done
events and let infrun's logic decide if it should be ignored.  We don't
save much cycles by filtering the event here.

Add a test that replicates the situation described above.  See comments
in the test for more details.

Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf

gdbserver/linux: set lwp !stopped when failing to resume

I see some failures, at least in gdb.multi/multi-re-run.exp and
gdb.threads/interrupted-hand-call.exp.  Running `stress -C $(nproc)` at
the same time as the test makes those tests relatively frequent.

Let's take gdb.multi/multi-re-run.exp as an example.  The failure looks
like this, an unexpected "no resumed":

    continue
    Continuing.
    No unwaited-for children left.
    (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=2: iter=1: continue until exit

The situation is:

 - Inferior 1 is stopped somewhere, it won't really play a role here.
 - Inferior 2 has 2 threads, both stopped.
 - We resume inferior 2, the leader thread is expected to exit, making
   the process exit.

From GDB's perspective, a failing run looks like this:

    [infrun] fetch_inferior_event: enter
      [infrun] scoped_disable_commit_resumed: reason=handling event
      [infrun] do_target_wait: Found 2 inferiors, starting at #1
      [infrun] random_pending_event_thread: None found.
      [remote] wait: enter
        [remote] Packet received: T0506:20dcffffff7f0000;07:20dcffffff7f0000;10:9551555555550000;thread:pae4cd.ae4cd;core:e;
      [remote] wait: exit
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   713933.713933.0 [Thread 713933.713933],
      [infrun] print_target_wait_results:   status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
      [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
      [infrun] clear_step_over_info: clearing step over info
      [infrun] context_switch: Switching context from 0.0.0 to 713933.713933.0
      [infrun] handle_signal_stop: stop_pc=0x555555555195
      [infrun] start_step_over: enter
        [infrun] start_step_over: stealing global queue of threads to step, length = 0
        [infrun] operator(): step-over queue now empty
      [infrun] start_step_over: exit
      [infrun] process_event_stop_test: no stepping, continue
      [remote] Sending packet: $Z0,555555555194,1#8e
      [remote] Packet received: OK
      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [713933.713933.0] at 0x555555555195
      [remote] Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a
      [remote] Packet received: OK
      [remote] Sending packet: $vCont;c:pae4cd.-1#9f
      [infrun] prepare_to_wait: prepare_to_wait
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
    [infrun] fetch_inferior_event: exit
    [infrun] fetch_inferior_event: enter
      [infrun] scoped_disable_commit_resumed: reason=handling event
      [infrun] do_target_wait: Found 2 inferiors, starting at #0
      [infrun] random_pending_event_thread: None found.
      [remote] wait: enter
        [remote] Packet received: N
      [remote] wait: exit
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   -1.0.0 [process -1],
      [infrun] print_target_wait_results:   status->kind = NO_RESUMED
      [infrun] handle_inferior_event: status->kind = NO_RESUMED
      [remote] Sending packet: $Hgp0.0#ad
      [remote] Packet received: OK
      [remote] Sending packet: $qXfer:threads:read::0,1000#92
      [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
      [infrun] stop_waiting: stop_waiting
      [remote] Sending packet: $qXfer:threads:read::0,1000#92
      [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
      [infrun] infrun_async: enable=0
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
    [infrun] fetch_inferior_event: exit

We can see that we resume the inferior with vCont;c, but got NO_RESUMED.
When the test passes, we get an EXITED status to indicate the process
has exited.

From GDBserver's point of view, it looks like this.  The logs contain
some logging I added and that are part of this patch.

    [remote] getpkt: getpkt ("vCont;c:pae4cf.-1");  [no ack sent]
    [threads] resume: enter
      [threads] thread_needs_step_over: Need step over [LWP 713931]? Ignoring, should remain stopped
      [threads] thread_needs_step_over: Need step over [LWP 713932]? Ignoring, should remain stopped
      [threads] get_pc: pc is 0x555555555195
      [threads] thread_needs_step_over: Need step over [LWP 713935]? No, no breakpoint found at 0x555555555195
      [threads] get_pc: pc is 0x7ffff7d35a95
      [threads] thread_needs_step_over: Need step over [LWP 713936]? No, no breakpoint found at 0x7ffff7d35a95
      [threads] resume: Resuming, no pending status or step over needed
      [threads] resume_one_thread: resuming LWP 713935
      [threads] proceed_one_lwp: lwp 713935
      [threads] resume_one_lwp_throw:   continue from pc 0x555555555195
      [threads] resume_one_lwp_throw: Resuming lwp 713935 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: NOW ptid=713935.713935.0 stopped=0 resumed=0
      [threads] resume_one_thread: resuming LWP 713936
      [threads] proceed_one_lwp: lwp 713936
      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
      [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
    [threads] resume: exit
    [threads] wait_1: enter
      [threads] wait_1: [<all threads>]
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
      [threads] resume_stopped_resumed_lwps: resuming stopped-resumed LWP LWP 713935.713936 at 7ffff7d35a95: step=0
      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
      [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
      [threads] operator(): check_zombie_leaders: leader_pid=713931, leader_lp!=NULL=1, num_lwps=2, zombie=0
      [threads] operator(): check_zombie_leaders: leader_pid=713935, leader_lp!=NULL=1, num_lwps=2, zombie=1
      [threads] operator(): Thread group leader 713935 zombie (it exited, or another thread execd).
      [threads] delete_lwp: deleting 713935
      [threads] wait_for_event_filtered: exit (no unwaited-for LWP)
    sigchld_handler
      [threads] wait_1: ret = null_ptid, TARGET_WAITKIND_NO_RESUMED
    [threads] wait_1: exit

What happens is:

 - We resume the leader (713935) successfully.
 - The leader exits.
 - We resume the secondary thread (713936), we get ESRCH.  This is
   expected this the leader has exited.
 - resume_one_lwp_throw throws, it's caught by resume_one_lwp.
 - resume_one_lwp checks with check_ptrace_stopped_lwp_gone that the
   failure can be explained by the LWP becoming zombie, and swallows the
   error.
 - Note that this means that the secondary lwp still has stopped==1.
 - wait_1 is called, probably because linux_process_target::resume marks
   the async pipe at the end.
 - The exit event isn't ready yet, probably because the machine is under
   load, so waitpid returns nothing.
 - check_zombie_leaders detects that the leader is zombie and deletes
 - We try to find a resumed (non-stopped) LWP to get an event from,
   there's none since the leader (that was resumed) is now deleted, and
   the secondary thread is still marked stopped.
   wait_for_event_filtered returns -1, causing wait_1 to return
   NO_RESUMED.

What I notice here is that there is some kind of race between the
availability of the process' exit notification and the call to wait_1
that results from marking the async pipe at the end of resume.

I think what we want from this wait_1 invocation is to keep waiting, as
we will eventually get thread exit notifications for both of our
threads.

The fix I came up with is to mark the secondary thread as !stopped (or
resumed) when we fail to resume it.  This makes wait_1 see that there is
at least one resume lwp, so it won't return NO_RESUMED.  I think this
makes sense to consider it resumed, because we are going to receive an
exit event for it.  Here's the GDBserver logs with the fix applied:

    [threads] resume: enter
      [threads] thread_needs_step_over: Need step over [LWP 724595]? Ignoring, should remain stopped
      [threads] thread_needs_step_over: Need step over [LWP 724596]? Ignoring, should remain stopped
      [threads] get_pc: pc is 0x555555555195
      [threads] thread_needs_step_over: Need step over [LWP 724597]? No, no breakpoint found at 0x555555555195
      [threads] get_pc: pc is 0x7ffff7d35a95
      [threads] thread_needs_step_over: Need step over [LWP 724598]? No, no breakpoint found at 0x7ffff7d35a95
      [threads] resume: Resuming, no pending status or step over needed
      [threads] resume_one_thread: resuming LWP 724597
      [threads] proceed_one_lwp: lwp 724597
      [threads] resume_one_lwp_throw:   continue from pc 0x555555555195
      [threads] resume_one_lwp_throw: Resuming lwp 724597 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: NOW ptid=724597.724597.0 stopped=0 resumed=0
      [threads] resume_one_thread: resuming LWP 724598
      [threads] proceed_one_lwp: lwp 724598
      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
      [threads] resume_one_lwp_throw: Resuming lwp 724598 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
    [threads] resume: exit
    [threads] wait_1: enter
      [threads] wait_1: [<all threads>]
    sigchld_handler
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
      [threads] operator(): check_zombie_leaders: leader_pid=724595, leader_lp!=NULL=1, num_lwps=2, zombie=0
      [threads] operator(): check_zombie_leaders: leader_pid=724597, leader_lp!=NULL=1, num_lwps=2, zombie=1
      [threads] operator(): Thread group leader 724597 zombie (it exited, or another thread execd).
      [threads] delete_lwp: deleting 724597
      [threads] wait_for_event_filtered: sigsuspend'ing
    sigchld_handler
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724598, ERRNO-OK
      [threads] wait_for_event_filtered: waitpid 724598 received 0 (exited)
      [threads] filter_event: 724598 exited
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724597, ERRNO-OK
      [threads] wait_for_event_filtered: waitpid 724597 received 0 (exited)
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
    sigchld_handler
      [threads] wait_1: ret = LWP 724597.724598, exited with retcode 0
    [threads] wait_1: exit

Change-Id: Idf0bdb4cb0313f1b49e4864071650cc83fb3c100

gdb/testsuite/tui: implement _csi_P proc

Since commit 3cd522938792 ("Change the pager to a ui_file"), I see these
errors when running gdb.tui/scroll.exp:

    ERROR: invalid command name "_csi_P"
        while executing
    "::gdb_tcl_unknown _csi_P 2"
        ("uplevel" body line 1)
        invoked from within
    "uplevel 1 ::gdb_tcl_unknown $args"
        (procedure "::unknown" line 5)
        invoked from within
    "_csi_P 2"
        ("eval" body line 1)
        invoked from within
    "eval _csi_$cmd $params"

It looks like GDB is emitting a CSI that it did not emit before, the
"Delete character" one:

  https://vt100.net/docs/vt510-rm/DCH.html

Implement it.

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

gdb: fix use of fprintf_filtered in top.c

A race condition in how patches were pushed causes this build failure:

      CXX    top.o
    /home/simark/src/binutils-gdb/gdb/top.c: In function ‘void print_gdb_configuration(ui_file*)’:
    /home/simark/src/binutils-gdb/gdb/top.c:1622:3: error: ‘fprintf_filtered’ was not declared in this scope; did you mean ‘printf_unfiltered’?
     1622 |   fprintf_filtered (stream, _("\
          |   ^~~~~~~~~~~~~~~~

fprintf_filtered has been removed, gdb_printf must be used now.  Fix
this.

Change-Id: I6a172ba0d53dab2e7cc43ed0ed2696c82925245b

aarch64: Relax check for RNG system registers

FEAT_RNG is an optional Armv8.5-A extension, but it can be backported
to earlier architectures as well.  GAS previously made the RNG registers
conditional on having both armv8.5-a and +rng, but only +rng should be
required.

This seems to be the only feature that was handled like this.

opcodes/
* aarch64-opc.c (SR_RNG): Don't require V8_5.

gas/
* testsuite/gas/aarch64/rng-1.s, testsuite/gas/aarch64/rng-1.d: New
test.

* gdb/top.c (print_gdb_configuration): Announce --enable-threading.

This includes the reporting of --enable/disable-threading as part of
the GDB configuration description.

gdb/infrun: add reason parameter to stop_all_threads

Add a "reason" parameter, only used to show in debug messages what is
the reason for stopping all threads.  This helped me understand the
debug logs while adding some new uses of stop_all_threads, so I am
proposing to merge it.

Change-Id: I66c8c335ebf41836a7bc3d5fe1db92c195f65e55

gdb/testsuite: update copyright years in gdb.base/vfork-follow-parent.*

I forgot to do this before pushing the previous commit.

Change-Id: Ia343f702e8357d0fd109e9ddd778973e91862805

gdb: test vfork + follow-fork-mode=parent + detach-on-fork=off

The particular behavior we have when using that combination of settings
doesn't seem tested at all (at least, I don't find it if I grep for "Can
not resume the parent process").  Add a simple test for that.

Change-Id: Ib9454a615abba661b42f1b15056df73ed1bcd4c5

Accept the + character as part of filenames for MRI scripts.

Fix procfs.c compilation

procfs.c doesn't compile on Solaris:

/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c: In member function ‘virtual bool procfs_target::info_proc(const char*, info_proc_what)’:
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3302:3: error: ‘gdb_argv’ was not declared in this scope
 3302 |   gdb_argv built_argv (args);
      |   ^~~~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3303:20: error: ‘built_argv’ was not declared in this scope; did you mean ‘buildargv’?
 3303 |   for (char *arg : built_argv)
      |                    ^~~~~~~~~~
      |                    buildargv

Fixed by including  "gdbsupport/buildargv.h".

Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11.

Automatic date update in version.in

gdb/testsuite: add tests for Term

While trying to review Andrew's patch here [1], I thought I spotted a
bug in the handling of a CSI, but I had no way to know for sure.  So I
thought it would be useful to have unit tests for the handling of
control characters and control sequences of our toy terminal
implementation.  It might help avoid chasing bugs in the GDB TUI when in
reality it's a problem with the testsuite's terminal implementation.

Add the gdb.tui/tuiterm.exp file to do that.  All currently supported
control sequences and characters are tested, except _csi_m (the one that
handles colors and stuff).  _csi_m should probably be tested too, but it
will require more work.

Fix a few issues that the tests spotted:

 - backspace: according to [3] (table 4-1), a backspace when the cursor
   is at the beginning of a line should have no effect.  Our
   implementation did wrap to the end of the previous line.  Change our
   implementation to match the doc (and the test).
 - insert character: this control sequence is supposed to insert blank
   characters, shifting all the rest of the line right.  The current
   implementation moves N characters right, but it overwrites the
   characters on the right instead of shifting them.  It also doesn't
   insert blank characters at the cursor.
 - Cursor down, forward, next line: off-by-one error when reaching the
   end of the display.
 - erase in display, line: off-by-one errors.
 - vertical line position absolute: allowed setting the cursor outside
   the display, when it should clamp it to the display size.

I found that this web page [2] gave some good clues on the expected
behavior of some control characters or sequences that some other pages
didn't.

[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
[2] https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
[3] https://vt100.net/docs/vt510-rm/chapter4.html#S4.3.3

Change-Id: Iab4141fdcfb7459d1b7c45cc63bd1fcb50a78d5d

Only allow QUIT on the main thread

Pedro pointed out that gdb worker threads should not react to quits.
While I don't think that the new DWARF reader can call QUIT from a
worker thread (and I don't think the existing minsym threading code
can either), it seems safest to address this before checking in the
new code.  This patch arranges for the QUIT macro to only work on the
main thread.

Use gdb_printf and gdb_vprintf in more places

Luis pointed out that I missed a spot in the gdb_printf conversion --
namely aarch64-nat.c.  While looking at this, I found another spot in
darwin-nat.c that I also missed.  I can't build either of these, but I
think this patch should fix the problems.

Consolidate definition of current_directory

I noticed that both gdbserver and gdb define current_directory.
However, as it is referenced by gdbsupport, it seemed better to define
it there as well.  This patch also moves the declaration to
pathstuff.h.  Tested by rebuilding.

Decode "dynamic" interface types in Ada

In Ada, if a class implements an interface and has a dynamic
superclass, then the "offset to top" -- the offset that says how to
turn a pointer to the interface into a pointer to the whole object --
is stored in the object itself.  This patch changes GDB to understand
this.

Because this only touches Ada code, and because Joel already reviewed
it internally, I am checking it in.

Fix for MUL instruction on the v850

* sim/v850/simops.c (Multiply64): Properly test if we need to
negate either of the operands.

* sim/testsuite/v850/mul.cgs: New test.

Automatic date update in version.in

Remove two unused hooks

I noticed that a couple of deprecated hooks aren't ever called, so
they can't really be used by Insight.  This patch removes them
entirely.  I checked the Insight sources, and these aren't mentioned
there, either.

Remove unnecessary calls to wrap_here and gdb_flush

Various spots in gdb currently know about the wrap buffer, and so are
careful to call wrap_here to be certain that all output has been
flushed.

Now that the pager is just an ordinary stream, this isn't needed, and
a simple call to gdb_flush is enough.

Similarly, there are places where gdb prints to gdb_stderr, but first
flushes gdb_stdout.  stderr_file already flushes gdb_stdout, so these
aren't needed.

Minor comment updates in utils.h

This patch updates some comments in utils.h to more closely reflect
the new reality.

Remove vfprintf_styled

Nothing calls vfprintf_styled any more, so remove it.

Remove ui_out_flag::unfiltered_output

There is no longer any need for ui_out_flag::unfiltered_output --
nothing ever sets this flag.  This used to be needed to make the
_unfiltered output work, but now only printf_unfiltered can be used,
and it uses the puts_unfiltered method.  This patch removes the flag
and the dead code.

Rename fprintf_symbol_filtered

fprintf_symbol_filtered is misnamed, because whether filtering happens
is now up to the stream.  This renames it to fprintf_symbol, which
isn't a great name (the first "f" doesn't mean much and the second one
is truly meaningless here), but "print_symbol" was already taken.

Rename puts_filtered_tabular

puts_filtered_tabular is now misnamed, because whether filtering
happens is now up to the stream.  So, rename it.  (This function is
pretty weird, and should probably be rewritten to avoid using the
chars_printed global, and moved into objc-lang.c.  However, I haven't
done so.)

Rename print_spaces_filtered

print_spaces_filtered is now misnamed, because whether filtering
happens is up to the stream.  So, rename it.

Unify gdb printf functions

Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions.  This is done under the name
"gdb_printf".  Most of this patch was written by script.

Unify gdb putc functions

Now that filtered and unfiltered output can be treated identically, we
can unify the putc family of functions.  This is done under the name
"gdb_putc".  Most of this patch was written by script.

Unify gdb puts functions

Now that filtered and unfiltered output can be treated identically, we
can unify the puts family of functions.  This is done under the name
"gdb_puts".  Most of this patch was written by script.

Unify vprintf functions

Now that filtered and unfiltered output can be treated identically, we
can unify the vprintf family of functions: vprintf_filtered,
vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered.  (For
the gdb_stdout variants, recall that only printf_unfiltered gets truly
unfiltered output at this point.)  This removes one such function and
renames the remaining two to "gdb_vprintf".  All callers are updated.
Much of this patch was written by script.

Remove fputs_styled_unfiltered

fputs_styled_unfiltered is only called from cli_ui_out, so remove it.
This area will be further simplified in future patches.

Change the pager to a ui_file

This rewrites the output pager as a ui_file implementation.

A new header is introduced to declare the pager class.  The
implementation remains in utils.c for the time being, because there
are some static globals there that must be used by this code.  (This
could be cleaned up at some future date.)

I went through all the text output in gdb to ensure that this change
should be ok.  There are a few cases:

* Any existing call to printf_unfiltered is required to be avoid the
  pager.  This is ensured directly in the implementation.

* All remaining calls to the f*_unfiltered functions -- the ones that
  take an explicit ui_file -- either send to an unfiltered stream
  (e.g., gdb_stderr), which is obviously ok; or conditionally send to
  gdb_stdout

  I investigated all such calls by searching for:

    grep -e '\bf[a-z0-9_]*_unfiltered' *.[chyl] */*.[ch] | grep -v gdb_stdlog | grep -v gdb_stderr

  This yields a number of candidates to check.

  * The breakpoint _print_recreate family, and
    save_trace_state_variables.  These are used for "save" commands
    and so are fine.

  * Things printing to a temporary stream.  Obviously ok.

  * Disassembly selftests.

  * print_gdb_help - this is non-obvious, but ok because paging isn't
    yet enabled at this point during startup.

  * serial.c - doens't use gdb_stdout

  * The code in compile/.  This is all printing to a file.

  * DWARF DIE dumping - doesn't reference gdb_stdout.

* Calls to the _filtered form -- these are all clearly ok, because if
  they are using gdb_stdout, then filtering will still apply; and if
  not, then filtering never applied and still will not.

Therefore, at this point, there is no longer any distinction between
all the other _filtered and _unfiltered calls, and they can be
unified.

In this patch, take special note of the vfprintf_maybe_filtered and
ui_file::vprintf change.  This is one instance of the above idea,
erasing the distinction between filtered and unfiltered -- in this
part of the change, the "unfiltered_output" flag is never passe to
cli_ui_out.  Subsequent patches will go much further in this
direction.

Also note the can_emit_style_escape changes in ui-file.c.  Checking
against gdb_stdout or gdb_stderr was always a bit of a hack; and now
it is no longer needed, because this is decision can be more fully
delegated to the particular ui_file implementation.

ui_file::can_page is removed, because this patch removed the only call
to it.

I think this is the main part of fixing PR cli/7234.

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

Remove vfprintf_styled_no_gdbfmt

This removes vfprintf_styled_no_gdbfmt, inlining it at the sole point
of call.

Add style-escape methods to ui_file

This adds emit_style_escape and reset_style methods to ui_file.  These
aren't used yet, but they will be once the pager is converted to be a
ui_file subclass.

Add puts_unfiltered method to ui_file

When the pager is rewritten as a ui_file, gdb will still need a way to
bypass the filtering.  After examining a few approaches, I chose this
patch, which adds a puts_unfiltered method to ui_file.  For most
implementations of ui_file, this will just delegate to puts.  This
patch also switches printf_unfiltered to use the new method.

Only have one API for unfiltered output

At the end of this series, the use of unfiltered output will be very
restricted -- only places that definitely need it will use it.  To
this end, I thought it would be good to reduce the number of
_unfiltered APIs that are exposed.  This patch changes gdb so that
only printf_unfiltered exists.  (After this patch, the f* variants
still exist as well, but those will be removed later.)

Remove some uses of printf_unfiltered

A number of spots call printf_unfiltered only because they are in code
that should not be interrupted by the pager.  However, I believe these
cases are all handled by infrun's blanket ban on paging, and so can be
converted to the default (_filtered) API.

After this patch, I think all the remaining _unfiltered calls are ones
that really ought to be.  A few -- namely in complete_command -- could
be replaced by a scoped assignment to pagination_enabled, but for the
remainder, the code seems simple enough like this.

Use unfiltered output in annotate.c

It seems to me that annotations should not be filtered.  While it
might be weird for an annotation-based UI to use the pager, it's not,
I think, out of the question.  This patch makes this change.

gdb/remote: use current_inferior in read_ptid if multi-process not supported

When parsing the ptid out of a reply package, if the multi-process
extensions are not supported, use current_inferior's pid as the pid of
the reported thread, instead of inferior_ptid.  This is needed because
the inferior_ptid may be null_ptid although a legit context exists,
due to a prior context switch via switch_to_inferior_no_thread.

Below is a scenario that illustrates what could go wrong.  First,
setup a multi-target scenario.  This is needed, because in a
multi-target setting, the inferior_ptid is cleared out before waiting
on targets.  The second inferior below sits on top of a remote target.
Multi-process packets are disabled.

  $ # First, spawn a process with PID 26253 to attach to later.
  $ gdb-up a.out
  Reading symbols from a.out...
  (gdb) maint set target-non-stop on
  (gdb) set remote multiprocess-feature-packet off
  (gdb) start
  ...
  (gdb) add-inferior -no-connection
  [New inferior 2]
  Added inferior 2
  (gdb) inferior 2
  [Switching to inferior 2 [<null>] (<noexec>)]
  (gdb) target extended-remote | gdbserver --multi -
  Remote debugging using | gdbserver --multi -
  Remote debugging using stdio
  (gdb) attach 26253
  Attaching to Remote target
  Attached; pid = 26253
  [New Thread 26253]
  [New inferior 3]
  Reading /tmp/a.out from remote target...
  ...
  [New Thread 26253]
  ...
  Reading /usr/local/lib/debug/....debug from remote target...
  >>> GDB seems to hang here.

After attaching to a process and reading some library files, GDB
seems to hang.  One interesting thing to note is that

  [New Thread 26253]

appears twice.  We also see

  [New inferior 3]

Running the same scenario with "debug infrun on" reveals more details.

  ...
  (gdb) attach 26253
  [infrun] scoped_disable_commit_resumed: reason=attaching
  Attaching to Remote target
  Attached; pid = 26253
  [New Thread 26253]
  [infrun] infrun_async: enable=1
  [infrun] attach_command: immediately after attach:
  [infrun] attach_command:   thread 26253.26253.0, executing = 1, resumed = 0, state = RUNNING
  [infrun] clear_proceed_status_thread: 26253.26253.0
  [infrun] reset: reason=attaching
  [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
  [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
  [infrun] fetch_inferior_event: enter
    [infrun] scoped_disable_commit_resumed: reason=handling event
    [infrun] do_target_wait: Found 2 inferiors, starting at #1
    [infrun] random_pending_event_thread: None found.
    [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
    [infrun] print_target_wait_results:   26253.26253.0 [Thread 26253],
    [infrun] print_target_wait_results:   status->kind = STOPPED, sig = GDB_SIGNAL_0
    [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_0
    [infrun] start_step_over: enter
      [infrun] start_step_over: stealing global queue of threads to step, length = 0
      [infrun] operator(): step-over queue now empty
    [infrun] start_step_over: exit
    [infrun] context_switch: Switching context from 0.0.0 to 26253.26253.0
    [infrun] handle_signal_stop: stop_pc=0x7f849d8cf151
    [infrun] stop_waiting: stop_waiting
    [infrun] stop_all_threads: starting
    [infrun] stop_all_threads: pass=0, iterations=0
  [New inferior 3]
  Reading /tmp/a.out from remote target...
  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
  Reading /tmp/a.out from remote target...
  Reading symbols from target:/tmp/a.out...
  [New Thread 26253]
    [infrun] stop_all_threads:   4723.4723.0 not executing
    [infrun] stop_all_threads:   26253.26253.0 not executing
    [infrun] stop_all_threads:   42000.26253.0 executing, need stop
    [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
    [infrun] print_target_wait_results:   -1.0.0 [Thread 0],
    [infrun] print_target_wait_results:   status->kind = IGNORE
    [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
    [infrun] print_target_wait_results:   -1.0.0 [Thread 0],
    [infrun] print_target_wait_results:   status->kind = IGNORE

GDB tried to stop Thread 42000.26253.0, which does not exist, and we
are waiting for a stop event that will never happen.  The PID in
'42000.26253.0', namely 42000, is the PID of magic_null_ptid.
It comes from gdb/remote.c:read_ptid:

  /* Since the stub is not sending a process id, then default to
     what's in inferior_ptid, unless it's null at this point.  If so,
     then since there's no way to know the pid of the reported
     threads, use the magic number.  */
  if (inferior_ptid == null_ptid)
    pid = magic_null_ptid.pid ();
  else
    pid = inferior_ptid.pid ();

  if (obuf)
    *obuf = pp;
  return ptid_t (pid, tid);

Because multi-process was turned off, GDB did not parse an explicitly
specified PID.  Furthermore, inferior_ptid == null_ptid, and
eventually GDB picked the PID from magic_null_ptid.

If target-non-stop is not turned on at the beginning, the same bug
reveals itself as a duplicated thread as shown below.

  # Same setup as above, without 'maint set target-non-stop on'.
  ...
  (gdb) attach 26253
  Attaching to Remote target
  Attached; pid = 26253
  [New inferior 3]
  ...
  [New Thread 26253]
  ...
  (gdb) info threads
    Id   Target Id             Frame
    1.1  process 13517 "a.out" main () at test.c:3
  * 2.1  Thread 26253 "a.out"  0x00007f12750c5151 in read () from target:/lib/x86_64-linux-gnu/libc.so.6
    3.1  Thread 26253 "a.out"  Remote 'g' packet reply is too long (expected 560 bytes, got 2496 bytes): 00feffffffffffff000a3a75127f000051510c75127f0000000400000000000060d24ef6af5500000000000000000000680d000000000000b85b31e3fc7f0000c0283a75127f000000e55b75127f000010d04ef6af550000460200000000000060c73975127f0000a0d23975127f0000000a3a75127f0000000000000000000051510c75127f000046020000330000002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff0000000000000000000000000000000000000000000080143a75127f000080143a75127f000040143a75127f000040143a75127f00007d0000007e0000007f00000080000000300c3a75127f0000300c3a75127f00000e000000000000000e0000000000000000000000000000000000000000000000ffffffffffffffffffffffffffffffff0400000004000000040000000400000020143a75127f000020143a75127f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000000000000000000000e55b75127f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  (gdb)

Fix the problem by preferring current_inferior()'s pid instead of
magic_null_ptid.

Regression-tested on X86-64 Linux.

Co-authored-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>

gdb/testsuite: fix test failure when building against readline v7

The test added in the commit:

  commit a6b413d24ccc5d76179bab866834e11fd6fec294
  Date:   Fri Mar 11 14:44:03 2022 +0000

      gdb: work around prompt corruption caused by bracketed-paste-mode

Was not written with readline 7 in mind, only readline 8+.  Between
readline 7 and 8 the escape sequence used to disable bracketed paste
mode changed, an additional '\r' character was added to the end.  In
fact, it was the addition of this '\r' character that triggered the
issue for which the above commit is part of the solution.

Anyway, the test tries to spot the case where the output from GDB is
not perfect, but does have the above work around applied.  However,
the pattern in the test assumes that the problematic '\r' will be
present, and this is only true for readline 8+.  With readline 7 the
test was failing.

In this commit I generalise the pattern a little so that the test will
still KFAIL with readline 7.

It's a little unfortunate that the test is KFAILing with readline 7,
as without the problematic '\r' there's actually no reason that GDB
couldn't "do the right thing" in this case, in which case, the test
would PASS, but that would require changes within GDB itself.

My preference then is that initially we patch the test to get it
KFAILing, then in a separate commit I can modify GDB so that it can
PASS with readline 7.

gdb/testsuite: fix copy & paste error in gdb.python/py-format-address.exp

The test gdb.python/py-format-address.exp, added in commit:

  commit 25209e2c6979c3838e14e099f0333609810db280
  Date:   Sat Oct 23 09:59:25 2021 +0100

      gdb/python: add gdb.format_address function

included 3 copy & paste errors where the wrong address was used in the
expected output patterns.

The test compiles two almost identical test binaries (one function
changes its name, that's the only difference), two inferiors are
created, each inferior using one of the test binaries.

We then take the address of the name changing function in both
inferiors ('foo' in inferior 1 and 'bar' in inferior 2) and the tests
are carried out using these addresses.

What we're checking for is that symbols 'foo' and 'bar' show up in the
correct inferior, and that (as this test is for a Python API feature),
the user can have one inferior selected, but ask about the other
inferior, and see the correct symbol in the result.

The hope is that the two binaries will be laid out identically by the
compiler, and that 'foo' and 'bar' will be at the same address.  This
is fine, unless the executable is compiled as PIE (position
independent executable), in which case there is a problem.

The problem is that though inferior 1 is set running, the inferior 2
never is.  If the executables are compiled as PIE, then the address in
the inferior 2 will not have been resolved, while the address in the
inferior 1 will have been, and so the two addresses we use in the
tests will be different.

This issue was reported here:

  https://sourceware.org/pipermail/gdb-patches/2022-March/186911.html

The first part of the fix is to use the correct address variable in
the expected output patterns, with this change the tests pass even
when the executables are compiled as PIE.

A second part of this fix is to pass the 'nopie' option when we
compile the tests, this should ensure that the address obtained in
inferior 2 is the same as the address from inferior 1, which makes the
test more useful.

gdb/mi: fix use after free of frame_info causing spurious notifications

In commit:

  commit a2757c4ed693cef4ecc4dcdcb2518353eb6b3c3f
  Date:   Wed Mar 16 15:08:22 2022 +0000

      gdb/mi: consistently notify user when GDB/MI client uses -thread-select

Changes were made to GDB to address some inconsistencies in when
notifications are sent from a MI terminal to a CLI terminal (when
multiple terminals are in use, see new-ui command).

Unfortunately, in order to track when the currently selected frame has
changed, that commit grabs a frame_info pointer before and after an MI
command has executed, and compares the pointers to see if the frame
has changed.

This is not safe.

If the frame cache is deleted for any reason then the frame_info
pointer captured before the command started, is no longer valid, and
any comparisons based on that pointer are undefined.

This was leading to random test failures for some folk, see:

  https://sourceware.org/pipermail/gdb-patches/2022-March/186867.html

This commit changes GDB so we no longer hold frame_info pointers, but
instead store the frame_id and frame_level, this is safe even when the
frame cache is flushed.

bfd/Dwarf2: gas doesn't mangle names

Include the language identifier emitted by gas in the set of ones where
no mangled names are expected. Even if there could be "hand-mangled"
names, gas doesn't emit DW_AT_linkage_name in the first place.

bfd/Dwarf2: make find-nearest-line returned function name consistent

Prior to entering the enclosing "else if()" the earlier associated if()
checks function->is_linkage and, if set, uses function->name. The
comment in patch context precedes (and explains) the setting
function->is_linkage. Yet with the flag set, we should then also return
the function name, just like said earlier if() would do when we came
here a 2nd time for the same "addr". And indeed passing the same address
twice on addr2line's command line would resolve the function for the 2nd
instance, but not for the 1st (if this code path is taken). (This,
obviously, is particularly relevant when there's no ELF symbol table in
the first place, like would be the case - naturally - in PE/COFF
binaries, for example.)

gas/Dwarf: special-case .linefile only for macros

Restrict the PR gas/16908 workaround to just macros, matching the
original intention as well as the comment there. For constructs like
.irp or .rept the reasoning doesn't apply, as there's no separate
"invocation" point which may be of interest to record (for, as said
there, short macros).

RISC-V: correct FCVT.Q.L[U]

While the spec isn't explicit about this, it pointing out the similarity
with the D extension ought to extend to the ignoring of a meaningless
rounding mode: "Note FCVT.D.W[U] always produces an exact result and is
unaffected by rounding mode." Hence the chosen encodings also ought to
match.

Note that to avoid breaking existing code the forms with a 3rd operand
are not removed, which means there continues to be a difference to
FCVT.D.W[U].

sim: add arch/.gdbinit stub scripts

Make it easy to load the common gdbinit script even when running in
the arch/ subdir instead of the top-level sim dir.

asan: heap buffer overflow in pa_chk_field_selector

The buffer overflow showed up running the gas "all macro" test.

PR 29005
* config/tc-hppa.c (pa_chk_field_selector): Don't read past end
of line.

Automatic date update in version.in

Add Rust parser check for end of expression

I noticed that "print 5," passed in Rust -- the parser wasn't checking
that the entire input was used.  This patch fixes the problem.  This
in turn pointed out another bug in the parser, namely that it didn't
lex the next token after handling a string token.  This is also fixed
here.

Switch gdb_stdlog to use timestamped_file

Currently, timestamps for logging are done by looking for the use of
gdb_stdlog in vfprintf_unfiltered.  This seems potentially buggy, in
that during logging or other redirects (like execute_fn_to_ui_file) we
might have gdb_stdout==gdb_stdlog and so, conceivably, wind up with
timestamps in a log when they were not desired.

It seems better, instead, for timestamps to be a property of the
ui_file itself.

This patch changes gdb to use the new timestamped_file for gdb_stdlog
where appropriate, and removes the special case from
vfprintf_unfiltered.

Note that this may somewhat change the output in some cases -- in
particular, when going through execute_fn_to_ui_file (or the _string
variant), timestamps won't be emitted.  This could be fixed in those
functions, but it wasn't clear to me whether this is really desirable.

Note also that this changes the TUI to send gdb_stdlog to gdb_stderr.
I imagine that the previous use of gdb_stdout here was inadvertent.
(And in any case it probably doesn't matter.)

Add new timestamped_file class

This adds a "timestamped_file" subclass of ui_file.  This class adds a
timestamp to its output when appropriate.  That is, it follows the
rule already used in vfprintf_unfiltered of adding a timestamp at most
once per write.

The new class is not yet used.

Use unique_ptr in CLI logging code

This changes the CLI logging code to avoid manual memory management
(to the extent possible) by using unique_ptr in a couple of spots.
This will come in handy in a later patch.

Simplify the CLI set_logging logic

The CLI's set_logging logic seemed unnecessarily complicated to me.
This patch simplifies it, with an eye toward changing it to use RAII
objects in a subsequent patch.

I did not touch the corresponding MI code.  That code seems incorrect
(nothing ever uses raw_stdlog, and nothing ever sets
saved_raw_stdlog).  I didn't attempt to fix this, because I question
whether this is even useful for MI.

Handle multiple addresses in call_site_target

A large customer program has a function that is partitioned into hot
and cold parts.  A variable in a callee of this function is described
using DW_OP_GNU_entry_value, but gdb gets confused when trying to find
the caller.  I tracked this down to dwarf2_get_pc_bounds interpreting
the function's changes so that the returned low PC is the "wrong"
function.

Intead, when processing DW_TAG_call_site, the low PC of each range in
DW_AT_ranges should be preserved in the call_site_target.  This fixes
the variable lookup in the test case I have.

I didn't write a standalone test for this as it seemed excessively
complicated.

Change call_site_target to iterate over addresses

In order to handle the case where a call site target might refer to
multiple addresses, we change the code to use a callback style.  Any
spot using call_site_target::address now passes in a callback function
that may be called multiple times.

Change call_site_find_chain_1 to work recursively

call_site_find_chain_1 has a comment claiming that recursive calls
would be too expensive.  However, I doubt this is so expensive; and
furthermore the explicit state management approach here is difficult
both to understand and to modify.  This patch changes this code to use
explicit recursion, so that a subsequent patch can generalize this
code without undue trauma.

Additionally, I think this patch detects a latent bug in the recursion
code.  (It's hard for me to be completely certain.)  The bug is that
when a new target_call_site is entered, the code does:

  if (target_call_site)
    {
      if (addr_hash.insert (target_call_site->pc ()).second)
{
  /* Successfully entered TARGET_CALL_SITE.  */

  chain.push_back (target_call_site);
  break;
}
    }

Here, if entering the target_call_site fails, then any tail_call_next
elements in this call site are not visited.  However, if this code
does happen to enter a call site, then the tail_call_next elements
will be visited during backtracking.  This applies when doing the
backtracking as well -- it will only continue through a given chain as
long as each element in the chain can successfully be visited.

I'd appreciate some review of this.  If this behavior is intentional,
it can be added to the new implementation.

Constify chain_candidate

While investigating this bug, I wasn't sure if chain_candidate might
update 'chain'.  I changed it to accept a const reference, making it
clear that it cannot.  This simplifies the code a tiny bit as well.

Make call_site_target members private

This makes the data members of call_site_target 'private'.  This lets
us remove most of its public API.  call_site_to_target_addr is changed
to be a method of this type.  This is a preparatory refactoring for
the fix at the end of this series.

Change call_site_target to use custom type and enum

call_site_target reuses field_loc_kind and field_location.  However,
it has never used the full range of the field_loc_kind enum.  In a
subsequent patch, I plan to add a new 'kind' here, so it seemed best
to avoid this reuse and instead introduce new types here.

Automatic date update in version.in

Automatic date update in version.in

Remove an unused declaration from value.h

value.h has a declaration of value_print_array_elements that is
incorrect.  In C, this would have been an error, but in C++ this is a
declaration of an overload that is neither defined nor used.  This
patch removes the declaration.

Automatic date update in version.in

libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case

My previous nm patch handled all cases but one -- if the user set NM in
the environment to a path which contained an option, libtool's nm
detection tries to run nm against a copy of nm with the options in it:
e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
This is unlikely to be desirable: in this case we should run
"/usr/bin/nm --blargle /usr/bin/nm".

Furthermore, as part of this nm has to detect when the passed-in $NM
contains a path, and in that case avoid doing a path search itself.
This too was thrown off if an option contained something that looked
like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
"nm -B../prev-gcc nm" which rarely works well (and indeed it looks
to see whether that nm exists, finds it doesn't, and wrongly concludes
that nm -p or whatever does not work).

Fix all of these by clipping all options (defined as everything
including and after the first " -") before deciding whether nm
contains a path (but not using the clipped value for anything else),
and then removing all options from the path-modified nm before
looking to see whether that nm existed.

NM=my-nm now does a path search and runs e.g.
  /usr/bin/my-nm -B /usr/bin/my-nm

NM=/usr/bin/my-nm now avoids a path search and runs e.g.
  /usr/bin/my-nm -B /usr/bin/my-nm

NM="my-nm -p../wombat" now does a path search and runs e.g.
  /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm

NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
  ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm

This seems to be all combinations, including those used by GCC bootstrap
(which, before this commit, fails to bootstrap when configured
--with-build-config=bootstrap-lto, because the lto plugin is now using
--export-symbols-regex, which requires libtool to find a working nm,
while also using -B../prev-gcc to point at the lto plugin associated
with the GCC just built.)

Regenerate all affected configure scripts.

* libtool.m4 (LT_PATH_NM): Handle user-specified NM with
options, including options containing paths.

Re: gas/Dwarf: improve debug info generation from .irp and alike blocks

am33_2.0-linux is a mn10300 target.

* testsuite/gas/elf/dwarf-5-irp.d: xfail am33.

Automatic date update in version.in

Remove download size from debuginfod progress messages if unavailable

Currently debuginfod progress update messages include the size of
each download:

  Downloading 7.5 MB separate debug info for /lib/libxyz.so.0

This value originates from the Content-Length HTTP header of the
transfer.  However this header is not guaranteed to be present for
each download.  This can happen when debuginfod servers compress files
on-the-fly at the time of transfer.  In this case gdb wrongly prints
"-0.00 MB" as the size.

This patch removes download sizes from progress messages when they are
not available.  It also removes usage of the progress bar until
a more thorough reworking of progress updating is implemented. [1]

[1] https://sourceware.org/pipermail/gdb-patches/2022-February/185798.html

sim: fix a comment typo in sim-load.c

Fix a typo where the documentation refers to a function parameter by the
wrong name.

Change-Id: I99494efe62cd4aa76fb78a0bd5da438d35740ebe

sim: fix “alligned” typos

Change-Id: Ifd574e38524dd4f1cf0fc003e0c5c7499abc84a0

x86: mention dropped L1OM/K1OM support in ld/ as well

This amends e961c696dcb2 ("x86: drop L1OM/K1OM support from ld"). Also
remove the marker that I mistakenly added in c085ab00c7b2 ("x86: drop
L1OM/K1OM support from gas").

gdb/testsuite: remove gdb.python/pretty-print-call-by-hand.exp

This test was added without a corresponding fix, with some setup_kfails.
However, it results in UNRESOLVED results when GDB is built with ASan.

  ERROR: GDB process no longer exists
  GDB process exited with wait status 1946871 exp7 0 1
  UNRESOLVED: gdb.python/pretty-print-call-by-hand.exp: frame print: backtrace test (PRMS gdb/28856)

Remove the test from the tree, I'll attach it to the Bugzilla bug
instead [1].

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

Change-Id: Id95d8949fb8742874bd12aeac758aa4d7564d678

x86: drop L1OM/K1OM support from ld

This was only rudimentary support anyway; none of the sub-architecture
specific insns were ever supported.

x86: drop L1OM special case from disassembler

There wasn't any real support anyway: None of the sub-architecture
specific insns were ever supported.

MAINTAINERS: add myself

I much appreciate Nick offering this role to me. Nevertheless there's
still a lot for me to learn here.

At this occasion also update my email address in the pre-existing, much
more narrow entry.

Automatic date update in version.in

gdb/testsuite: address test failures in gdb.mi/mi-multi-commands.exp

The gdb.mi/mi-multi-commands.exp test was added in commit:

  commit d08cbc5d3203118da5583296e49273cf82378042
  Date:   Wed Dec 22 12:57:44 2021 +0000

      gdb: unbuffer all input streams when not using readline

And then tweaked in commit:

  commit 144459531dd68a1287905079aaa131b777a8cc82
  Date:   Mon Feb 7 20:35:58 2022 +0000

      gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test

The second of these commits was intended to address periodic test
failures that I was seeing, and this change did fix some problems,
but, unfortunately, introduced other issues.

The problem is that the test relies on sending two commands to GDB in
a single write.  As the characters that make these two commands arrive
they are echoed to GDB's console.  However, there is a race between
how quickly the characters are echoed and how quickly GDB decides to
act on the incoming commands.

Usually, both commands are echoed in full before GDB acts on the first
command, but sometimes this is not the case, and GDB can execute the
first command before both commands are fully echoed to the console.
In this case, the output of the first command will be mixed in with
the echoing of the second command.

This mixing of the command echoing and the first command output is
what was causing failures in the original version of the test.

The second commit relaxed the expected output pattern a little, but
was still susceptible to failures, so this commit further relaxes the
pattern.

Now, we look for the first command output with no regard to what is
before, or after the command.  Then we look for the first mi prompt to
indicate that the first command has completed.

I believe that this change should make the test more stable than it
was before.

libctf: add LIBCTF_WRITE_FOREIGN_ENDIAN debugging option

libctf has always handled endianness differences by detecting
foreign-endian CTF dicts on the input and endian-flipping them: dicts
are always written in native endianness.  This makes endian-awareness
very low overhead, but it means that the foreign-endian code paths
almost never get routinely tested, since "make check" usually reads in
dicts ld has just written out: only a few corrupted-CTF tests are
actually in fixed endianness, and even they only test the foreign-
endian code paths when you run make check on a big-endian machine.
(And the fix is surely not to add more .s-based tests like that, because
they are a nightmare to maintain compared to the C-code-based ones.)

To improve on this, add a new environment variable,
LIBCTF_WRITE_FOREIGN_ENDIAN, which causes libctf to unconditionally
endian-flip at ctf_write time, so the output is always in the wrong
endianness.  This then tests the foreign-endian read paths properly
at open time.

Make this easier by restructuring the writeout code in ctf-serialize.c,
which duplicates the maybe-gzip-and-write-out code three times (once
for ctf_write_mem, with thresholding, and once each for
ctf_compress_write and ctf_write just so those can avoid thresholding
and/or compression).  Instead, have the latter two call the former
with thresholds of 0 or (size_t) -1, respectively.

The endian-flipping code itself gains a bit of complexity, because
one single endian-flipper (flip_types) was assuming the input to be
in foreign-endian form and assuming it could pull things out of the
input once they had been flipped and make sense of them. At the
cost of a few lines of duplicated initializations, teach it to
read before flipping if we're flipping to foreign-endianness instead
of away from it.

libctf/
* ctf-impl.h (ctf_flip_header): No longer static.
(ctf_flip): Likewise.
* ctf-open.c (flip_header): Rename to...
(ctf_flip_header): ... this, now it is not private to one file.
(flip_ctf): Rename...
(ctf_flip): ... this too.  Add FOREIGN_ENDIAN arg.
(flip_types): Likewise.  Use it.
(ctf_bufopen_internal): Adjust calls.
* ctf-serialize.c (ctf_write_mem): Add flip_endian path via
a newly-allocated bounce buffer.
(ctf_compress_write): Move below ctf_write_mem and reimplement
in terms of it.
(ctf_write): Likewise.
(ctf_gzwrite): Note that this obscure writeout function does not
support endian-flipping.

libctf, ld: diagnose corrupted CTF header cth_strlen

The last section in a CTF dict is the string table, at an offset
represented by the cth_stroff header field.  Its length is recorded in
the next field, cth_strlen, and the two added together are taken as the
size of the CTF dict.  Upon opening a dict, we check that none of the
header offsets exceed this size, and we check when uncompressing a
compressed dict that the result of the uncompression is the same length:
but CTF dicts need not be compressed, and short ones are not.
Uncompressed dicts just use the ctf_size without checking it.  This
field is thankfully almost unused: it is mostly used when reserializing
a dict, which can't be done to dicts read off disk since they're
read-only.

However, when opening an uncompressed foreign-endian dict we have to
copy it out of the mmaped region it is stored in so we can endian-
swap it, and we use ctf_size when doing that.  When the cth_strlen is
corrupt, this can overrun.

Fix this by checking the ctf_size in all uncompressed cases, just as we
already do in the compressed case.  Add a new test.

This came to light because various corrupted-CTF raw-asm tests had an
incorrect cth_strlen: fix all of them so they produce the expected
error again.

libctf/
PR libctf/28933
* ctf-open.c (ctf_bufopen_internal): Always check uncompressed
CTF dict sizes against the section size in case the cth_strlen is
corrupt.

ld/
PR libctf/28933
* testsuite/ld-ctf/diag-strlen-invalid.*: New test,
derived from diag-cttname-invalid.s.
* testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect cth_strlen.
* testsuite/ld-ctf/diag-cttname-null.s: Likewise.
* testsuite/ld-ctf/diag-cuname.s: Likewise.
* testsuite/ld-ctf/diag-parlabel.s: Likewise.
* testsuite/ld-ctf/diag-parname.s: Likewise.

include, libctf, ld: extend variable section to contain functions too

The CTF variable section is an optional (usually-not-present) section in
the CTF dict which contains name -> type mappings corresponding to data
symbols that are present in the linker input but not in the output
symbol table: the idea is that programs that use their own symbol-
resolution mechanisms can use this section to look up the types of
symbols they have found using their own mechanism.

Because these removed symbols (mostly static variables, functions, etc)
all have names that are unlikely to appear in the ELF symtab and because
very few programs have their own symbol-resolution mechanisms, a special
linker flag (--ctf-variables) is needed to emit this section.

Historically, we emitted only removed data symbols into the variable
section.  This seemed to make sense at the time, but in hindsight it
really doesn't: functions are symbols too, and a C program can look them
up just like any other type.  So extend the variable section so that it
contains all static function symbols too (if it is emitted at all), with
types of kind CTF_K_FUNCTION.

This is a little fiddly.  We relied on compiler assistance for data
symbols: the compiler simply emits all data symbols twice, once into the
symtypetab as an indexed symbol and once into the variable section.

Rather than wait for a suitably adjusted compiler that does the same for
function symbols, we can pluck unreported function symbols out of the
symtab and add them to the variable section ourselves.  While we're at
it, we do the same with data symbols: this is redundant right now
because the compiler does it, but it costs very little time and lets the
compiler drop this kludge and save a little space in .o files.

include/
* ctf.h: Mention the new things we can see in the variable
section.

ld/
* testsuite/ld-ctf/data-func-conflicted-vars.d: New test.

libctf/
* ctf-link.c (ctf_link_deduplicating_variables): Duplicate
symbols into the variable section too.
* ctf-serialize.c (symtypetab_delete_nonstatic_vars): Rename
to...
(symtypetab_delete_nonstatics): ... this.  Check the funchash
when pruning redundant variables.
(ctf_symtypetab_sect_sizes): Adjust accordingly.
* NEWS: Describe this change.

ld, testsuite: improve CTF-availability test

The test for -gctf support in the compiler is used to determine when to
run the ld-ctf tests and most of those in libctf.  Unfortunately,
because it uses check_compiler_available and compile_one_cc, it will
fail whenever the compiler emits anything on stderr, even if it
actually does support CTF perfectly well.

So, instead, ask the compiler to emit assembler output and grep it for
references to ".ctf": this is highly unlikely to be present if the
compiler does not support CTF.  (This will need adjusting when CTF grows
support for non-ELF platforms that don't dot-prepend their section
names, but right now the linker doesn't link CTF on any such platforms
in any case.)

With this in place we can do things like run all the libctf tests under
leak sanitizers etc even if those spray warnings on simple CTF
compilations, rather than being blocked from doing so just when we would
most like to.

ld/
* testsuite/lib/ld-lib.exp (check_ctf_available): detect CTF
even if a CTF-capable compiler emits warnings.

gdb/python: remove Python 2/3 compatibility macros

New in this version:

 - Rebase on master, fix a few more issues that appeared.

python-internal.h contains a number of macros that helped make the code
work with both Python 2 and 3.  Remove them and adjust the code to use
the Python 3 functions.

Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d

gdb/python: remove Python 2 support

New in this version:

 - Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON.  If
   the user passes --with-python=python2, this will cause a configure
   failure saying that GDB only supports Python 3.

Support for Python 2 is a maintenance burden for any patches touching
Python support.  Among others, the differences between Python 2 and 3
string and integer types are subtle.  It requires a lot of effort and
thinking to get something that behaves correctly on both.  And that's if
the author and reviewer of the patch even remember to test with Python
2.

See this thread for an example:

  https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html

So, remove Python 2 support.  Update the documentation to state that GDB
can be built against Python 3 (as opposed to Python 2 or 3).

Update all the spots that use:

 - sys.version_info
 - IS_PY3K
 - PY_MAJOR_VERSION
 - gdb_py_is_py3k

... to only keep the Python 3 portions and drop the use of some
now-removed compatibility macros.

I did not update the configure script more than just removing the
explicit references to Python 2.  We could maybe do more there, like
check the Python version and reject it if that version is not
supported.  Otherwise (with this patch), things will only fail at
compile time, so it won't really be clear to the user that they are
trying to use an unsupported Python version.  But I'm a bit lost in the
configure code that checks for Python, so I kept that for later.

Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62

x86: reject relocations involving registers

To prevent fatal or even internal errors, add a simple check to
i386_validate_fix(), rejecting relocations when their target symbol is
an equate of a register (or resolved to reg_section for any other
reason).

x86: improve resolution of register equates

Allow transitive (or recursive) equates to work in addition to direct
ones. The only requirements are that
- the equate being straight of a register, i.e. no expressions involved
  (albeit I'm afraid something like "%eax + 0" will be viewed as %eax),
- at the point of use there's no forward ref left which cannot be
  resolved, yet.

Revert "PR28977 tc-i386.c internal error in parse_register"

This reverts commit 5fac3f02edacfca458f7eeaaaa33a87e26e0e332,
which was superceeded / replaced by 4faaa10f3fab.

x86: don't attempt to resolve equates and alike from i386_parse_name()

PR gas/28977

Perhaps right from its introduction in 4d1bb7955a8b it was wrong for
i386_parse_name() to call parse_register(). This being a hook from the
expression parser, it shouldn't be resolving e.g. equated symbols.
That's relevant only for all other callers of parse_register().

To compensate, in Intel syntax mode check_register() needs calling;
perhaps not doing so was an oversight right when the function was
introduced. This is necessary in particular to force EVEX encoding when
VRex registers are used (but of course also to reject bad uses of
registers, i.e. fully matching what parse_register() needs it for).