Automatic date update in version.in

PR gdb/27876 - debuginfod-downloaded source files don't pass proper fullname across mi / (gdb)info source

Source files downloaded from debuginfod currently use their original DWARF
filename as their "fullname".  This causes a mismatch between the fullname
and the actual location of the source file in the debuginfod client cache.

MI consumers such as VSCode will fail to open debuginfod-downloaded
source files due to this.  Also 'info source' will fail to include the
true paths of these files.

To fix this, use the debuginfod cache path as the fullname for debuginfod-
downloaded source files.

gdb/mi: preserve user selected thread and frame when invoking MI commands

Fix for PR gdb/20684.  When invoking MI commands with --thread and/or
--frame, the user selected thread and frame was not preserved:

  (gdb)
  info thread
  &"info thread\n"
  ~"  Id   Target Id                                           Frame \n"
  ~"* 1    Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
  ~"  2    Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
  ~"  3    Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
  ^done
  (gdb)
  info frame
  &"info frame\n"
  ~"Stack level 0, frame at 0x7fffffffdf90:\n"
  ~" rip = 0x555555555207 in main (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b\n"
  ~" source language c.\n"
  ~" Arglist at 0x7fffffffdf80, args: \n"
  ~" Locals at 0x7fffffffdf80, Previous frame's sp is 0x7fffffffdf90\n"
  ~" Saved registers:\n "
  ~" rbp at 0x7fffffffdf80, rip at 0x7fffffffdf88\n"
  ^done
  (gdb)
  -stack-info-depth --thread 3
  ^done,depth="4"
  (gdb)
  info thread
  &"info thread\n"
  ~"  Id   Target Id                                           Frame \n"
  ~"  1    Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
  ~"  2    Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
  ~"* 3    Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
  ^done
  (gdb)
  info frame
  &"info frame\n"
  ~"Stack level 0, frame at 0x7ffff742dee0:\n"
  ~" rip = 0x555555555169 in child_sub_function (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30); saved rip = 0x555555555188\n"
  ~" called by frame at 0x7ffff742df00\n"
  ~" source language c.\n"
  ~" Arglist at 0x7ffff742ded0, args: \n"
  ~" Locals at 0x7ffff742ded0, Previous frame's sp is 0x7ffff742dee0\n"
  ~" Saved registers:\n "
  ~" rbp at 0x7ffff742ded0, rip at 0x7ffff742ded8\n"
  ^done
  (gdb)

This caused problems for frontends that provide access to CLI because UI
may silently change the context for CLI commands (as demonstrated above).

This commit fixes the problem by restoring thread and frame in
mi_cmd_execute (). With this change, there are only two GDB/MI commands
that can change user selected context: -thread-select and -stack-select-frame.
This allows us to remove all and rather complicated logic of notifying
about user selected context change from mi_execute_command (), leaving it
to these two commands themselves to notify.

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

gdb: announce upcoming removal of Python 2 support from gdb

As has been discussed here:

  https://sourceware.org/pipermail/gdb-patches/2022-January/184910.html

Python 2 support will be removed from GDB after GDB 12 has branched.
This commit places an entry in the NEWS file to inform users of this
decision.

Automatic date update in version.in

gdb/testsuite: add new test for comparing char types in Python

There's an interesting property of the 'char' type in C and C++, the
three types 'char', 'unsigned char', and 'signed char', are all
considered distinct.

In contrast, and 'int' is signed by default, and so 'int' and 'signed
int' are considered the same type.

This commit adds a test to ensure that this edge case is visible to a
user from Python.

It is worth noting that for any particular compiler implementation (or
the flags a compiler was invoked with), a 'char' will be either signed
or unsigned; it has to be one or the other, and a user can access this
information by using the Type.is_signed property.  However, for
something like function overload resolution, the 'char' type is
considered distinct from the signed and unsigned variants.

There's no change to GDB with this commit, this is just adding a new
test to guard some existing functionality.

gdb/python: add Type.is_signed property

Add a new read-only property, Type.is_signed, which is True for signed
types, and False otherwise.

This property should only be read on types for which Type.is_scalar is
true, attempting to read this property for non-scalar types will raise
a ValueError.

I chose 'is_signed' rather than 'is_unsigned' in order to match the
existing Architecture.integer_type method, which takes a 'signed'
parameter.  As far as I could find, that was the only existing
signed/unsigned selector in the Python API, so it seemed reasonable to
stay consistent.

gdb/python: add Type.is_scalar property

Add a new read-only property which is True for scalar types,
otherwise, it's False.

gdb/mi: add --no-connection to MI -add-inferior command

Following on from the previous commit, where the -add-inferior command
now uses the same connection as the current inferior, this commit adds
a --no-connection option to -add-inferior.

This new option matches the existing option of the same name for the
CLI version of add-inferior; the new inferior is created with no
connection.

I've added a new 'connection' field to the MI output of -add-inferior,
which includes the connection number and short name.  I haven't
included the longer description field, this is the MI after all.  My
expectation would be that if the frontend wanted to display all the
connection details then this would be looked up from 'info
connection' (or the MI equivalent if/when such a command is added).

The existing -add-inferior tests are updated, as are the docs.

gdb/mi: fix regression in mi -add-inferior command

Prior to the multi-target support commit:

  commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2
  Date:   Fri Jan 10 20:06:08 2020 +0000

      Multi-target support

When a new inferior was added using the MI -add-inferior command, the
new inferior would be using the same target as all the other
inferiors.  This makes sense, GDB only supported a single target stack
at a time.

After the above commit, each inferior has its own target stack.

To maintain backward compatibility, for the CLI add-inferior command,
when a new inferior is added the above commit has the new inferior
inherit a copy of the target stack from the current inferior.

Unfortunately, this same backward compatibility is missing for the MI.

This commit fixes this oversight.

Now, when the -add-inferior MI command is used, the new inferior will
inherit a copy of the target stack from the current inferior.

Deprecate dbx mode

GDB has a dbx emulation mode that adds a few aliases and helper
commands.  This mode is barely documented and is very superficial
besides.  I suspect it is rarely used, and I would like to propose
deprecating it for GDB 12, and then removing it in GDB 13.

Remove unnecessary inferior lookup in infrun:handle_one

infrun.c:handle_one calls find_inferior_ptid unnecessarily, since we
already have a thread pointer handy, and the thread has a pointer to
the inferior.  This commit removes the unnecessary lookup.

Change-Id: I2ae18601dd75346c6c91068e9a4f9a6484fb3339

Fix bug in ada_print_floating

ada_print_floating rewrites a floating-point string representation to
conform to Ada syntax.  However, if you managed to get a floating
point error, you might see:

    (gdb) print whatever
    $2 = <invalid float valu.0e>

What's happening here is that ada_print_floating doesn't recognize
this error case, and proceeds to modify the error text.

This patch fixes this problem.

Implement real literal extension for Ada

Sometimes it is convenient to be able to specify the exact bits of a
floating-point literal.  For example, you may want to set a
floating-point register to a denormalized value, or to a particular
NaN.

In C, you can do this by combining the "{}" cast with an array
literal, like:

    (gdb) p {double}{0x576488BDD2AE9FFE}
    $1 = 9.8765449999999996e+112

This patch adds a somewhat similar idea to Ada.  It extends the lexer
to allow "l" and "f" suffixes in a based literal.  The "f" indicates a
floating-point literal, and the "l"s control the size of the
floating-point type.

Note that this differs from Ada's based real literals.  I believe
those can also be used to control the bits of a floating-point value,
but they are a bit more cumbersome to use (simplest is binary but
that's also very lengthy).  Also, these aren't implemented in GDB.

I chose not to allow this extension to work with based integer
literals with exponents.  That didn't seem very useful.

Fix Ada integer literals with exponents

While working on another patch, I noticed that Ada integer literals
with exponents did not work.  For example, with one form you get an
error:

    (gdb) print 8e2
    Invalid digit `e' in based literal

And with another form you get an incorrect value:

    (gdb) print 16#8#e2
    $2 = 8

This patch fixes the bugs and adds tests.

Fix gdb.ada/arrayptr.exp results

PR ada/28115 points out that gdb.ada/arrayptr.exp works with GNAT 12,
but fails with minimal encodings in earlier versions.

This patch updates the test to try to report the results correctly.  I
tried this with the Fedora 34 system gcc (GCC 11) and with a GCC 12
built from git trunk sometime relatively recently.

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

Handle non-ASCII identifiers in Ada

Ada allows non-ASCII identifiers, and GNAT supports several such
encodings.  This patch adds the corresponding support to gdb.

GNAT encodes non-ASCII characters using special symbol names.

For character sets like Latin-1, where all characters are a single
byte, it uses a "U" followed by the hex for the character.  So, for
example, thorn would be encoded as "Ufe" (0xFE being lower case
thorn).

For wider characters, despite what the manual says (it claims
Shift-JIS and EUC can be used), in practice recent versions only
support Unicode.  Here, characters in the base plane are represented
using "Wxxxx" and characters outside the base plane using
"WWxxxxxxxx".

GNAT has some further quirks here.  Ada is case-insensitive, and GNAT
emits symbols that have been case-folded.  For characters in ASCII,
and for all characters in non-Unicode character sets, lower case is
used.  For Unicode, however, characters that fit in a single byte are
converted to lower case, but all others are converted to upper case.

Furthermore, there is a bug in GNAT where two symbols that differ only
in the case of "Y WITH DIAERESIS" (and potentially others, I did not
check exhaustively) can be used in one program.  I chose to omit
handling this case from gdb, on the theory that it is hard to figure
out the logic, and anyway if the bug is ever fixed, we'll regret
having a heuristic.

This patch introduces a new "ada source-charset" setting.  It defaults
to Latin-1, as that is GNAT's default.  This setting controls how "U"
characters are decoded -- W/WW are always handled as UTF-32.

The ada_tag_name_from_tsd change is needed because this function will
read memory from the inferior and interpret it -- and this caused an
encoding failure on PPC when running a test that tries to read
uninitialized memory.

This patch implements its own UTF-32-based case folder.  This avoids
host platform quirks, and is relatively simple.  A short Python
program to generate the case-folding table is included.  It simply
relies on whatever version of Unicode is used by the host Python,
which seems basically acceptable.

Test cases for UTF-8, Latin-1, and Latin-3 are included.  This
exercises most of the new code paths, aside from Y WITH DIAERESIS as
noted above.

Define HOST_UTF32 in charset.h

rust-parse.c has a #define for the host-specific UTF-32 charset name.
A later patch needs the same thing, so this patch moves the definition
to charset.h for easier reuse.

Let phex and phex_nz handle sizeof_l==1

Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let
this case fall through to the default case.  However, a subsequent
patch in this series needs this case to work correctly.

I looked at all calls to these functions that pass a 1 for the
sizeof_l parameter.  The only such case seems to be correct with this
change.

Don't pre-size result string in ada_decode

Currently, ada_decode pre-sizes the output string, filling it with 'X'
characters.  However, it's a bit simpler and more flexible to let
std::string do the work here, and simply append characters to the
string as we go.  This turns out to be useful for a subsequent patch.

Simplify a regular expression in ada-lex.l

ada-lex.l uses "%option case-insensitive", so there is no need for
regular expressions to match upper case.

Automatic date update in version.in

MIPS/opcodes: Fix alias annotation for branch instructions

Correct issues with INSN2_ALIAS annotation for branch instructions:

- regular MIPS BEQZ/L and BNEZ/L assembly instructions are idioms for
  BEQ/L and BNE/L respectively with the `rs' operand equal to $0,

- microMIPS 32-bit BEQZ and BNEZ assembly instructions are idioms for
  BEQ and BNE respectively with the `rt' operand equal to $0,

- regular MIPS BAL assembly instruction is an idiom for architecture
  levels of up to the MIPSr5 ISA and a machine instruction on its own
  from the MIPSr6 ISA up.

Add missing annotation to BEQZ/L and BNEZ/L accordingly then and add a
new entry for BAL for the MIPSr6 ISA, correcting a disassembly bug:

$ mips-linux-gnu-objdump -m mips:isa64r6 -M no-aliases -d bal.o

bal.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <foo>:
   0: 04110000  0x4110000
...
$

Add test cases accordingly.

Parts for regular MIPS BEQZ/L and BNEZ/L instructions from Sagar Patel.

2022-03-06  Maciej W. Rozycki  <macro@orcam.me.uk>

binutils/
* testsuite/binutils-all/mips/mips1-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips1-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-alias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/mips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/micromips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.

2022-03-06  Sagar Patel  <sagarmp@cs.unc.edu>
    Maciej W. Rozycki  <macro@orcam.me.uk>

opcodes/
* mips-opc.c (mips_builtin_opcodes): Fix INSN2_ALIAS annotation
for "bal", "beqz", "beqzl", "bnez" and "bnezl" instructions.
* micromips-opc.c (micromips_opcodes): Likewise for "beqz" and
"bnez" instructions.

Use function view when iterating over block symbols

This changes iterate_over_block_local_vars and
iterate_over_block_arg_vars to take a gdb::function_view rather than a
function pointer and a user-data.  In one spot, this allows us to
remove a helper structure and helper function.  In another spot, this
looked more complicated, so I changed the helper function to be an
"operator()" -- also a simplification, just not as big.

Simplify hppa-tdep.c use of objfile_key

I happened to notice a couple of unnecessary casts in hppa-tdep.c, and
then I saw that the use of objfile_key could be simplified -- removing
some code and using the default deleter rather than noop_deleter.

Tested by rebuilding.  Let me know what you think.

gdb: constify parameter of value_copy

In a following patch, I have a const value I want to copy using a
value_copy.  However, value_copy takes a non-const source value, at the
moment.  Change the paramter to be const,

If the source value is not lazy, we currently call
value_contents_all_raw, which calls allocate_value_contents, to get a
view on the contents.  They both take a non-const value, that's a
problem.  My first attempt at solving it was to add a const version of
value_contents_all_raw, make allocate_value_contents take a const value,
and either:

 - make value::contents mutable
 - make allocate_value_contents cast away the const

The idea being that allocating the value contents buffer does modify the
value at the bit level, but logically that doesn't change its state.

That was getting a bit complicated, so what I ended up doing is make
value_copy not call value_contents_all_raw.  We know at this point that
the value is not lazy, so value::contents must have been allocate
already.

Change-Id: I3741ab362bce14315f712ec24064ccc17e3578d4

gdb: remove internalvar_funcs::destroy

No kind of internal var uses it remove it.  This makes the transition to
using a variant easier, since we don't need to think about where this
should be called (in a destructor or not), if it can throw, etc.

Change-Id: Iebbc867d1ce6716480450d9790410d6684cbe4dd

Automatic date update in version.in

Automatic date update in version.in

Mark vDSO as not a file

The vDSO objfile is not a real file, so mark it as such.  I noticed
this because, when playing with debuginfod, I saw:

Downloading 0.01 MB separate debug info for /tmp/system-supplied DSO at 0x7ffff7fc9000

That "/tmp" is wrong -- it's just gdb's cwd.  This patch corrects the
problem, resulting in:

Downloading 0.01 MB separate debug info for system-supplied DSO at 0x7ffff7fc9000

Regression tested on x86-64 Fedora 34.

binutils/readelf: fix indentation in process_dynamic_section

Clangd shows a warning about misleading indentation in this file, fix
it.

binutils/ChangeLog:

* readelf.c (process_dynamic_section): Fix indentation.

Change-Id: I43a7f4f4c75dd080af614222b980526f5debf297

gdb: Use a typedef's scoped type name to identify local typedefs

GDB prints the wrong type for typedefs in case there is another typedef
available for the same raw type (gdb/16040).  The reason is that the
current hashmap based substitution mechanism always compares the target
type of a typedef and not its scoped name.

The original output of GDB for a program like

~~~~
namespace ns
{
  typedef double scoped_double;
}

typedef double global_double;

class TypedefHolder
{
public:
  double a;
  ns::scoped_double b;
  global_double c;

private:
  typedef double class_double;
  class_double d;

  double method1(ns::scoped_double) { return 24.0; }
  double method2(global_double) { return 24.0; }
};

int main()
{
  TypedefHolder th;
  return 0;
}
~~~~

is
~~~~

(gdb) b 27
Breakpoint 1 at 0x1131: file TypedefHolder.cc, line 27.
(gdb) r
Starting program: /tmp/typedefholder

Breakpoint 1, main () at TypedefHolder.cc:27
27   return 0;
(gdb) ptype th
type = class TypedefHolder {
  public:
    class_double a;
    class_double b;
    class_double c;
  private:
    class_double d;

    class_double method1(class_double);
    class_double method2(class_double);

    typedef double class_double;
}
~~~~

Basically all attributes of a class which have the raw type "double" are
substituted by "class_double".

With the patch the output is the following

~~~~
type = class TypedefHolder {
  public:
    double a;
    ns::scoped_double b;
    global_double c;
  private:
    class_double d;

    double method1(ns::scoped_double);
    double method2(global_double);

    typedef double class_double;
}
~~~~

RISC-V: make .insn actually work for 64-bit insns

Presently in this case, due to an undefined behavior shift, at least
with x86 cross builds I'm observing:

Error: value conflicts with instruction length `8,0x0000003f'

Eliminate the UB and extend the respective testcase.

x86: drop redundant x86-64-code16-2 test

The code16-2 test is already meaningless enough as a gas test, identical
to this one, and is run uniformly for all ELF targets anyway.

Automatic date update in version.in

Fix typo in last change.

Avoid conflict with gnulib open/close macros.

On some systems, the gnulib configuration will decide to define open
and/or close as macros to replace the POSIX C functions.  This
interferes with using those names in C++ class or namespace scopes.

gdbsupport/
* event-pipe.cc (event_pipe::open): Renamed to ...
(event_pipe::open_pipe): ... this.
(event_pipe::close): Renamed to ...
(event_pipe::close_pipe): ... this.
* event-pipe.h (class event_pipe): Updated.
gdb/
* inf-ptrace.h (async_file_open, async_file_close): Updated.
gdbserver/
* gdbserver/linux-low.cc (linux_process_target::async): Likewise.

Adjust ld ctf test for 32-bit targets

powerpc-linux, and I suspect other 32-bit targets, report "aligned at
0x4" for this test.

* testsuite/ld-ctf/nonrepresentable.d: Accept any alignment.

Update my e-mail address in the MAINTAINERS file

Update the information accordingly.

gdb: testsuite: fix failed testcases in gdb.base/gdb-caching-proc.exp

When execute the following command:

  make check-gdb TESTS="gdb.base/gdb-caching-proc.exp"

we can see there exist some failed testcases:

  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 1: can spawn for attach (got interactive prompt)
  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 2: can spawn for attach (got interactive prompt)
  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 3: can spawn for attach (got interactive prompt)
  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 4: can spawn for attach (got interactive prompt)
  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 5: can spawn for attach (got interactive prompt)
  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 6: can spawn for attach (got interactive prompt)
  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 7: can spawn for attach (got interactive prompt)
  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 8: can spawn for attach (got interactive prompt)
  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 9: can spawn for attach (got interactive prompt)

here are the detailed messages in gdb/testsuite/gdb.log:

  attach 873776
  A program is being debugged already.  Kill it? (y or n) n
  Not killed.
  (gdb) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)

so handle the case "A program is being debugged already.  Kill it" in
can_spawn_for_attach to fix the failed testcases.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

comment typo fix

PowerPC64 DT_RELR relative reloc addresses

Section addresses can change between ppc64_elf_size_stubs and
ppc64_elf_build_stubs due to .eh_frame editing.  The idea of stashing
r_offset final addresses calculated in ppc64_elf_size_stubs for use by
ppc64_elf_build_stubs was never a good idea.  Instead, we need to keep
section/offset pairs.

* elf64-ppc.c (struct ppc_link_hash_table): Delete relr_addr.
Add relr section/offset array.
(append_relr_off): Rewrite.  Update all callers.
(sort_relr): New function.
(ppc64_elf_size_stubs): Adjust to suit new relative reloc stash.
(ppc64_elf_build_stubs): Likewise.

Automatic date update in version.in

configure: Stop checking for PT_GETXMMREGS.

This request is present on all modern *BSD/i386 systems (those
released since mid-2006), and the *BSD/i386 targets now assume it is
present unconditionally.

i386-bsd-nat: Assume PT_GETXMMREGS is present.

NetBSD has included PT_GETXMMREGS since 1.6 released in September
2002.  OpenBSD has included PT_GETXMMREGS since 3.8 released in
November 2005.

i386-fbsd-nat: Assume PT_GETXMMREGS is present.

PT_GETXMMREGS was first added in FreeBSD 6.0 released in November 2005.
The last FreeBSD release without support was 5.5 released in May 2006.

fbsd-tdep: Implement the vsyscall_range gdbarch hook.

FreeBSD recently added a real vDSO in its shared page for the amd64
architecture.  The vDSO is mapped at the address given by the
AT_KPRELOAD ELF auxiliary vector entry.  To find the end of the
mapping range, parse the list of virtual map entries used by 'info
proc mappings' either from the NT_PROCSTAT_VMMAP core dump note, or
via the kinfo_getvmmap function for native targets (fetched from the
native target as the TARGET_OBJECT_FREEBSD_VMMAP object).

This silences warnings on recent FreeBSD/amd64 kernels due to not
finding symbols for the vdso:

warning: Could not load shared library symbols for [vdso].
Do you need "set solib-search-path" or "set sysroot"?

Rewrite make-target-delegates in Python

I think gdb is probably better off having fewer languages involved
when generating code.  'sh' is unavoidable for build-time generation,
but for other things, let's use Python.

This rewrites make-target-delegates in Python.  I've stuck pretty
closely to the original code in this rewrite, so it may look slightly
weird from a Python perspective.

The only output difference is that a copyright header is now
generated, using the code introduced in the previous patch.

make-target-delegates.py is simpler to invoke, as it knows the correct
input file to scan and it creates the output file itself.

Move copyright code from gdbarch.py to new file

This moves the copyright code from gdbarch.py to a new Python source
file, gdbcopyright.py.  The function in this file will find the
copyright dates by scanning the calling script.  This will be reused
in a future patch.

This involved minor changes to the output of gdbarch.py.  Also, I've
updated copyright.py to remove the reference to gdbarch.sh.  We don't
need to mention gdbarch.py there, either.

Automatic date update in version.in

Some "distclean" fixes in gdb

PR build/12440 points out that "make distclean" is broken in gdb.
Most of the breakage comes from other projects in the tree, but we can
fix some of the issues, which is what this patch does.

Note that the yacc output files, like c-exp.c, are left alone.  In a
source distribution, these are included in the tarball, and if the
user builds in-tree, we would not want to remove them.

While that seems a bit obscure, it seems to me that "distclean" is
only really useful for in-tree builds anyway -- out-of-tree I simply
delete the entire build directory and start over.

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

Fix typo in the "alias" example

PR cli/17332, filed around 8 years ago, points out a typo in the docs
-- in one example, the command and its output are obviously out of
sync.  This patch fixes it.  I'm checking this in as obvious.

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

Fix a typo in the previous delta to bfdio.c.

PR 25713
* bfdio.c (_bfd_real_fopen): Fix typo.

Revert "Check thin archive element file size against archive header"

This reverts commit 48e3e6aec8a4f37d00ea6c0da3ab45e76490e3db.

PR 28929
* archive.c (_bfd_get_elt_at_filepos): Don't check thin archive
element file size.

Fix linker tests to compile with gcc-12.

PR 21964
* testsuite/ld-elf/pr21964-1a.c: Fix array comparisons.
* testsuite/ld-elf/pr21964-1b.c: Likewise.
* testsuite/ld-elf/pr21964-1c.c: Likewise.
* testsuite/ld-elf/pr21964-2a.c: Likewise.
* testsuite/ld-elf/pr21964-2b.c: Likewise.
* testsuite/ld-elf/pr21964-3a.c: Likewise.

Prevent an assertion from being triggered when linking an ARM object file with incorrectly set build attributes.

PR 28848
PR 28859
* elf32-arm.c (elf32_arm_merge_eabi_attributes): If the first
input bfd has a Tag_ABI_HardFP_use set to 3 but does not also have
TAG_FP_arch set then reset the TAG_ABI_HardFP_use.

gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp

If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case
gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the
following info:

  (gdb) attach 6500
  Attaching to process 6500
  ptrace: Operation not permitted.
  (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach

It is obviously wrong, the expected result should be UNSUPPORTED in such
a case.

It is better to make can_spawn_for_attach to return false for this case.
It would have to setup a small test program, compile it to exec, spawn it
and try to attach to it.

With this patch, we can see "Operation not permitted" in the log info,
and then we can do the following processes to test:
(1) set ptrace_scope as 0
    $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
    $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
(2) use sudo
    $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"

Additionally, handle the other cases when test with RUNTESTFLAGS=
"--target_board=native-extended-gdbserver".

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: testsuite: print explicit test result in can_spawn_for_attach

In the current code, there is no test result when execute the following
commands:

  $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost"
  $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=native-gdbserver"

It is better to print explicit test result in can_spawn_for_attach.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: add Tiezhu Yang as LoongArch maintainer

The patch series "gdb: Add basic support for LoongArch" has been
merged into master, list Tiezhu Yang as LoongArch maintainer.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Automatic date update in version.in

Fix "spawn id XYZ not open" errors in gdb.mi/mi-exec-run.exp

Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64}
causes several Tcl errors to appear. For example,

(gdb)
ERROR: : spawn id exp20 not open
    while executing
"expect {
-i exp11 -timeout 10
                -i "$inferior_spawn_id"
                -re ".*Cannot exec.*Permission denied" {
                    set saw_perm_error 1
                    verbose -log "saw..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp20 not open
UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof)

This is happening because of the way this test is implemented:

        while {1} {
            gdb_expect {
                -i "$inferior_spawn_id"
                -re ".*Cannot exec.*Permission denied" {
                    set saw_perm_error 1
                    verbose -log "saw mi error"
                }
                -i "$gdb_spawn_id"
                -re "\\^error,msg=\"During startup program exited with code 127" {
                    set saw_mi_error 1
                    verbose -log "saw mi error"
                }
               # and so on
            }
        }

The first time this loop is executed, `inferior_spawn_id' is valid. When the
first branch of the expect statement is reached, gdbserver has exited, closing
the spawn_id.  Since we haven't seen the gdb-side error yet, the loop is executed
again.  The first branch now refers to a non-existent spawn_id, leading to the error.

This can be fixed by using exp_continue to loop in expect instead of looping around
expect, which is the approach I have used[1].  Note I've had to update the expected
message for the "During startup..." error message when running with gdbserver.

One other small change I've made is to add a log entry which spills the values of
the two variables, saw_mi_error and saw_perm_error (and updated the log output
for the later).  This should make the log output clearer about why the test failed.

With this patch installed, all the ERRORs disappear, leaving previously masked
FAILs (which I have not attempted to fix).

[1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only
assume that it was intentionally written this way, and I've modified the code with
that assumption. I have tested a version using gdb_test_multiple, and that appears
to work fine, too, if that is preferred. [It still employs exp_continue to fix the
spawn_id errors.]

Add more filename styling

I found a few spots where filename styling ought to be applied, but is
not.

Fix maybe-uninitialized warning in py-infthread.c

I got this warning from py-infthread.c using the Fedora 34 system GCC:

../../binutils-gdb/gdb/python/py-infthread.c:102:30: warning: ‘extra_info’ may be used uninitialized in this function [-Wmaybe-uninitialized]

I think this happens because GDB_PY_HANDLE_EXCEPTION expands to an
'if' whose condition is always true -- but GCC can't know this.  This
patch avoids the warning by adding a harmless initialization.

Handle multi-byte bracket sequences in Ada lexer

As noted in an earlier patch, the Ada lexer does not handle multi-byte
bracket sequences.  This patch adds support for these for character
literals.  gdb does not generally seem to handle the Ada wide string
types, so for the time being these continue to be excluded -- but an
explicit error is added to make this more clear.

Handle 'QWW' encoding case in Ada enums

In Ada, an enum can contain character literals.  GNAT encodes these
values in a special way.  For example, the Unicode character U+0178
would be represented as 'QW0178' in the DWARF:

 <3><112f>: Abbrev Number: 2 (DW_TAG_enumerator)
    <1130>   DW_AT_name        : (indirect string, offset: 0x19ff): QW0178
    <1134>   DW_AT_const_value : 2

gdb handles this reasonably well, but failed to handle the 'QWW'
encoding, which is used for characters outside the base plane.

Also, while working on this, I noticed that gdb will print the decimal
value for an enum character constant:

    (gdb) print Char_X
    $2 = 1 'x'

This is a nice feature, IMO, because in this situation the 'x' enum
constant does not have its usual decimal value -- it has the value
that's assigned based on the enumeration type.

However, gdb did not do this when it decided to print the constant
using the bracket notation:

    (gdb) print Char_Thorn
    $3 = ["de"]

This patch changes gdb to print the decimal value here as well, and to
put the bracket notation in single quotes -- otherwise gdb will be
printing something that it can't then read.  Now it looks like:

    (gdb) print Char_Thorn
    $3 = 4 '["de"]'

Note that gdb can't read longer bracket notations, like the other ones
printed in this test case:

    (gdb) print Char_King
    $4 = 3 '["01fa00"]'

While I think this is a bug, I plan to fix it separately.

Finally, in the new test case, the copyright dates are chosen this way
because this all started as a copy of an existing test.

gdb/python: Add gdb.InferiorThread.details attribute

This adds a new read-only attribute gdb.InferiorThread.details, this
attribute contains a string, the results of target_extra_thread_info
for the thread, or None, if target_extra_thread_info returns nullptr.

As the string returned by target_extra_thread_info is unstructured,
this attribute is only really useful for echoing straight through to
the user, but, if a user wants to write a command that displays the
same, or a similar 'Thread Id' to the one seen in 'info threads', then
they need access to this string.

Given that the string produced by target_extra_thread_info varies by
target, there's only minimal testing of this attribute, I check that
the attribute can be accessed, and that the return value is either
None, or a string.

Error when gdb_is_target_1 is called without running gdb instance

This is a snafu that I encountered while implementing the previous
patch, which attempted to use gdb_is_target_native.  This proc and
gdb_is_target_remote both rely on gdb_is_target_1, which actually
cannot be called without gdb already running.

This patch adds appropriate warning comments to these procs and
causes gdb_is_target_1 to issue a Tcl error if it is called without a
gdb instance already running.  This should prevent unwitting callers
from using this at the wrong time.

Fix gdb.fortran "failed to extract expected results" errors

When running the gdb.fortran tests array-slices.exp and lbound-ubound.exp,
the test suite throws several ERRORs on native-gdbserver/-m{32,64},
and native-extended-gdbsever/-m{32,64}:

[on native-extended-gdbserver/-m64]
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/array-slices.exp ...
ERROR: failed to extract expected results
ERROR: failed to extract expected results
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/lbound-ubound.exp ...
ERROR: failed to extract expected results for lbound

This occurs because the tests require inferior I/O which we do not have
access to while using these targets.

This patch skips these tests when running on non-native targets.

Further correct the handling of long pathnames on Windows hosts.

PR 25713
* bfdio.c (_bfd_real_fopen): Fix handling of parhs longer than 260
characters on Windows hosts.

Clarify the wording of the error message when an obsolete configuration is encountered.

PR 28886
* config.bfd: Update error message for obsolete configurations.

Automatic date update in version.in

Automatic date update in version.in

Handle recursive internal problem in gdb_internal_error_resync

I came across this problem when testing gdb.base/gdb-sigterm.exp
on a machine with a pre-release version of glib-2.34 installed:

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
Resyncing due to internal error.
ERROR: : spawn id exp11 not open
    while executing
"expect {
-i exp11 -timeout 10
    -re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
    }
    -re "Create..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp11 not open
ERROR: Could not resync from internal error (timeout)
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes

I don't have a problem with the latter ERROR nor the UNRESOLVED
messages.  However the first ERROR regarding the exp11 spawn id
not being open is not especially useful.

This commit handles the "Recursive internal problem" case, avoiding
the problematic ERROR shown above.

With this commit in place, the log messages look like this instead:

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
Resyncing due to internal error.
ERROR: Could not resync from internal error (recursive internal problem)
gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes

gdb/testsuite/ChangeLog:

* lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive
internal problem".

Automatic date update in version.in

gdb-add-index: disable debuginfod

gdb-add-index may trigger debuginfod's first-use notice.  The notice
is misleading in this case.  It instructs the user to modify .gdbinit
in order to permanently enable/disable debuginfod but gdb-add-index
invokes gdb with -nx which ignores .gdbinit.

Additionally debuginfod is not needed for gdb-add-index since the
symbol file is given as an argument and should already be present
locally.

Fix this by disabling debuginfod when gdb-add-index invokes gdb.

gdb: add operator+= and operator+ overload for std::string

This commit adds operator+= and operator+ overloads for adding
gdb::unique_xmalloc_ptr<char> to a std::string.  I could only find 3
places in GDB where this was useful right now, and these all make use
of operator+=.

I've also added a self test for gdb::unique_xmalloc_ptr<char>, which
makes use of both operator+= and operator+, so they are both getting
used/tested.

There should be no user visible changes after this commit, except when
running 'maint selftest', where the new self test is visible.

Print MI prompt on interrupted command

Joel noticed that if the remote dies unexpectedly during a command --
you can simulate this by using "continue" and then killing gdbserver
-- then the CLI will print a new prompt, but MI will not.  Later, we
found out that this was also filed in bugzilla as PR mi/23820.

The output looks something like this:

    | (gdb)
    | cont
    | &"cont\n"
    | ~"Continuing.\n"
    | ^running
    | *running,thread-id="all"
    | (gdb)
    | [... some output from GDB during program startup...]
    | =thread-exited,id="1",group-id="i1"
    | =thread-group-exited,id="i1"
    | &"Remote connection closed\n"

Now, what about that "(gdb)" in the middle?

That prompt comes from this questionable code in
mi-interp.c:mi_on_resume_1:

      /* This is what gdb used to do historically -- printing prompt
 even if it cannot actually accept any input.  This will be
 surely removed for MI3, and may be removed even earlier.  */
      if (current_ui->prompt_state == PROMPT_BLOCKED)
fputs_unfiltered ("(gdb) \n", mi->raw_stdout);

... which seems like something to remove.  But maybe the intent here
is that this prompt is sufficient, and MI clients must be ready to
handle output coming after a prompt.  On the other hand, if this code
*is* removed, then nothing would print a prompt in this scenario.

Anyway, the CLI and the TUI handle emitting the prompt here by hooking
into gdb::observers::command_error, but MI doesn't install an observer
here.

This patch adds the missing observer and arranges to show the MI
prompt.  Regression tested on x86-64 Fedora 34.

It seems like this area could be improved a bit, by having
start_event_loop call the prompt-displaying code directly, rather than
indirecting through an observer.  However, I haven't done this.

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

gdb/testsuite: fix list.exp test cases

PR testsuite/7142 -- old enough to have been converted from Gnats --
points out that test_list_filename_and_function in gdb.base/list.exp
has "fails" that are unmatched with passes.  This patch cleans this up
a little.

Co-authored-by: Tom Tromey <tromey@adacore.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7142

RISC-V: Remove a loop in the ISA parser

Since commit e601909a3287bf541c6a7d82214bb387d2c76d82 ("RISC-V: Support
to parse the multi-letter prefix in the architecture string.") changed
so that all prefixed extensions are parsed in single
riscv_parse_prefixed_ext call, a "while" loop on riscv_parse_subset
is no longer required.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_parse_subset): Remove unnecessary loop.

RISC-V: Fix mask for some fcvt instructions

This commit fixes incorrect uses of mask values in 'fcvt' instruction
family.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Fix incorrect uses of mask values
in 'fcvt' instruction family.

Support template lookups in strncmp_iw_with_mode

This patch adds support for wild template parameter list matches, similar
to how ABI tags or function overloads are now handled.

With this patch, users will be able to "gloss over" the details of matching
template parameter lists.  This is accomplished by adding (yet more) logic
to strncmp_iw_with_mode to skip parameter lists if none is explicitly given
by the user.

Here's a simple example using gdb.linespec/cpls-ops.exp:

Before
------
(gdb) ptype test_op_call
type = struct test_op_call {
  public:
    void operator()(void);
    void operator()(int);
    void operator()(long);
    void operator()<int>(int *);
}
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (3 locations)
(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>
1.1                         y     0x400583 in test_op_call::operator()(int)
                                                   at cpls-ops.cc:43
1.2                         y     0x40058e in test_op_call::operator()()
                                                   at cpls-ops.cc:47
1.3                         y     0x40059e in test_op_call::operator()(long)
                                                   at cpls-ops.cc:51

The breakpoint at test_op_call::operator()<int> was never set.

After
-----
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (4 locations)
(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>
1.1                         y     0x400583 in test_op_call::operator()(int)
                                                   at cpls-ops.cc:43
1.2                         y     0x40058e in test_op_call::operator()()
                                                   at cpls-ops.cc:47
1.3                         y     0x40059e in test_op_call::operator()(long)
                                                   at cpls-ops.cc:51
1.4                         y     0x4008d0 in test_op_call::operator()<int>(int*)
                                                   at cpls-ops.cc:57

Similar to how scope lookups work, passing "-qualified" to the break command
will cause a literal lookup of the symbol.  In the example immediately above,
this will cause GDB to only find the three non-template functions.

Unit tests for strncmp_iw_with_mode

This patch attempts to make a start at adding unit tests for
strncmp_iw_with_mode.  While there is quite a bit of testing
of this function in other tests, these are currently end-to-end
tests.

This patch attempts to cover the basics of string matching, white
space, C++ ABI tags, and several other topics. However, one area
that is ostensibly missing is testing the `match_for_lcd' feature.
This is otherwise tested as part of our end-to-end DejaGNU-based
testing.

Move find_toplevel_char to cp-support.[ch]

find_toplevel_char is being used more and more outside of linespec.c, so
this patch moves it into cp-support.[ch].

Automatic date update in version.in

Fix crash in Fortran code

PR fortran/28801 points out a gdb crash that can be provoked by
certain Fortran code.  The bug is that f77_get_upperbound assumes the
property is either a constant or undefined, but in this case it is
PROP_LOCEXPR.

This patch fixes the crash by making this function (and the
lower-bound one as well) do the correct check before calling
'const_val'.

Thanks to Andrew for writing the test case.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28801

Revert "do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async."

Commit 14b3360508b1 ("do_target_wait_1: Clear
TARGET_WNOHANG if the target isn't async.") broke some multi-target
tests, such as gdb.multi/multi-target-info-inferiors.exp.  The symptom
is that execution just hangs at some point.  What happens is:

1. One remote inferior is started, and now sits stopped at a breakpoint.
   It is not "async" at this point (but it "can async").

2. We run a native inferior, the event loop gets woken up by the native
   target's fd.

3. In do_target_wait, we randomly choose an inferior to call target_wait
   on first, it happens to be the remote inferior.

4. Because the target is currently not "async", we clear
   TARGET_WNOHANG, resulting in synchronous wait.  We therefore block
   here:

  #0  0x00007fe9540dbb4d in select () from /usr/lib/libc.so.6
  #1  0x000055fc7e821da7 in gdb_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31
  #2  0x000055fc7ddef905 in interruptible_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/event-top.c:1134
  #3  0x000055fc7eda58e4 in ser_base_wait_for (scb=0x6250002e4100, timeout=1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:240
  #4  0x000055fc7eda66ba in do_ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:365
  #5  0x000055fc7eda6ff6 in generic_readchar (scb=0x6250002e4100, timeout=-1, do_readchar=0x55fc7eda663c <do_ser_base_readchar(serial*, int)>) at /home/simark/src/binutils-gdb/gdb/ser-base.c:444
  #6  0x000055fc7eda718a in ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:471
  #7  0x000055fc7edb1ecd in serial_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/serial.c:393
  #8  0x000055fc7ec48b8f in remote_target::readchar (this=0x617000038780, timeout=-1) at /home/simark/src/binutils-gdb/gdb/remote.c:9446
  #9  0x000055fc7ec4da82 in remote_target::getpkt_or_notif_sane_1 (this=0x617000038780, buf=0x6170000387a8, forever=1, expecting_notif=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:9928
  #10 0x000055fc7ec4f045 in remote_target::getpkt_or_notif_sane (this=0x617000038780, buf=0x6170000387a8, forever=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:10037
  #11 0x000055fc7ec354d4 in remote_target::wait_ns (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8147
  #12 0x000055fc7ec38aa1 in remote_target::wait (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8337
  #13 0x000055fc7f1409ce in target_wait (ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2612
  #14 0x000055fc7e19da98 in do_target_wait_1 (inf=0x617000038080, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3636
  #15 0x000055fc7e19e26b in operator() (__closure=0x7ffdb77c2f90, inf=0x617000038080) at /home/simark/src/binutils-gdb/gdb/infrun.c:3697
  #16 0x000055fc7e19f0c4 in do_target_wait (ecs=0x7ffdb77c33a0, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3716
  #17 0x000055fc7e1a31f7 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4061

Before the aforementioned commit, we would not have cleared
TARGET_WNOHANG, the remote target's wait would have returned nothing,
and we would have consumed the native target's event.

After applying this revert, the testsuite state looks as good as before
for me on Ubuntu 20.04 amd64.

Change-Id: Ic17a1642935cabcc16c25cb6899d52e12c2f5c3f

gdb: use a range based for loop when iterating over an array

Make use of a range based for loop to iterate over a static global
array, removing the need to have a null entry at the end of the
array.

There should be no user visible changes after this commit.

gdb/darwin: skip over WIFSTOPPED wait4 status

On modern Darwin's, there appears to be a new circumstance in which a
MACH_NOTIFY_DEAD_NAME message can be received, and which was not
previously accounted for: to signal the WIFSTOPPED condition in the
debuggee. In that case the debuggee is not dead yet (and in fact,
counting it as dead would cause a zombie leak - A process in such a
state reparents to PID 1, but cannot be killed).

 - Read and ignore such messages (counting on the next exception message
   to let us know of the inferior's new state again)
 - Refactor logging so as to clearly distinguish between the
   MACH_NOTIFY_DEAD_NAME cases (WIFEXITED, WIFSTOPPED, signal, or
   something else), and warn in the last case

Co-authored-by: Louis-He <1726110778@qq.com>
Co-authored-by: Philippe Blain <levraiphilippeblain@gmail.com>
Change-Id: Ie86904a894e9bd154e6b674b1bfbfbaee7fde3e1

gdb/linux-tdep: move "Perms" column right

Commit 29ef4c0699e1 ("gdb/linux-tdep.c: Add Perms to the 'info proc
mappings' output") has broken test gdb.base/info-proc.exp on Linux,
because it changes the output of "info proc mappings" in a way that the
test does not expect (my bad for not testing before pushing).

I looked at how FreeBSD handles this, since I remembered it did show
permission flags.  It looks like this:

          Start Addr           End Addr       Size     Offset   Flags   File
            0x200000           0x243000    0x43000        0x0  r-- CN-- /usr/local/bin/tmux

(I think that `Flags` and the flags not being aligned is not
intentional)

The test passes on FreeBSD, because the test looks for four hex numbers
in a row and ignores the rest:

    ".*Mapped address spaces:.*${hex}${ws}${hex}${ws}${hex}${ws}${hex}.*"

I suggest fixing it on Linux by moving the flags column to the same
place as in the FreeBSD output.  It makes things a bit more consistent
between OSes, and we don't have to touch the test.

At the same time, make use of the actual length of the permission's
string to specify the number of characters to print.

Before this patch, the output looks like:

          Start Addr           End Addr   Perms       Size     Offset objfile
      0x55dd4b544000     0x55dd4b546000   r--p      0x2000        0x0 /usr/bin/sleep

and after, it looks like:

          Start Addr           End Addr       Size     Offset  Perms  objfile
      0x5622ae662000     0x5622ae664000     0x2000        0x0  r--p   /usr/bin/sleep

Change-Id: If0fc167b010b25f97a3c54e2f491df4973ccde8f

gdb/linux-tdep: make read_mapping return a structure

Change read_mapping to return a structure instead of taking many output
parameters.  Change the string + length output parameters (permissions
and device) to be gdb::string_view, since that's what string_view is
for (a non-NULL terminated view on a string).  No changes in behavior
expected.

Change-Id: I86e627d84d3dda8c9b835592b0f4de8d90d12112

Automatic date update in version.in

Fix bug in C++ overload resolution

PR c++/28901 points out a bug in C++ overload resolution.  When
comparing two overloads, one might be better than the other for
certain parameters -- but, if that one also has some invalid
conversion, then it should never be considered the better choice.
Instead, a valid-but-not-apparently-quite-as-good overload should be
preferred.

This patch fixes this problem by changing how overload comparisons are
done.  I don't believe it should affect any currently valid overload
resolution; nor should it affect resolutions where all the choices are
equally invalid.

gdb/linux-tdep.c: Add Perms to the 'info proc mappings' output

Fixes #28914 and so it adds a 'Perms' (permissions) column to the
'info proc mappings' command output. This will allow users to know
the memory pages permissions right away from GDB instead of having
to fetch them from the /proc/$pid/maps file (which is also what GDB
does internally, but it just did not print that column).

Below I am also showing how an example output looks like before and
after this commit in case someone wonders.

On i386 targets - before this commit:
```
(gdb) info proc mappings
process 3461464
Mapped address spaces:

    Start Addr   End Addr        Size     Offset objfile
    0x56555000 0x56556000      0x1000        0x0 /home/dc/src/binutils-gdb/build/a.out
    0x56556000 0x56557000      0x1000     0x1000 /home/dc/src/binutils-gdb/build/a.out
    0x56557000 0x56558000      0x1000     0x2000 /home/dc/src/binutils-gdb/build/a.out
    0x56558000 0x5655a000      0x2000     0x2000 /home/dc/src/binutils-gdb/build/a.out
    0xf7fc4000 0xf7fc8000      0x4000        0x0 [vvar]
    0xf7fc8000 0xf7fca000      0x2000        0x0 [vdso]
    0xf7fca000 0xf7fcb000      0x1000        0x0 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7fcb000 0xf7fee000     0x23000     0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7fee000 0xf7ffb000      0xd000    0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7ffb000 0xf7ffe000      0x3000    0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xfffdc000 0xffffe000     0x22000        0x0 [stack]
(gdb)
```

On i386 targets - after this commit:
```
(gdb) info proc mappings
process 3461464
Mapped address spaces:

    Start Addr   End Addr   Perms       Size     Offset objfile
    0x56555000 0x56556000   r--p      0x1000        0x0 /home/dc/src/binutils-gdb/build/a.out
    0x56556000 0x56557000   r-xp      0x1000     0x1000 /home/dc/src/binutils-gdb/build/a.out
    0x56557000 0x56558000   r--p      0x1000     0x2000 /home/dc/src/binutils-gdb/build/a.out
    0x56558000 0x5655a000   rw-p      0x2000     0x2000 /home/dc/src/binutils-gdb/build/a.out
    0xf7fc4000 0xf7fc8000   r--p      0x4000        0x0 [vvar]
    0xf7fc8000 0xf7fca000   r-xp      0x2000        0x0 [vdso]
    0xf7fca000 0xf7fcb000   r--p      0x1000        0x0 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7fcb000 0xf7fee000   r-xp     0x23000     0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7fee000 0xf7ffb000   r--p      0xd000    0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7ffb000 0xf7ffe000   rw-p      0x3000    0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xfffdc000 0xffffe000   rw-p     0x22000        0x0 [stack]
(gdb)
```

On amd64 targets - after this commit:
```
(gdb) info proc mappings
process 3461869
Mapped address spaces:

          Start Addr           End Addr   Perms       Size     Offset objfile
      0x555555554000     0x555555555000   r--p      0x1000        0x0 /home/dc/src/binutils-gdb/build/a.out
      0x555555555000     0x555555556000   r-xp      0x1000     0x1000 /home/dc/src/binutils-gdb/build/a.out
      0x555555556000     0x555555557000   r--p      0x1000     0x2000 /home/dc/src/binutils-gdb/build/a.out
      0x555555557000     0x555555559000   rw-p      0x2000     0x2000 /home/dc/src/binutils-gdb/build/a.out
      0x7ffff7fc3000     0x7ffff7fc7000   r--p      0x4000        0x0 [vvar]
      0x7ffff7fc7000     0x7ffff7fc9000   r-xp      0x2000        0x0 [vdso]
      0x7ffff7fc9000     0x7ffff7fca000   r--p      0x1000        0x0 /usr/lib/x86_64-linux-gnu/ld-2.33.so
      0x7ffff7fca000     0x7ffff7ff1000   r-xp     0x27000     0x1000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
      0x7ffff7ff1000     0x7ffff7ffb000   r--p      0xa000    0x28000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
      0x7ffff7ffb000     0x7ffff7fff000   rw-p      0x4000    0x31000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
      0x7ffffffdd000     0x7ffffffff000   rw-p     0x22000        0x0 [stack]
  0xffffffffff600000 0xffffffffff601000   --xp      0x1000        0x0 [vsyscall]
(gdb)
```

Signed-off-by: Dominik 'Disconnect3d' Czarnota <dominik.b.czarnota@gmail.com>
Change-Id: I4991f6cc758cd532eae3ae98c29d22e7bd9d9c36

RISC-V: PR28733, add missing extension info to 'unrecognized opcode' error

Currently we report errors as "unrecognized opcode `fence.i'" when the
opcode isn't part of the selected extensions.
This patch expands that error message to include the missing extension
information. For example, now the error message would be "unrecognized
opcode `fence.i', extension `zifencei' required".
If the opcode is not a part of any extension, the error message reverts
to "unrecognized opcode `<op statement>'".

Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
bfd/
pr 28733
* elfxx-riscv.c (riscv_multi_subset_supports_ext): New function,
used to return the extension string for each INSN_CLASS_*.
* elfxx-riscv.h: Added extern riscv_multi_subset_supports_ext.
gas/
pr 28733
* config/tc-riscv.c (struct riscv_ip_error): New structure,
contains information about errors that occur within the riscv_ip.
(riscv_ip): Use struct riscv_ip_error to report more detailed errors.
* testsuite/gas/riscv/c-fld-fsd-fail.l: Updated.
* testsuite/gas/riscv/march-imply-i2p1-01.: Likewise.

RISC-V: PR28733, add missing extension info to 'invalid CSR' error

Currently we report errors as "invalid CSR 'fscr' for the current ISA"
when the instruction isn't valid.

This patch expands that error message to include the missing extension
information. For example, now the error message would be "invalid CSR
'fscr' for the current ISA, CSR 'fscr' needs 'f' extension".

Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
gas/
pr 28733
* config/tc-riscv.c (riscv_csr_address): Report more details
when the CSR is invalid.
* testsuite/gas/riscv/csr-version-1p10.l: Updated detailed errors.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.

binutils 2.38 vs. ppc32 linux kernel

Commit b25f942e18d6 made .machine more strict.  Weaken it again.

* config/tc-ppc.c (ppc_machine): Treat an early .machine specially,
keeping sticky options to work around gcc bugs.

RISC-V: Updated CSRs to privileged spec v1.12 and debug spec v1.0.

* Removed N extension CSRs,
ustatus, uie, utvec, uscratch, uepc, ucause, utval and uip.

* Removed two supervisor CSRs,
sedeleg and sideleg.

* Changed debug CSR address of scontext from 0x7aa to 0x5a8.  We cannot support
different versions of debug specs for now, so only supporting the latest one is
the only way to move forward.

* Added debug CSRs,
mscontext (0x7aa), mcontrol6 (0x7a1, tdata1) and tmexttrigger ((0x7a1, tdata1).

* Regarded hcontext as a debug CSR.

include/
* opcode/riscv-opc.h: Updated CSRs to privileged spec v1.12 and
debug spec v1.0.
gas/
* testsuite/gas/riscv/csr.s: Updated CSRs to privileged spec v1.12
and debug spec v1.0.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.

RISC-V: Add Privileged Architecture 1.12 CSRs

This commit adds,

* Most of CSRs as listed in the Privileged Architecture,
version 1.12 (except scontext and mscontext).

* Testcases for most CSRs added on the Privileged
Architecture, version 1.12 (except moved "scontext" and
new "mscontext").

include/ChangeLog:

* opcode/riscv-opc.h (CSR_SENVCFG, CSR_MCONFIGPTR, CSR_MENVCFG,
CSR_MSTATUSH, CSR_MENVCFGH, CSR_MTINST, CSR_MTVAL2, CSR_MSECCFG,
CSR_MSECCFGH, CSR_PMPCFG4, CSR_PMPCFG5, CSR_PMPCFG6,
CSR_PMPCFG7, CSR_PMPCFG8, CSR_PMPCFG9, CSR_PMPCFG10,
CSR_PMPCFG11, CSR_PMPCFG12, CSR_PMPCFG13, CSR_PMPCFG14,
CSR_PMPCFG15, CSR_PMPADDR16, CSR_PMPADDR17, CSR_PMPADDR18,
CSR_PMPADDR19, CSR_PMPADDR20, CSR_PMPADDR21, CSR_PMPADDR22,
CSR_PMPADDR23, CSR_PMPADDR24, CSR_PMPADDR25, CSR_PMPADDR26,
CSR_PMPADDR27, CSR_PMPADDR28, CSR_PMPADDR29, CSR_PMPADDR30,
CSR_PMPADDR31, CSR_PMPADDR32, CSR_PMPADDR33, CSR_PMPADDR34,
CSR_PMPADDR35, CSR_PMPADDR36, CSR_PMPADDR37, CSR_PMPADDR38,
CSR_PMPADDR39, CSR_PMPADDR40, CSR_PMPADDR41, CSR_PMPADDR42,
CSR_PMPADDR43, CSR_PMPADDR44, CSR_PMPADDR45, CSR_PMPADDR46,
CSR_PMPADDR47, CSR_PMPADDR48, CSR_PMPADDR49, CSR_PMPADDR50,
CSR_PMPADDR51, CSR_PMPADDR52, CSR_PMPADDR53, CSR_PMPADDR54,
CSR_PMPADDR55, CSR_PMPADDR56, CSR_PMPADDR57, CSR_PMPADDR58,
CSR_PMPADDR59, CSR_PMPADDR60, CSR_PMPADDR61, CSR_PMPADDR62,
CSR_PMPADDR63): New CSR macros.

gas/ChangeLog:

* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr.s: Add new CSRs.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.

RISC-V: Reorganize testcases for CFI directives

This commit reorganizes and adds some CSRs to csr-dw-regnums.[sd] to
make it test the same CSRs as csr.s.

gas/ChangeLog:

* testsuite/gas/riscv/csr-dw-regnums.s: Reorganize and add
defined CSRs tested in csr.s.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.

Automatic date update in version.in