libctf: add ctf_member_count

This returns the number of members in a struct or union, or the number
of enumerations in an enum.  (This was only available before now by
iterating across every member, but it can be returned much faster than
that.)

include/
* ctf-api.h (ctf_member_count): New.

libctf/
* ctf-types.c (ctf_member_count): New.
* libctf.ver: New public function.

libctf: add ctf_type_kind_forwarded

This is just like ctf_type_kind, except that forwards get the
type of the thing being pointed to rather than CTF_K_FORWARD.

include/
* ctf-api.h (ctf_type_kind_forwarded): New.
libctf/
* ctf-types.c (ctf_type_kind_forwarded): New.

libctf: add ctf_type_name_raw

We already have a function ctf_type_aname_raw, which returns the raw
name of a type with no decoration for structures or arrays or anything
like that: just the underlying name of whatever it is that's being
ultimately pointed at.

But this can be inconvenient to use, becauswe it always allocates new
storage for the string and copies it in, so it can potentially fail.
Add ctf_type_name_raw, which just returns the string directly out of
libctf's guts: it will live until the ctf_file_t is closed (if we later
gain the ability to remove types from writable dicts, it will live as
long as the type lives).

Reimplement ctf_type_aname_raw in terms of it.

include/
* ctf-api.c (ctf_type_name_raw): New.

libctf/
* ctf-types.c (ctf_type_name_raw): New.
(ctf_type_aname_raw): Reimplement accordingly.

libctf: having debugging enabled is unlikely

The deduplicator can emit enormous amounts of debugging output,
so much so that a later commit will introduce a new configure flag
that configures most of it out (and configures it out by default).

It became clear that when this configure flag is on, but debugging is
not enabled via the LIBCTF_DEBUG environment variable, up to 10% of
runtime can be spent on branch mispredictions checking the _libctf_debug
variable.  Mark it unlikely to be set (when it is set, performance is
likely to be the least of your concerns).

libctf/
* ctf-subr.c (ctf_dprintf): _libctf_debug is unlikely to be set.

libctf, archive: stop ctf_arc_bufopen triggering crazy unmaps

The archive machinery mmap()s its archives when possible: so it arranges
to do appropriately-sized unmaps by recording the unmap length in the
ctfa_magic value and unmapping that.

This brilliant (horrible) trick works less well when ctf_arc_bufopen is
called with an existing buffer (which might be a readonly mapping).
ctf_arc_bufopen always returns a ctf_archive_t wrapper, so record in
there the necessity to not unmap anything when a bufopen'ed archive is
closed again.

libctf/
* ctf-impl.h (struct ctf_archive_internal)
<ctfi_unmap_on_close>: New.
(ctf_new_archive_internal): Adjust.
* ctf-archive.c (ctf_new_archive_internal): Likewise.
Initialize ctfi_unmap_on_close.  Adjust error path.
(ctf_arc_bufopen): Adjust ctf_new_archive_internal call
(unmap_on_close is 0).
(ctf_arc_close): Only unmap if ctfi_unmap_on_close.
* ctf-open-bfd.c (ctf_fdopen): Adjust.

libctf, types: ints, floats and typedefs with no name are invalid

Report them as such, rather than letting ctf_decl_sprintf wrongly
conclude that the printing of zero characters means we are out of
memory.

libctf/
* ctf-types.c (ctf_type_aname): Return ECTF_CORRUPT if
ints, floats or typedefs have no name.  Fix comment typo.

libctf, types: support slices of anything terminating in an int

It is perfectly valid C to say e.g.

typedef u64 int;
struct foo_t
  {
    const volatile u64 wibble:2;
  };

i.e. bitfields have to be integral types, but they can be cv-qualified
integral types or typedefs of same, etc.

This is easy to fix: do a ctf_type_resolve_unsliced() at creation time
to ensure the ultimate type is integral, and ctf_type_resolve() at
lookup time so that if you somehow have e.g. a slice of a typedef of a
slice of a cv-qualified int, we pull the encoding that the topmost slice
is based on out of the subsidiary slice (and then modify it), not out of
the underlying int.  (This last bit is rather academic right now, since
all slices override exactly the same properties of the underlying type,
but it's still the right thing to do.)

libctf/
* ctf-create.c (ctf_add_slice): Support slices of any kind that
resolves to an integral type.
* ctf-types.c (ctf_type_encoding): Resolve the type before
fishing its encoding out.

libctf, create: empty dicts are dirty to start with

Without this, an empty dict that is written out immediately never gets
any content at all: even the header is left empty.

libctf/
* ctf-create.c (ctf_create): Mark dirty.

libctf, create: fix addition of anonymous struct/union members

A Solaris-era bug causes us to check the offsets of types with no names
against the first such type when ctf_add_type()ing members to a struct
or union.  Members with no names (i.e. anonymous struct/union members)
can appear as many times as you like in a struct/union, so this check
should be skipped in this case.

libctf/
* ctf-create.c (membcmp)  Skip nameless members.

libctf, create: member names of "" and NULL should be the same

This matters for the case of unnamed bitfields, whose names are the null
string.  These are special in that they are the only members whose
"names" are allowed to be duplicated in a single struct, but we were
only handling this for the case where name == NULL.  Translate "" to
NULL to help callers.

libctf/
* ctf-create.c (ctf_add_member_offset): Support names of ""
as if they were the null pointer.

libctf, open: drop unnecessary historical wart around forwards

When opening, we consider a forward with a kind above the maximum
allowable set of kinds and a forward of kind CTF_K_UNKNOWN to be a
forward to a struct.  Whatever CTF version it was that produced
forwards with no associated kind, it predates anything we can read:
remove this wart.

libctf/
* ctf-open.c (init_types): Remove typeless CTF_K_FORWARD
special-casing.

libctf, types: allow ctf_type_reference of dynamic slices

One spot was missed when we rejigged ctf_update into ctf_serialize and
allowed all operations on dynamic containers: ctf_type_reference of
slices.  A dynamic slice's vlen state is stored in the dtu_slice member,
so fetch it from there.

libctf/
* ctf-types.c (ctf_type_reference): Add support for dynamic slices.

libctf, create: add explicit casts for variables' and slices' types

This is technically unnecessary -- the compiler is quite capable of
doing the range reduction for us -- but it does mean that all
assignments of a ctf_id_t to its final uint32_t representation now have
appropriate explicit casts.

libctf/
* ctf-create.c (ctf_serialize): Add cast.
(ctf_add_slice): Likewise.

libctf, create: do not corrupt function types' arglists at insertion time

ctf_add_function assumes that function types' arglists are of type
ctf_id_t.  Since they are CTF IDs, they are 32 bits wide, a uint32_t:
unfortunately ctf_id_t is a forward-compatible user-facing 64 bits wide,
and should never ever reach the CTF storage level.

All the CTF code other than ctf_add_function correctly assumes that
function arglists outside dynamic containers are 32 bits wide, so the
serialization machinery ends up cutting off half the arglist, corrupting
all args but the first (a good sign is a bunch of args of ID 0, the
unimplemented type, popping up).

Fix this by copying the arglist into place item by item, casting it
properly, at the same time as we validate the arg types.  Fix the type
of the dtu_argv in the dynamic container and drop the now-unnecessary
cast in the serializer.

libctf/
* ctf-impl.h (ctf_dtdef_t) <dtu_argv>: Fix type.
* ctf-create.c (ctf_add_function): Check for unimplemented type
and populate at the same time.  Populate one-by-one, not via
memcpy.
(ctf_serialize): Remove unnecessary cast.
* ctf-types.c (ctf_func_type_info): Likewise.
(ctf_func_type_args): Likewise.  Fix comment typo.

libctf, create: support addition of references to the unimplemented type

The deduplicating linker adds types from the linker inputs to the output
via the same API everyone else does, so it's important that we can emit
everything that the compiler wants us to.  Unfortunately, the compiler
may represent the unimplemented type (used for compiler constructs that
CTF cannot currently encode) as type zero or as a type of kind
CTF_K_UNKNOWN, and we don't allow the addition of types that cite the
former.

Adding this support adds a tiny bit of extra complexity: additions of
structure members immediately following a member of the unimplemented
type must be via ctf_add_member_offset or ctf_add_member_encoded, since
we have no idea how big members of the unimplemented type are.
(Attempts to do otherwise return -ECTF_NONREPRESENTABLE, like other
attempts to do forbidden things with the unimplemented type.)

Even slices of the unimplemented type are permitted: this is the only
case in which you can slice a type that terminates in a non-integral
type, on the grounds that it was likely integral in the source code,
it's just that we can't represent that sort of integral type properly
yet.

libctf/
* ctf-create.c (ctf_add_reftype): Support refs to type zero.
(ctf_add_array): Support array contents of type zero.
(ctf_add_function): Support arguments and return types of
type zero.
(ctf_add_typedef): Support typedefs to type zero.
(ctf_add_member_offset): Support members of type zero,
unless added at unspecified (naturally-aligned) offset.

libctf: restructure error handling to reduce relocations

Jose Marchesi noted that the traditional-Unix error array in ctf-error.c
introduces one reloc per error to initialize the array: 58 so far.  We
can reduce this to zero using an array of carefully-sized individual
members which is used to construct a string table, that is then
referenced by the lookup functions: but doing this automatically is a
pain.

Bruno Haible wrote suitable code years ago: I got permission to reuse it
(Bruno says "... which I hereby put in the public domain"); I modified
it a tiny bit (similarly to what Ulrich Drepper did in the dsohowto
text, but I redid it from scratch), commented it up a bit, and shifted
the error table into that form, migrating it into the new file
ctf-error.h.

This has the advantage that it spotted both typos in the text of the
errors in the comments in ctf-api.h and typos in the error defines in
the comments in ctf-error.c, and places where the two were simply not
in sync.  All are now fixed.

One new constant exists in ctf-api.h: CTF_NERR, since the old method of
working out the number of errors in ctf-error.c was no longer usable,
and it seems that the number of CTF errors is something users might
reasonably want as well.  It should be pretty easy to keep up to date as
new errors are introduced.

include/
* ctf-api.h (ECTF_*): Improve comments.
(ECTF_NERR): New.

libctf/
* ctf-error.c: Include <stddef.h>, for offsetof.
(_ctf_errlist): Migrate to...
(_ctf_errlist_t): ... this.
(_ctf_erridx): New, indexes into _ctf_errlist_t.
(_ctf_nerr): Remove.
(ctf_errmsg): Adjust accordingly.
* Makefile.am (BUILT_SOURCES): Note...
(ctf-error.h): ... this new rule.
* Makefile.in: Regenerate.
* mkerrors.sed: New, process ctf-api.h to generate ctf-error.h.
* .gitignore: New, ignore ctf-error.h.

include, libctf: typo fixes

include/
* ctf-api.h: Fix typos in comments.
libctf/
* ctf-impl.h: Fix typos in comments.

Correct an error in the remote protocol specification

The list of commands that a stub must implement was wrong.

gdb/ChangeLog:
2020-07-22  Reuben Thomas  <rrt@sc3d.org>

* gdb.texinfo (Remote Protocol, Overview): Correct the description
of which remote protocol commands are mandatory for a stub to
implement.

gdb/python: Use reference not pointer in py-registers.c

Pedro's review comments arrived after I'd already committed this
change:

  commit f7306dac19c502232f766c3881313857915f330d
  Date:   Tue Jul 7 15:00:30 2020 +0100

      gdb/python: Reuse gdb.RegisterDescriptor objects where possible

See:

  https://sourceware.org/pipermail/gdb-patches/2020-July/170726.html

There should be no user visible changes after this commit.

gdb/ChangeLog:

* python/py-registers.c (gdbpy_register_object_data_init): Remove
redundant local variable.
(gdbpy_get_register_descriptor): Extract descriptor vector as a
reference, not pointer, update code accordingly.

Fix problems in CTF handling code exposed by the Coverity static analysis tool.

readelf * readelf.c (parse_args): Silence potential warnings about a
memory resource leak when allocating space for ctf option values.
(dump_section_as_ctf): Fix typo checking dump_ctf_strtab_name
variable.

libctf * ctf-archive.c (ctf_arc_write): Avoid calling close twice on the
same file descriptor.

gdb/jit: skip jit symbol lookup if already detected the symbols don't exist

To detect whether an objfile is a JITer, we lookup JIT interface
symbols in the objfile.  If an objfile does not have these symbols, we
conclude that it is not a JITer.  An objfile that does not have the
symbols will never have them.  Therefore, once we do a lookup and find
out that the objfile does not have JIT symbols, just set a flag so
that we can skip symbol lookup for that objfile the next time we reset
JIT breakpoints.

gdb/ChangeLog:
2020-07-22  Simon Marchi  <simon.marchi@polymtl.ca>
    Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* objfiles.h (struct objfile) <skip_jit_symbol_lookup>: New field.
* jit.c (jit_breakpoint_re_set_internal): Use the
`skip_jit_symbol_lookup` field.

gdb/jit: apply minor cleanup and modernization

gdb/ChangeLog:
2020-07-22  Simon Marchi  <simon.marchi@polymtl.ca>
    Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* jit.c (jit_read_descriptor): Define the descriptor address once,
use twice.
(jit_breakpoint_deleted): Move the declaration of the loop variable
`iter` into the loop header.
(jit_breakpoint_re_set_internal): Move the declaration of the local
variable `objf_data` to the first point of definition.
(jit_event_handler): Move the declaration of local variables
`code_entry`, `entry_addr`, and `objf` to their first point of use.
Rename `objf` to `jited`.

gdb/jit: remove jiter_objfile_data -> objfile back-link

This is no longer needed, remove it.

gdb/ChangeLog:
2020-07-22  Simon Marchi  <simon.marchi@polymtl.ca>

* jit.h (struct jiter_objfile_data) <jiter_objfile_data, objfile>:
Remove.
* jit.c (get_jiter_objfile_data): Update.

gdb/jit: enable tracking multiple JITer objfiles

GDB's JIT handler stores an objfile (and data associated with it) per
program space to keep track of JIT breakpoint information.  This assumes
that there is at most one JITer objfile in the program space.  However,
there may be multiple.  If so, only the first JITer's hook breakpoints
would be realized and the JIT events from the other JITers would be
missed.

This patch removes that assumption, allowing an arbitrary number of
objfiles within a program space to be JITers.

- The "unique" program_space -> JITer objfile pointer in
  jit_program_space_data is removed.  In fact, jit_program_space_data
  becomes empty, so it is removed entirely.

- jit_breakpoint_deleted is modified, it now has to assume that any
  objfile in a program space is a potential JITer.  It now iterates on
  all objfiles, checking if they are indeed JITers, and if they are,
  whether the deleted breakpoint belongs to them.

- jit_breakpoint_re_set_internal also has to assume that any objfile in
  a program space is a potential JITer.  It creates (or updates) one
  jiter_objfile_data structure for each JITer it finds.

- Same for jit_inferior_init.  It now iterates all objfiles to read the
  initial JIT object list.

gdb/ChangeLog:
2020-07-22  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
    Simon Marchi  <simon.marchi@polymtl.ca>

* jit.c (struct jit_program_space_data): Remove.
(jit_program_space_key): Remove.
(jiter_objfile_data::~jiter_objfile_data): Remove program space
stuff.
(get_jit_program_space_data): Remove.
(jit_breakpoint_deleted): Iterate on all of the program space's
objfiles.
(jit_inferior_init): Likewise.
(jit_breakpoint_re_set_internal): Likewise.  Also change return
type to void.
(jit_breakpoint_re_set): Pass current_program_space to
jit_breakpoint_re_set_internal.

gdb/testsuite/ChangeLog:
2020-07-22  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* gdb.base/jit-reader-simple.exp: Add a scenario for a binary that
loads two JITers.

gdb/jit: move cached_code_address and jit_breakpoint to jiter_objfile_data

This is in preparation for allowing more than one JITer objfile per
program space.  Once we do that, each JITer objfile will have its own
JIT breakpoint (on the __jit_debug_register_code function it provides).
The cached_code_address field is just the runtime / relocated address of
that symbol.

Since they are going to become JITer-objfile-specific and not
program-space-specific, move these fields from jit_program_space_data to
jiter_objfile_data.

gdb/ChangeLog:
2020-07-22  Simon Marchi  <simon.marchi@polymtl.ca>

* jit.h (struct jiter_objfile_data) <cached_code_address,
jit_breakpoint>: Move to here from ...
* jit.c (jit_program_space_data): ... here.
(jiter_objfile_data::~jiter_objfile_data): Update.
(jit_breakpoint_deleted): Update.
(jit_breakpoint_re_set_internal): Update.

gdb/jit: apply some simplifications and assertions

Following patch "gdb/jit: split jit_objfile_data in two", there are some
simplifications we can make.  The invariants described there mean that
we can assume / assert some things instead of checking them using
conditionals.

If an instance of jiter_objfile_data exists for a given objfile, it's
because the required JIT interface symbols were found.  Therefore, in
~jiter_objfile_data, the `register_code` field can't be NULL.  It was
previously used to differentiate a jit_objfile_data object used for a
JITer vs a JITed.  We can remove that check.

If an instance of jiter_objfile_data exists for a given objfile, it's
because it's the sole JITer objfile in the scope of its program space
(jit_program_space_data::objfile points to it).  At the moment,
jit_breakpoint_re_set_internal won't create a second instance of
jiter_objfile_data for a given program space.  Therefore, it's not
necessary to check for `ps_data != NULL` in ~jiter_objfile_data: we know
a jit_program_space_data for that program space exists.  We also don't
need to check for `ps_data->objfile == this->objfile`, because we know
the objfile is the sole JITer in this program space.  Replace these two
conditions with assertions.

A pre-condition for calling the jit_read_descriptor function (which is
respected in the two call sites) is that the objfile `jiter` _is_ a
JITer - it already has a jiter_objfile_data attached to it.  When a
jiter_objfile_data exists, its `descriptor` field is necessarily set:
had the descriptor symbol not been found, jit_breakpoint_re_set_internal
would not have created the jiter_objfile_data.  Remove the check and
early return in jit_read_descriptor.  Access objfile's `jiter_data` field
directly instead of calling `get_jiter_objfile_data` (which creates the
jiter_objfile_data if it doesn't exist yet) and assert that the result
is not nullptr.

Finally, `jit_event_handler` is always passed a JITer objfile.  So, add
an assertion to ensure that.

gdb/ChangeLog:
2020-07-22  Simon Marchi  <simon.marchi@polymtl.ca>

* jit.c (jiter_objfile_data::~jiter_objfile_data): Remove some
checks.
(jit_read_descriptor): Remove NULL check.
(jit_event_handler): Add an assertion.

gdb/jit: split jit_objfile_data in two

The jit_objfile_data is currently used to hold information about both
objfiles that are the result of JIT compilation (JITed) and objfiles
that can produce JITed objfiles (JITers).  I think that this double use
of the type is confusing, and that things would be more obvious if we
had one type for each role.

This patch splits it into:

- jited_objfile_data: for data about an objfile that is the result of a
  JIT compilation
- jiter_objfile_data: for data about an objfile which produces JITed
  objfiles

There are now two JIT-related fields in an objfile, one for each kind.
With this change, the following invariants hold:

- an objfile has a non-null `jiter_data` field iff it defines the required
  symbols of the JIT interface
- an objfile has a non-null `jited_data` field iff it is the product of
  JIT compilation (has been produced by some JITer)

gdb/ChangeLog:
2020-07-22  Simon Marchi  <simon.marchi@polymtl.ca>

* jit.h (struct jit_objfile_data):  Split into...
(struct jiter_objfile_data): ... this ...
(struct jited_objfile_data): ... and this.
* objfiles.h (struct objfile) <jit_data>: Remove.
<jiter_data, jited_data>: New fields.
* jit.c (jit_objfile_data::~jit_objfile_data): Rename to ...
(jiter_objfile_data::~jiter_objfile_data): ... this.
(get_jit_objfile_data): Rename to ...
(get_jiter_objfile_data): ... this.
(add_objfile_entry): Update.
(jit_read_descriptor): Use get_jiter_objfile_data.
(jit_find_objf_with_entry_addr): Use objfile's jited_data field.
(jit_breakpoint_re_set_internal): Use get_jiter_objfile_data.
(jit_inferior_exit_hook): Use objfile's jited_data field.

gdb/jit: link to jit_objfile_data directly from the objfile struct

Remove the use of objfile_data to associate a jit_objfile_data with an
objfile.  Instead, directly link to a jit_objfile_data from an objfile
struct.  The goal is to eliminate unnecessary abstraction.

The free_objfile_data function naturally becomes the destructor of
jit_objfile_data.  However, free_objfile_data accesses the objfile to
which the data is attached, which the destructor of jit_objfile_data
doesn't have access to.  To work around this, add a backlink to the
owning objfile in jit_objfile_data.  This is however temporary, it goes
away in a subsequent patch.

gdb/ChangeLog:
2020-07-22  Simon Marchi  <simon.marchi@polymtl.ca>

* jit.h: Forward-declare `struct minimal_symbol`.
(struct jit_objfile_data): Migrate to here from jit.c; also add a
constructor, destructor, and an objfile* field.
* jit.c (jit_objfile_data): Remove.
(struct jit_objfile_data): Migrate from here to jit.h.
(jit_objfile_data::~jit_objfile_data): New destructor
implementation with code moved from free_objfile_data.
(free_objfile_data): Delete.
(get_jit_objfile_data): Update to use the jit_data field of objfile.
(jit_find_objf_with_entry_addr): Ditto.
(jit_inferior_exit_hook): Ditto.
(_initialize_jit): Remove the call to
register_objfile_data_with_cleanup.
* objfiles.h (struct objfile) <jit_data>: New field.

gdb/jit: pass the jiter objfile as an argument to jit_event_handler

This is a refactoring that adds a new parameter to the `jit_event_handler`
function: the JITer objfile.  The goal is to distinguish which JITer
triggered the JIT event, in case there are multiple JITers -- a capability
that is added in a subsequent patch.

gdb/ChangeLog:
2020-07-22  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* jit.h: Forward-declare `struct objfile`.
(jit_event_handler): Add a second parameter, the JITer objfile.
* jit.c (jit_read_descriptor): Change the signature to take the
JITer objfile as an argument instead of the jit_program_space_data.
(jit_inferior_init): Update the call to jit_read_descriptor.
(jit_event_handler): Use the new JITer objfile argument when calling
jit_read_descriptor.
* breakpoint.c (handle_jit_event): Update the call to
jit_event_handler to pass the JITer objfile.

MIPS/GAS/testsuite: Fix JALR relocation tests for IRIX targets

With IRIX targets the JALR hint relocation is not produced for the o32
ABI, where it is considered a GNU extension.  Consequently several tests
fail as the output produced by GAS fails to match patterns expecting the
relocation to be present where appropriate, even though output produced
is indeed correct.

As the absence of the relocation is expected, fix the tests by providing
respective alternative dump patterns with any JALR relocations removed,
removing numerous failures with `*-*-irix*' targets:

FAIL: MIPS jal-svr4pic (interaptiv-mr2)
FAIL: MIPS jal-svr4pic (micromips)
FAIL: MIPS jal-svr4pic (mips1)
FAIL: MIPS jal-svr4pic (mips2)
FAIL: MIPS jal-svr4pic (mips3)
FAIL: MIPS jal-svr4pic (mips4)
FAIL: MIPS jal-svr4pic (mips5)
FAIL: MIPS jal-svr4pic (mips32)
FAIL: MIPS jal-svr4pic (mips32r2)
FAIL: MIPS jal-svr4pic (mips32r3)
FAIL: MIPS jal-svr4pic (mips32r5)
FAIL: MIPS jal-svr4pic (mips32r6)
FAIL: MIPS jal-svr4pic (mips64)
FAIL: MIPS jal-svr4pic (mips64r2)
FAIL: MIPS jal-svr4pic (mips64r3)
FAIL: MIPS jal-svr4pic (mips64r5)
FAIL: MIPS jal-svr4pic (mips64r6)
FAIL: MIPS jal-svr4pic (octeon)
FAIL: MIPS jal-svr4pic (octeon2)
FAIL: MIPS jal-svr4pic (octeon3)
FAIL: MIPS jal-svr4pic (octeonp)
FAIL: MIPS jal-svr4pic (r3000)
FAIL: MIPS jal-svr4pic (r3900)
FAIL: MIPS jal-svr4pic (r4000)
FAIL: MIPS jal-svr4pic (r5900)
FAIL: MIPS jal-svr4pic (sb1)
FAIL: MIPS jal-svr4pic (vr5400)
FAIL: MIPS jal-svr4pic (xlr)
FAIL: MIPS jal-svr4pic noreorder (interaptiv-mr2)
FAIL: MIPS jal-svr4pic noreorder (micromips)
FAIL: MIPS jal-svr4pic noreorder (mips1)
FAIL: MIPS jal-svr4pic noreorder (mips2)
FAIL: MIPS jal-svr4pic noreorder (mips3)
FAIL: MIPS jal-svr4pic noreorder (mips4)
FAIL: MIPS jal-svr4pic noreorder (mips5)
FAIL: MIPS jal-svr4pic noreorder (mips32)
FAIL: MIPS jal-svr4pic noreorder (mips32r2)
FAIL: MIPS jal-svr4pic noreorder (mips32r3)
FAIL: MIPS jal-svr4pic noreorder (mips32r5)
FAIL: MIPS jal-svr4pic noreorder (mips32r6)
FAIL: MIPS jal-svr4pic noreorder (mips64)
FAIL: MIPS jal-svr4pic noreorder (mips64r2)
FAIL: MIPS jal-svr4pic noreorder (mips64r3)
FAIL: MIPS jal-svr4pic noreorder (mips64r5)
FAIL: MIPS jal-svr4pic noreorder (mips64r6)
FAIL: MIPS jal-svr4pic noreorder (octeon)
FAIL: MIPS jal-svr4pic noreorder (octeon2)
FAIL: MIPS jal-svr4pic noreorder (octeon3)
FAIL: MIPS jal-svr4pic noreorder (octeonp)
FAIL: MIPS jal-svr4pic noreorder (r3000)
FAIL: MIPS jal-svr4pic noreorder (r3900)
FAIL: MIPS jal-svr4pic noreorder (r4000)
FAIL: MIPS jal-svr4pic noreorder (r5900)
FAIL: MIPS jal-svr4pic noreorder (sb1)
FAIL: MIPS jal-svr4pic noreorder (vr5400)
FAIL: MIPS jal-svr4pic noreorder (xlr)
FAIL: MIPS R3000 jal-xgot
FAIL: MIPS -mabi=32 test 2 (SVR4 PIC)
FAIL: gas/mips/jalr2
FAIL: Relax microMIPS branches (pic)
FAIL: Relax microMIPS branches (insn32 mode, pic)

Strictly speaking no MIPSr6 or microMIPS target is supported by IRIX,
but GAS supports such configurations on the basis of uniformity, so
provide the relevant patterns too rather than excluding the combinations
from testing.

gas/
* testsuite/gas/mips/jal-svr4pic-irix.d: New file.
* testsuite/gas/mips/mips1@jal-svr4pic-irix.d: New file.
* testsuite/gas/mips/mipsr6@jal-svr4pic-irix.d: New file.
* testsuite/gas/mips/micromips@jal-svr4pic-irix.d: New file.
* testsuite/gas/mips/r3000@jal-svr4pic-irix.d: New file.
* testsuite/gas/mips/jal-svr4pic-local-irix.d: New file.
* testsuite/gas/mips/mips1@jal-svr4pic-local-irix.d: New file.
* testsuite/gas/mips/micromips@jal-svr4pic-local-irix.d: New
file.
* testsuite/gas/mips/r3000@jal-svr4pic-local-irix.d: New file.
* testsuite/gas/mips/jal-svr4pic-noreorder-irix.d: New file.
* testsuite/gas/mips/mips1@jal-svr4pic-noreorder-irix.d: New
file.
* testsuite/gas/mips/mipsr6@jal-svr4pic-noreorder-irix.d: New
file.
* testsuite/gas/mips/micromips@jal-svr4pic-noreorder-irix.d: New
file.
* testsuite/gas/mips/r3000@jal-svr4pic-noreorder-irix.d: New
file.
* testsuite/gas/mips/jal-xgot-irix.d: New file.
* testsuite/gas/mips/jalr2-irix.d: New file.
* testsuite/gas/mips/micromips-branch-relax-insn32-pic-irix.d:
New file.
* testsuite/gas/mips/micromips-branch-relax-pic-irix.d: New
file.
* testsuite/gas/mips/mips-abi32-pic2-irix.d: New file.
* testsuite/gas/mips/jal-svr4pic-local.d: Don't exclude
`*-*-irix*' targets.  Add source file designator.
* testsuite/gas/mips/mips1@jal-svr4pic-local.d: Don't exclude
`*-*-irix*' targets.
* testsuite/gas/mips/r3000@jal-svr4pic-local.d: Likewise.
* testsuite/gas/mips/micromips@jal-svr4pic-local.d: Likewise.
* testsuite/gas/mips/jalr2.d: Add name designator.
* testsuite/gas/mips/mips.exp: Use respective IRIX variants for
tests involving the JALR relocation throughout.

MIPS/GAS/testsuite: Use a helper variable for IRIX/non-IRIX test selection

Define a helper variable for IRIX/non-IRIX test selection and use it
with the PR 14798 test case.

gas/
* testsuite/gas/mips/mips.exp: Use a helper variable for
IRIX/non-IRIX test selection.

gdbserver: handle running threads in qXfer:threads:read

On some systems, the gdb.multi/multi-target.exp testcase occasionally
fails like so:

 Running src/gdb/testsuite/gdb.multi/multi-target.exp ...
 FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 1: info connections
 FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 1: info inferiors
 FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 2: info connections
 FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 2: info inferiors
 FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 3: inferior 3
 ... many more cascading fails.

The problem starts when the testcase runs an inferior against GDBserver:

 (gdb) run
 Starting program: build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target
 Reading /lib64/ld-linux-x86-64.so.2 from remote target...
 warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
 Reading /lib64/ld-linux-x86-64.so.2 from remote target...
 Reading /lib64/ld-2.31.so from remote target...
 Reading /lib64/.debug/ld-2.31.so from remote target...
 Reading /usr/lib/debug//lib64/ld-2.31.so from remote target...
 Reading /usr/lib/debug/lib64//ld-2.31.so from remote target...
 Reading target:/usr/lib/debug/lib64//ld-2.31.so from remote target...
 Reading /lib/x86_64-linux-gnu/libpthread.so.0 from remote target...
 Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
 Reading /lib/x86_64-linux-gnu/libc-2.31.so from remote target...
 Reading /lib/x86_64-linux-gnu/.debug/libc-2.31.so from remote target...
 Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target...
 Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target...
 Remote connection closed
 ...

Note the "Remote connection closed" message.  That means GDBserver
exited abruptly.

I traced it down to the fact that GDB fetches the thread list from
GDBserver while the main thread of the process is still running.  On
my main system where I wrote the testcase, I have not observed the
failure because it is slow enough that the thread stops before
GDBserver fetches the thread list in the problem scenario which I'll
describe below.

With some --remote-debug logging from GDBserver side, we see the last
packets before the connection closes:

 ...
 getpkt ("vCont;c");  [no ack sent]
 putpkt ("$OK#9a"); [noack mode]
 getpkt ("Tp10f9a.10f9a");  [no ack sent]
 putpkt ("$OK#9a"); [noack mode]
 getpkt ("Hgp0.0");  [no ack sent]
 putpkt ("$OK#9a"); [noack mode]
 getpkt ("qXfer:threads:read::0,1000");  [no ack sent]

Note the vCont;c , which sets the program running, and then a
qXfer:threads:read packet at the end.

The problem happens when the thread list refresh (qXfer:threads:read)
is sent just while the main thread is running and it still hasn't
initialized its libpthread id internally.  In that state, the main
thread's lwp will remain with the thread_known flag clear.  See in
find_one_thread:

  /* If the new thread ID is zero, a final thread ID will be available
     later.  Do not enable thread debugging yet.  */
  if (ti.ti_tid == 0)
    return 0;

Now, back in server.cc, to handle the qXfer:threads:read, we reach
handle_qxfer_threads -> handle_qxfer_threads_proper, and the latter
then calls handle_qxfer_threads_worker for each known thread.  In
handle_qxfer_threads_worker, we call target_thread_handle.  This ends
up in thread_db_thread_handle, here:

  if (!lwp->thread_known && !find_one_thread (thread->id))
    return false;

Since the thread ID isn't known yet, we call find_one_thread.  This
calls into libthread_db.so, which accesses memory.  Because the
current thread is running, that fails and we throw an error, here:

  /* Get information about this thread.  */
  err = thread_db->td_ta_map_lwp2thr_p (thread_db->thread_agent, lwpid, &th);
  if (err != TD_OK)
    error ("Cannot get thread handle for LWP %d: %s",
   lwpid, thread_db_err_str (err));

The current design is that whenever GDB-facing packets/requests need
to accesses memory, server.cc is supposed to prepare the target for
the access.  See gdb_read_memory / gdb_write_memory.  This preparation
means pausing threads if in non-stop mode (someday we could lift this
requirement, but we will still need to pause to access registers or do
other related ptrace accesses like PTRACE_GET_THREAD_AREA).  Note that
the multi-target.exp testcase forces "maint set target-non-stop on".

So the fix here is to prepare the target to access memory when
handling qXfer:threads:read too.

gdbserver/ChangeLog:

* inferiors.cc (switch_to_process): New, moved here from
thread-db.cc, and made extern.
* inferiors.h (switch_to_process): Declare.
* server.cc: Include "gdbsupport/scoped_restore.h".
(handle_qxfer_threads_proper): Now returns bool.  Prepare to
access memory around target calls.
(handle_qxfer_threads): Handle errors.
* thread-db.cc (switch_to_process): Moved to inferiors.cc.

ld: Properly override the IR definition

We change the previous definition in the IR object to undefweak only
after all LTO symbols have been read.

include/

PR ld/26262
PR ld/26267
* bfdlink.h (bfd_link_info): Add lto_all_symbols_read.

ld/

PR ld/26262
PR ld/26267
* ldlang.c (lang_process): Set lto_all_symbols_read after all
LTO IR symbols have been read.
* plugin.c (plugin_notice): Override the IR definition only if
all LTO IR symbols have been read or the new definition is
non-weak and the the IR definition is weak
* testsuite/ld-plugin/lto.exp: Run PR ld/26262 and ld/26267
tests.
* testsuite/ld-plugin/pr26262a.c: New file.
* testsuite/ld-plugin/pr26262b.c: Likewise.
* testsuite/ld-plugin/pr26262c.c: Likewise.
* testsuite/ld-plugin/pr26267.err: Likewise.
* testsuite/ld-plugin/pr26267a.c: Likewise.
* testsuite/ld-plugin/pr26267b.c: Likewise.
* testsuite/ld-plugin/pr26267c.c: Likewise.

bfd: xtensa: pr26246: fix removed_literal_compare

2020-07-22  Max Filippov  <jcmvbkbc@gmail.com>
bfd/
PR 26246
* elf32-xtensa.c (removed_literal_compare): Use correct pointer
type for the first function argument. Rename pointers to reflect
that they have distinct types.

Retire the now-unused gdbarch handle_segmentation_fault hook.

* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (handle_segmentation_fault): Remove method.
* infrun.c (handle_segmentation_fault): Remove.
(print_signal_received_reason): Remove call to
handle_segmentation_fault.

Migrate the sparc64 ADI handle_segmentation_fault hook to report_signal_info.

gdb/ChangeLog:

* sparc64-linux-tdep.c (sparc64_linux_handle_segmentation_fault):
Rename to sparc64_linux_report_signal_info and add siggnal
argument.
(sparc64_linux_init_abi): Use sparc64_linux_report_signal_info
instead of sparc64_linux_handle_segmentation_fault.

Migrate the x86 MPX handle_segmentation_fault hook to report_signal_info.

gdb/ChangeLog:

* amd64-linux-tdep.c (amd64_linux_init_abi_common): Use
i386_linux_report_signal_info instead of
i386_linux_handle_segmentation_fault.
* i386-linux-tdep.c (i386_linux_handle_segmentation_fault): Rename
to i386_linux_report_signal_info and add siggnal argument.
(i386_linux_init_abi): Use i386_linux_report_signal_info instead
of i386_linux_handle_segmentation_fault.
* i386-linux-tdep.h (i386_linux_handle_segmentation_fault): Rename
to i386_linux_report_signal_info and add siggnal argument.

Report architecture-specific signal information for core files.

When opening a core file, if the process terminated due to a signal,
invoke the gdbarch report_signal_info hook to report
architecture-specific information about the signal.

gdb/ChangeLog:

* corelow.c (core_target_open): Invoke gdbarch report_signal_info
hook if present.

Add a new gdbarch hook to report additional signal information.

This is a more general version of the existing handle_segmentation_fault
hook that is able to report information for an arbitrary signal, not
just SIGSEGV.

gdb/ChangeLog:

* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (report_signal_info): New method.
* infrun.c (print_signal_received_reason): Invoke gdbarch
report_signal_info hook if present.

Automatic date update in version.in

gdb/python: Reuse gdb.RegisterGroup objects where possible

Only create one gdb.RegisterGroup Python object for each of GDB's
reggroup objects.

I could have added a field into the reggroup object to hold the Python
object pointer for each reggroup, however, as reggroups are never
deleted within GDB, and are global (not per-architecture) a simpler
solution seemed to be just to hold a single global map from reggroup
pointer to a Python object representing the reggroup.  Then we can
reuse the objects out of this map.

After this commit it is possible for a user to tell that two
gdb.RegisterGroup objects are now identical when previously they were
unique, however, as both these objects are read-only I don't think
this should be a problem.

There should be no other user visible changes after this commit.

gdb/ChangeLog:

* python/py-registers.c : Add 'unordered_map' include.
(gdbpy_new_reggroup): Renamed to...
(gdbpy_get_reggroup): ...this.  Update to only create register
group descriptors when needed.
(gdbpy_reggroup_iter_next): Update.

gdb/testsuite/ChangeLog:

* gdb.python/py-arch-reg-groups.exp: Additional tests.

gdb/python: Reuse gdb.RegisterDescriptor objects where possible

Instead of having the gdb.RegisterDescriptorIterator creating new
gdb.RegisterDescriptor objects for each regnum, instead cache
gdb.RegisterDescriptor objects on the gdbarch object and reuse these.

This means that for every gdbarch/regnum pair there is a single unique
gdb.RegisterDescriptor, this feels like a neater implementation than
the existing one.

It is possible for a user to see (in Python code) that the descriptors
are now identical, but as the descriptors are read-only this should
make no real difference.

There should be no other user visible changes.

gdb/ChangeLog:

* python/py-registers.c (gdbpy_register_object_data): New static
global.
(gdbpy_register_object_data_init): New function.
(gdbpy_new_register_descriptor): Renamed to...
(gdbpy_get_register_descriptor): ...this, and update to reuse
existing register descriptors where possible.
(gdbpy_register_descriptor_iter_next): Update.
(gdbpy_initialize_registers): Register new gdbarch data.

gdb/testsuite/ChangeLog:

* gdb.python/py-arch-reg-names.exp: Additional tests.

gdb, gdbserver: make stopped_pids global variables static

I noticed that my IDE was confusing the two stopped_pids variables.
There is one in GDB and one in GDBserver.  They should be static, make
them so.

gdb/ChangeLog:

* linux-nat.c (stopped_pids): Make static.

gdbserver/ChangeLog:

* linux-low.cc (stopped_pids): Make static.

Change-Id: If4a2bdcd45d32eb3a732d266a0f686a4e4c23672

gdb: handle undefined properties in ada_discrete_type_{low,high}_bound

This patch fixes a failure in test `gdb.ada/access_to_packed_array.exp`.
The failure was introduced by 8c2e4e0689ea24 ("gdb: add accessors to
struct dynamic_prop"), but I think it in fact exposed a latent buglet.

Note that to reproduce it, I had to use AdaCore's Ada "distribution"
[1].  The one that comes with my distro doesn't have debug info for the
standard library stuff, so the bug wouldn't trigger.

The bug is that while executing the `maint print symbols` command, we
are accessing the value of a range type's high bound dynamic prop as a
"const" value (PROP_CONST), when it is actually undefined
(PROP_UNDEFINED).  It results in this failed assertion:

    /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.

`ada_discrete_type_high_bound` calls `resolve_dynamic_type`, which
eventually calls `resolve_dynamic_range`.  This one is responsible for
evaluating a range type's dynamic bounds in the current context and
returning static values.  It returns a new range type with these static
bounds.

The resulting bounds are typically properties of the PROP_CONST kind.
But when it's not possible to evaluate the properties, the properties
are PROP_UNDEFINED.  In the case we are looking at, it's not possible to
evaluate the dynamic high bound, which is of type PROP_LOCLIST.  It
would require a target with registers and a frame, but we run `maint
print symbols` without a live process.

`ada_discrete_type_high_bound` then accesses the high bound
unconditionally as a const value, which triggers the assert.

Note that the previous code in resolve_dynamic_range (before commit
8c2e4e0689ea24) did this:

    prop = &TYPE_RANGE_DATA (dyn_range_type)->high;
    if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
      {
        high_bound.kind = PROP_CONST;
        high_bound.data.const_val = value;

        if (TYPE_RANGE_DATA (dyn_range_type)->flag_upper_bound_is_count)
   high_bound.data.const_val
     = low_bound.data.const_val + high_bound.data.const_val - 1;
      }
    else
      {
        high_bound.kind = PROP_UNDEFINED;
        high_bound.data.const_val = 0;
      }

That did not really made sense, setting the kind to `PROP_UNDEFINED` but
also setting the `const_val` field.  The `const_val` field is only
meaningful if the kind if `PROP_CONST`.  The new code
(post-8c2e4e0689ea24) simply calls `set_undefined ()`.

Fix this by making the caller, `ada_discrete_type_high_bound`, consider
that a range high bound could be of kind `PROP_UNDEFINED`, and return
0 in this case.  I made the same change in ada_discrete_type_low_bound.
I didn't encounter a problem with this function, but the same could in
theory happen there.

Returning 0 here is kind of a lie, but the goal here is just to restore
the behavior of pre-8c2e4e0689ea24.

The output of `maint print symbols` is:

     typedef <ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0;
     record
         ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0;
     end record;

Instead of `1 .. 0`, which does not make sense, we could say something
like `1 .. <dynamic>`.  But that would require more changes than I'm
willing to do at the moment.

[1] https://www.adacore.com/download

gdb/ChangeLog:

PR ada/26235
* gdbtypes.c (ada_discrete_type_low_bound,
ada_discrete_type_high_bound): Handle undefined bounds.

Change-Id: Ia12167e61ef030941c0790f83294f3418e6a7c12

[gdb/testsuite] Fix gdb.reverse/solib-{precsave,reverse}.exp with gcc-8

With gcc-8, we have the following FAILs, which are not there for gcc-7:
...
FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function two
FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function two
FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main two
FAIL: gdb.reverse/solib-precsave.exp: run until end part two
FAIL: gdb.reverse/solib-precsave.exp: reverse-next over solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two
FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main two
FAIL: gdb.reverse/solib-reverse.exp: run until end part two
FAIL: gdb.reverse/solib-reverse.exp: reverse-next over solib function one
...

Looking at the first FAIL for gdb.reverse/solib-precsave.exp, we have:
...
 (gdb) PASS: reverse-next first shr1
 reverse-next^M
 40        b[0] = 6;   b[1] = 9;     /* generic statement, end part two */^M
 (gdb) PASS: reverse-next generic
 reverse-step^M
-shr2 (x=17) at gdb.reverse/shr2.c:23^M
-23      }^M
-(gdb) PASS: reverse-step into solib function one
+38        b[1] = shr2(17);              /* middle part two */^M
+(gdb) FAIL: reverse-step into solib function one
...

There's a difference in line number info for line 38, where for gcc-7 we have:
...
Line number    Starting address    View    Stmt
         38            0x4005c6               x
...
and for gcc-8:
...
         38            0x4005c1               x
         38            0x4005cb               x
...
which explains why we don't step directly into "solib function one".

Fix this by recognizing the extra "recommended breakpoint location" and
issuing an additional reverse-next/step.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-21  Tom de Vries  <tdevries@suse.de>

* gdb.reverse/solib-precsave.exp: Handle additional "recommended
breakpoint locations".
* gdb.reverse/solib-reverse.exp: Same.

[gdb/testsuite] Fix step-reverse.c with gcc-10

The file gdb.reverse/step-reverse.c is used in test-cases:
- gdb.reverse/step-reverse.exp
- gdb.reverse/next-reverse-bkpt-over-sr.exp
- gdb.reverse/step-precsave.exp

With gcc-7, there are only PASSes (apart from one KFAIL), but with gcc-10, we
have the following FAILs:
...
FAIL: gdb.reverse/step-reverse.exp: reverse stepi from a function call \
  (start statement)
FAIL: gdb.reverse/step-reverse.exp: simple reverse stepi
FAIL: gdb.reverse/step-reverse.exp: reverse step out of called fn
FAIL: gdb.reverse/step-reverse.exp: reverse next over call
FAIL: gdb.reverse/step-reverse.exp: reverse step test 1
FAIL: gdb.reverse/step-reverse.exp: reverse next test 1
FAIL: gdb.reverse/step-reverse.exp: reverse step test 2
FAIL: gdb.reverse/step-reverse.exp: reverse next test 2
FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \
  (start statement)
FAIL: gdb.reverse/step-precsave.exp: simple reverse stepi
FAIL: gdb.reverse/step-precsave.exp: reverse step out of called fn
FAIL: gdb.reverse/step-precsave.exp: reverse next over call
FAIL: gdb.reverse/step-precsave.exp: reverse step test 1
FAIL: gdb.reverse/step-precsave.exp: reverse next test 1
FAIL: gdb.reverse/step-precsave.exp: reverse step test 2
FAIL: gdb.reverse/step-precsave.exp: reverse next test 2
...

Looking at the first step-precsave.exp FAIL, we have:
...
(gdb) stepi^M
26        myglob++; return 0;   /* ARRIVED IN CALLEE */^M
(gdb) PASS: gdb.reverse/step-precsave.exp: reverse stepi thru function return
stepi^M
0x000000000040055f      26        myglob++; return 0;   /* ARRIVED IN CALLEE */^M
(gdb) FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \
  (start statement)
...

There's a difference in line info for callee:
...
    25  int callee() {          /* ENTER CALLEE */
    26    myglob++; return 0;   /* ARRIVED IN CALLEE */
    27  }                       /* RETURN FROM CALLEE */
...
between gcc-7:
...
Line number    Starting address    View    Stmt
         25            0x400557               x
         26            0x40055b               x
         27            0x40056f               x
...
and gcc-10:
...
         25            0x400552               x
         26            0x400556               x
         26            0x400565               x
         27            0x40056a               x
...

The two "recommend breakpoint location" entries at line 26 are for the two
statements ("myglob++" and "return 0"), but the test-case expects to hit line
26 only once.

Fix this by rewriting the two statements into a single statement:
...
-  myglob++; return 0;  /* ARRIVED IN CALLEE */
+  return myglob++;     /* ARRIVED IN CALLEE */
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-21  Tom de Vries  <tdevries@suse.de>

* gdb.reverse/step-reverse.c (callee): Merge statements.

Enable multi-process mode in the NetBSD native target.

This enables proper support for multiple inferiors and ptrace(2)
assisted management of the inferior processes and their threads.

(gdb) info inferior
  Num  Description       Connection           Executable
* 1    process 14952     1 (native)           /usr/bin/dig
  2    <null>            1 (native)
  3    process 25684     1 (native)           /bin/ls
  4    <null>            1 (native)           /bin/ls

Without this patch, additional inferiors can be added, but not
properly controlled.

gdb/ChangeLog:

        * nbsd-nat.h (nbsd_nat_target::supports_multi_process): New
        declaration.
        * nbsd-nat.c (nbsd_nat_target::supports_multi_process): New
        function.

Revert "x86: Don't display eiz with no scale"

This reverts commit 04c662e2b66bedd050f97adec19afe0fcfce9ea7.
In my underlying suggestion I neglected the fact that in those
cases (,%eiz,1) is the only visible indication that 32-bit
addressing is in effect.

Fix Unreasonable arch and cpu conflict warning for ther CSky architecture.

* config/tc-csky.c (md_begin): Fix tests of arch and mach flags.

Updated Swedish translation for the binutils sub-directory

[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-8

When using test-case gdb.fortran/info-modules.exp with gcc 8.4.0, I run into:
...
FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \
  'info-types.f90', '35', 'Type m1t1 mod1::__def_init_mod1_M1t1;'
FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \
  'info-types.f90', '35', 'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;'
...

This is caused by this change in gdb output:
...
 (gdb) info module variables
    ...
 File gdb.fortran/info-types.f90:
-35:     Type m1t1 mod1::__def_init_mod1_M1t1;
+        Type m1t1 mod1::__def_init_mod1_M1t1;
-35:     Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;
+        Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;
 21:     real(kind=4) mod1::mod1_var_1;
 22:     integer(kind=4) mod1::mod1_var_2;
...
caused by a change in debug info.

Fix this by allowing those entries without line number.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-21  Tom de Vries  <tdevries@suse.de>

* gdb.fortran/info-modules.exp (info module variables): Allow missing
line numbers for some variables.

Revert "x86: Replace evex-no-scale.s with evex-no-scale-[32|64].s"

This reverts commit 19449d7c67690c641b1ec9c13ff3531677a5afcc, addressing
the issue that was run into back then: There was no relationship to i686-*
and/or cross builds on 64-bit hosts. The sole problem was the use of / as
as comment character in certain ELF targets. Instead of division, use a
comparison operation.

At the same time also revert the ELF related part of 99c2d522f7a7 ("x86:
Update assembler tests for non-ELF targets") by replacing the construct
that's problematic for non-ELF, and by adding the "#pass" patterns to
the expected output files to cover for the tail padding generated into
COFF output.

[gdb/testsuite] Make inline-locals.c deterministic

When running testcase gdb.opt/inline-locals.exp on openSUSE Tumbleweed, I get:
...
(gdb) info locals^M
array = {0 <repeats 48 times>, 15775231, 0, 194, 0, -11497, 32767, 4199061, \
  0, 0, 0, 0, 0, 4198992, 0, 4198432, 0}^M
(gdb) FAIL: gdb.opt/inline-locals.exp: info locals above bar 2
...

Fix this by:
- completely initializing array before printing any value
- updating the pattern to match "array = {0 <repeats 64 times>}"

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-21  Tom de Vries  <tdevries@suse.de>

* gdb.opt/inline-locals.c (init_array): New func.
(func1): Use init_array.
* gdb.opt/inline-locals.exp: Update pattern.

[gdb/testsuite] Don't leak env vars in gdb.debuginfod/fetch_src_and_symbols.exp

Test-case gdb.debuginfod/fetch_src_and_symbols.exp leaks env vars
DEBUGINFOD_URLS, DEBUGINFOD_TIMEOUT and DEBUGINFOD_CACHE_PATH, causing
timeouts in subsequent tests.

Fix this by using save_vars.  Also, fix PATH and DUPLICATE errors.  Finally,
cleanup whitespace.

gdb/testsuite/ChangeLog:

2020-07-21  Tom de Vries  <tdevries@suse.de>

* gdb.debuginfod/fetch_src_and_symbols.exp: Use save_vars for env
vars.  Fix PATH and DUPLICATE errors.  Cleanup whitespace.

MIPS/GAS: Remove stale `prev_reloc_op_frag' variable

Ever since commit 4d7206a284ee ("Rework MIPS macro relaxation, fix string
merging bug"), <https://sourceware.org/ml/binutils/2004-01/msg00248.html>,
`prev_reloc_op_frag' has only been set and never used.  Remove it then.

gas/
* config/tc-mips.c (prev_reloc_op_frag): Remove variable.
(my_getSmallExpression): Adjust accordingly.

Automatic date update in version.in

Implement the skip_solib_resolver gdbarch hook for FreeBSD architectures.

The ELF runtime linker on all FreeBSD architectures uses the
"_rtld_bind" entry point for unresolved PTL entries.  FreeBSD/mips has
an additional entry point called "_mips_rtld_bind".

gdb/ChangeLog:

* fbsd-tdep.c (fbsd_skip_solib_resolver): New function.
(fbsd_init_abi): Install gdbarch "skip_solib_resolver" method.
* fbsd-tdep.h (fbsd_skip_solib_resolver): New prototype.
* mips-fbsd-tdep.c (mips_fbsd_skip_solib_resolver): New function.
(mips_fbsd_init_abi): Install gdbarch "skip_solib_resolver"
method.

guile: Add support for Guile 3.0.

gdb/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* guile/scm-math.c (vlscm_integer_fits_p): Use 'uintmax_t'
and 'intmax_t' instead of 'scm_t_uintmax' and 'scm_t_intmax',
which are deprecated in Guile 3.0.
* configure.ac (try_guile_versions): Add "guile-3.0".
* configure (try_guile_versions): Regenerate.
* NEWS: Update entry.

gdb/testsuite/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* gdb.guile/source2.scm: Add #f first argument to 'format'.
* gdb.guile/types-module.exp: Remove "ERROR:" from
regexps since Guile 3.0 no longer prints that.

gdb/doc/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* doc/guile.texi (Guile Introduction): Mention Guile 3.0.

Change-Id: Iff116c2e40f334e4e0ca4e759a097bfd23634679

guile: Add support for Guile 2.2.

This primarily updates code that uses the I/O port API of Guile.

gdb/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>
            Doug Evans  <dje@google.com>

PR gdb/21104
* guile/scm-ports.c (USING_GUILE_BEFORE_2_2): New macro.
(ioscm_memory_port)[read_buf_size, write_buf_size]: Wrap in #if
USING_GUILE_BEFORE_2_2.
(stdio_port_desc, memory_port_desc) [!USING_GUILE_BEFORE_2_2]:
Change type to 'scm_t_port_type *'.
(natural_buffer_size) [!USING_GUILE_BEFORE_2_2]: New variable.
(ioscm_open_port) [USING_GUILE_BEFORE_2_2]: Add 'stream'
parameter and honor it.  Update callers.
(ioscm_open_port) [!USING_GUILE_BEFORE_2_2]: New function.
(ioscm_read_from_port, ioscm_write) [!USING_GUILE_BEFORE_2_2]: New
functions.
(ioscm_fill_input, ioscm_input_waiting, ioscm_flush): Wrap in #if
USING_GUILE_BEFORE_2_2.
(ioscm_init_gdb_stdio_port) [!USING_GUILE_BEFORE_2_2]: Use
'ioscm_read_from_port'.  Call 'scm_set_port_read_wait_fd'.
(ioscm_init_stdio_buffers) [!USING_GUILE_BEFORE_2_2]: New function.
(gdbscm_stdio_port_p) [!USING_GUILE_BEFORE_2_2]: Use 'SCM_PORTP'
and 'SCM_PORT_TYPE'.
(gdbscm_memory_port_end_input, gdbscm_memory_port_seek)
(ioscm_reinit_memory_port): Wrap in #if USING_GUILE_BEFORE_2_2.
(gdbscm_memory_port_read, gdbscm_memory_port_write)
(gdbscm_memory_port_seek, gdbscm_memory_port_close)
[!USING_GUILE_BEFORE_2_2]: New functions.
(gdbscm_memory_port_print): Remove use of 'SCM_PTOB_NAME'.
(ioscm_init_memory_port_type) [!USING_GUILE_BEFORE_2_2]: Use
'gdbscm_memory_port_read'.
Wrap 'scm_set_port_end_input', 'scm_set_port_flush', and
'scm_set_port_free' calls in #if USING_GUILE_BEFORE_2_2.
(gdbscm_get_natural_buffer_sizes) [!USING_GUILE_BEFORE_2_2]: New
function.
(ioscm_init_memory_port): Remove.
(ioscm_init_memory_port_stream): New function
(ioscm_init_memory_port_buffers) [USING_GUILE_BEFORE_2_2]: New
function.
(gdbscm_memory_port_read_buffer_size) [!USING_GUILE_BEFORE_2_2]:
Return scm_from_uint (0).
(gdbscm_set_memory_port_read_buffer_size_x)
[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
(gdbscm_memory_port_write_buffer_size) [!USING_GUILE_BEFORE_2_2]:
Return scm_from_uint (0).
(gdbscm_set_memory_port_write_buffer_size_x)
[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
* configure.ac (try_guile_versions): Add "guile-2.2".
* configure: Regenerate.
* NEWS: Add entry.

gdb/testsuite/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* gdb.guile/scm-error.exp ("source $remote_guile_file_1"): Relax
error regexp to match on Guile 2.2.

gdb/doc/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* guile.texi (Memory Ports in Guile): Mark
'memory-port-read-buffer-size',
'set-memory-port-read-buffer-size!',
'memory-port-write-buffer-size',
'set-memory-port-read-buffer-size!' as deprecated.
* doc/guile.texi (Guile Introduction): Clarify which Guile
versions are supported.

Change-Id: Ib119b10a2787446e0ae482a5e1b36d809c44bb31

Skip tests requiring "alignof (void)" when compiling using clang

As an extension, GCC allows void pointer arithmetic, with sizeof(void)
and alignof(void) both 1.  GDB supports this extension, but clang does
not, and fails to compile the generated output of gdb.cp/align.exp
with the following error:

 gdb compile failed, /gdbtest/build/gdb/testsuite/outputs/gdb.cp/align/align.cc:28:23:
       error: invalid application of 'alignof' to an incomplete type 'void'
    unsigned a_void = alignof (void);
                      ^       ~~~~~~
 1 error generated.

This commit adds preprocessor conditionals to the generated output, to
omit the unsupported code when using clang, and supplies the expected
value so the test can complete.

gdb/testsuite/ChangeLog:

* gdb.cp/align.exp: Fix "alignof (void)" tests when compiling
with clang.

Fix problem running a few PowerPC linker tests when the .data section is retained.

* testsuite/ld-powerpc/powerpc.exp (ppcelftests): Use section name
.PPC.EMB.apuinfo instead of section number 2 in apuinfo tests.

PR26265, Spurious 'gc-sections requires ... when --init or --fini

bfd/
* elflink.c (_bfd_elf_gc_keep): Use bfd_is_const_section.
ld/
PR 26265
* ldlang.c (undef_from_cmdline): Delete.
(ldlang_add_undef): Mark "cmdline" param unused.
(lang_end): Traverse gc_sym_list to determine whether a symbol root
has been specified.  Update error message.
* testsuite/ld-gc/noent.d: Adjust for changed error message.

[gdb/testsuite] Stabilize execution order in omp-par-scope.c

In openmp test-case gdb.threads/omp-par-scope.exp we xfail and kfail dependent
on omp_get_thread_num ().  Since execution order of the threads can vary from
execution to execution, this can cause changes in test results.

F.i., we can see this difference between two test runs:
...
-KFAIL: single_scope: first thread: print i3 (PRMS: gdb/22214)
+PASS: single_scope: first thread: print i3
-PASS: single_scope: second thread: print i3
+KFAIL: single_scope: second thread: print i3 (PRMS: gdb/22214)
...
In both cases, the KFAIL is for omp_get_thread_num () == 1, but in one case
that corresponds to the first thread executing that bit of code, and in the
other case to the second thread.

Get rid of this difference by stabilizing execution order.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-20  Tom de Vries  <tdevries@suse.de>

* gdb.threads/omp-par-scope.c (lock, lock2): New variable.
(omp_set_lock_in_order): New function.
(single_scope, multi_scope, nested_func, nested_parallel): Use
omp_set_lock_in_order and omp_unset_lock.
(main): Init and destroy lock and lock2.

x86: Update PR gas/26263 linker tests

Update and run PR gas/26263 linker tests for all x86 ELF targets to
accept any program header layout.

PR gas/26263
* testsuite/ld-i386/pr26263.d: Updated.
* testsuite/ld-x86-64/pr26263.d: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run gas/26263 test for all ELF
targets.

[gdb/testsuite] Fix valgrind-infcall-2.exp without libc debug info

When running test-case gdb.base/valgrind-infcall-2.exp on a system without
libc debug info installed, I run into:
...
(gdb) p printf ("bla")^M
'printf' has unknown return type; cast the call to its declared return type^M
(gdb) FAIL: gdb.base/valgrind-infcall-2.exp: do printf
...

Fix this by casting the result of the printf call to int.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-20  Tom de Vries  <tdevries@suse.de>

* gdb.base/valgrind-infcall-2.exp: Handle printf unknown return type.

[gdb/testsuite] Bail out after gdb_start error in gdb.threads/attach-slow-waitpid.exp

When building gdb using CFLAGS/CXXFLAGS+=-fsanitizer=address and
LDFLAGS+=-lasan, and running test-case gdb.threads/attach-slow-waitpid.exp,
we get:
...
spawn gdb -nw -nx -data-directory data-directory^M
==16079==ASan runtime does not come first in initial library list; \
  you should either link runtime to your application or manually preload \
  it with LD_PRELOAD.^M
ERROR: (eof) GDB never initialized.
ERROR: : spawn id exp10 not open
    while executing
"expect {
-i exp10 -timeout 120
        -re "Kill the program being debugged. .y or n. $" {
            send_gdb "y\n" answer
            verbose "\t\tKilling previous pro..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp10 not open
WARNING: remote_expect statement without a default case
ERROR: : spawn id exp10 not open
    while executing
"expect {
-i exp10 -timeout 120
        -re "Reading symbols from.*LZMA support was disabled.*$gdb_prompt $" {
            verbose "\t\tLoaded $arg into $GDB; .gnu_..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp10 not open
ERROR: Couldn't load attach-slow-waitpid into GDB (eof).
ERROR: Couldn't send attach 16070 to GDB.
UNRESOLVED: gdb.threads/attach-slow-waitpid.exp: attach to target
...

Bail out at the first ERROR, such that we have instead:
...
ERROR: (eof) GDB never initialized.
UNTESTED: gdb.threads/attach-slow-waitpid.exp: \
  Couldn't start GDB with preloaded lib
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-20  Tom de Vries  <tdevries@suse.de>

* gdb.threads/attach-slow-waitpid.exp: Bail out if gdb_start fails.

x86: handle SVR4 escaped binary operators

PR gas/4572

When / is a comment character, its use as binary "divide" operator needs
escaping by a backslash. Besides the scrubber needing to support this
(addressed in an earlier change), there are also a few provisions needed
in target specific operator handling.

As the spec calls for % and * to also be escaped because of being
"overloaded", also recognize these, despite the overloading there not
really preventing their use as operators in most (%) or all (*) cases,
given the way how the rest of the assembler works.

To bring source and testsuite in line, also drop the TE_I386AIX part of
the respective conditional, as i?86-*-aix* support had been removed a
while ago.

gas: generalize comment character escaping recognition

PR gas/4572

Generalize what ab1fadc6b2f0 ("PR22714, Assembler preprocessor loses
track of \@") did to always honor escaped comment chars. Use this then
to support escaped /, %, and * operators on x86, when / is a comment
char (to match the Sun assembler's behavior).

x86: honor absolute section when emitting code

Various provisions exist for insns to be placed in the absolute section,
yet actually trying to do so didn't work. While data emission (of non-
zero values) is not allowed by generic code, I think this functionality
is useful for the programmer to be able to determine the size of insns.
Therefore, rather than turning the silnet failure into a verbose one,
make things mostly work; the one class of insns not supported (yet) are
branches (JMP and Jcc) with dynamically determined displacement widths.
In this one case, an error now gets reported instead of silently
ignoring the code.

Also avoid recording ISA / feature usage for insns emitted to the
absolute section.

ix86: enable more ELF tests for VxWorks

The tree-wide is_elf_format predicate excludes VxWorks, but the majority
of ELF specific tests is quite fine for this target.

Automatic date update in version.in

gold: Update x32 test

* testsuite/split_x32.sh: Likewise.

gold: Update x86-64 tests

commit 36938cabf0efcb053d1585e8580a4b3db438ca4e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Jul 15 08:53:55 2020 +0200

    x86: avoid attaching suffixes to unambiguous insns

removed the 'a' suffix on call and jmp from disassembler output.  Update
gold x86-64 tests.

* testsuite/bnd_ifunc_1.sh: Updated.
* testsuite/bnd_plt_1.sh: Likewise.
* testsuite/split_x86_64.sh: Likewise.
* testsuite/x86_64_indirect_call_to_direct.sh: Likewise.

x86: Change PLT32 reloc against section to PC32

Commit 292676c1 resolved PLT32 reloc aganst local symbol to section.
Since PLT32 relocation must be against symbols, turn such PLT32
relocation into PC32 relocation.

gas/

PR gas/26263
* config/tc-i386.c (i386_validate_fix): Change PLT32 reloc
against section to PC32 reloc.
* testsuite/gas/i386/relax-5.d: Updated.
* testsuite/gas/i386/x86-64-relax-4.d: Likewise.

ld/

PR gas/26263
* testsuite/ld-i386/i386.exp: Run PR gas/26263 test.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-i386/pr26263.d: New file.
* testsuite/ld-x86-64/pr26263.d: Likewise.
* testsuite/ld-x86-64/pr26263.s: Likewise.

ld: optionally emit _etext last, before .data

So, here's my suggestion for making _init .. __etext cover .text +
.rodata (including things like the read-only exception tables) for
elf64mmix.  A quick web search gives that __etext (and friends) isn't
well defined, so each target can interpret the "end of text segment"
to their own liking.  It seems likely this change is also a better fit
than the default for other ports, at least those with .rodata after
.text in the same segment.

The presence of a separate rodata-segment is optional (and not true
for elf64mmix).  This is reflected in the name as SEPARATE_TEXT /
SEPARATE_CODE isn't considered, to keep it simple; each target has to
make sure their settings of variables make sense.

ld:
* scripttempl/elf.sc (ETEXT_LAST_IN_RODATA_SEGMENT): New variable.
* emulparams/elf64mmix.sh (ETEXT_LAST_IN_RODATA_SEGMENT): Define.
* testsuite/ld-mmix/sec-1.d: Adjust.

Power10 stub selection

This patch better supports mixing of power10 and non-power10 code,
as might be seen in a cpu-optimized library using ifuncs to select
functions optimized for a given cpu.  Using -Wl,--no-power10-stubs
isn't that good in this situation since non-power10 notoc stubs are
slower and larger than the power10 variants, which you'd like to use
on power10 code paths.

With this change, power10 pc-relative code that makes calls marked
@notoc uses power10 stubs if stubs are necessary, and other calls use
non-power10 instructions in stubs.  This will mean that if gcc is
generating code for -mcpu=power10 but with pc-rel disabled then you'll
get the older stubs even on power10 (unless you force with
-Wl,--power10-stubs).  That shouldn't be too big a problem: stubs that
use r2 are reasonable.  It's just the ones that set up addressing
using "mflr 12; bcl 20,31,.+4; mflr 11; mtlr 12" that should be
avoided if possible.

bfd/
* elf64-ppc.c (struct ppc_link_hash_table): Add has_power10_relocs.
(select_alt_stub): New function.
(ppc_get_stub_entry): Use it here.
(ppc64_elf_check_relocs): Set had_power10_relocs rather than
power10_stubs.
(ppc64_elf_size_stubs): Clear power10_stubs here instead.  Don't
merge notoc stubs with other varieties when power10_stubs is "auto".
Instead dup the stub hash table entry.
(plt_stub_size, ppc_build_one_stub, ppc_size_one_stub): Adjust
tests of power10_stubs.
ld/
* emultempl/ppc64elf.em (power10-stubs): Accept optional "auto" arg.
* ld.texi (power10-stubs): Update.
* testsuite/ld-powerpc/callstub-1.d: Force --power10-stubs.
* testsuite/ld-powerpc/callstub-2.d: Relax branch offset comparison.
* testsuite/ld-powerpc/callstub-4.d: New test.
* testsuite/ld-powerpc/notoc.d: Force --no-power10-stubs.
* testsuite/ld-powerpc/notoc3.d,
* testsuite/ld-powerpc/notoc3.s,
* testsuite/ld-powerpc/notoc3.wf: New test.
* testsuite/ld-powerpc/powerpc.exp: Run new tests.  Pass
--no-power10-stubs for notoc link.

Automatic date update in version.in

Remove "linux_multi_process" global

The "linux_multi_process" is initialized but never modified.  I
discussed this with Pedro on irc, and he said that, while it was
useful when developing this feature, it is now no longer needed.  So,
this removes it.

gdb/ChangeLog
2020-07-18  Tom Tromey  <tom@tromey.com>

* linux-nat.c (linux_multi_process): Remove.
(linux_nat_target::supports_multi_process): Return true.

Automatic date update in version.in

gdb/riscv: delete target descriptions when gdb exits

It was pointed out on IRC that the RISC-V target allocates target
descriptions and stores them in a global map, and doesn't delete these
target descriptions when GDB shuts down.

This isn't a particular problem, the total number of target
descriptions we can create is very limited so creating these on demand
and holding them for the entire run on GDB seems reasonable.

However, not deleting these objects on GDB exit means extra warnings
are printed from tools like valgrind, and the address sanitiser,
making it harder to spot real issues.  As it's reasonably easy to have
GDB correctly delete these objects on exit, lets just do that.

I started by noticing that we already have a target_desc_up type, a
wrapper around unique_ptr that calls a function that will correctly
delete target descriptions, so I want to use that, but....

...that type is declared in gdb/target-descriptions.h.  If I try to
include that file in gdb/arch/riscv.c I run into a problem, that file
is compiled into both GDB and GDBServer.

OK, I could guard the include with #ifdef, but surely we can do
better.

So then I decided to move the target_desc_up type into
gdbsupport/tdesc.h, this is the interface file for generic code shared
between GDB and GDBserver (relating to target descriptions).  The
actual implementation for the delete function still lives in
gdb/target-description.c, but now gdb/arch/riscv.c can see the
declaration.  Problem solved....

... but, though RISC-V doesn't use it I've now exposed the
target_desc_up type to gdbserver, so in future someone _might_ start
using it, which is fine, except right now there's no definition of the
delete function - remember the delete I used is only defined in GDB
code.

No problem, I add an implementation of the delete operator into
gdbserver/tdesc.cc, and all is good..... except....

I start getting this error from GCC:

  tdesc.cc:109:10: error: deleting object of polymorphic class type ‘target_desc’ which has non-virtual destructor might cause undefined behavior [-Werror=delete-non-virtual-dtor]

Which is caused because gdbserver's target_desc type inherits from
tdesc_element which has a virtual method, and so GCC worries that
target_desc might be used as a base class.

The solution is to declare gdbserver's target_desc class as final.
This is fine so long as we never intent to inherit from
target_desc (in gdbserver).  But if we did then we'd want to make
target_desc's destructor virtual anyway, so the error above would be
resolved, and there wouldn't be an issue.

gdb/ChangeLog:

* arch/riscv.c (riscv_tdesc_cache): Change map type.
(riscv_lookup_target_description): Return pointer out of
unique_ptr.
* target-descriptions.c (allocate_target_description): Add
comment.
(target_desc_deleter::operator()): Likewise.
* target-descriptions.h (struct target_desc_deleter): Moved to
gdbsupport/tdesc.h.
(target_desc_up): Likewise.

gdbserver/ChangeLog:

* tdesc.cc (allocate_target_description): Add header comment.
(target_desc_deleter::operator()): New function.
* tdesc.h (struct target_desc): Declare as final.

gdbsupport/ChangeLog:

* tdesc.h (struct target_desc_deleter): Moved here
from gdb/target-descriptions.h, extend comment.
(target_desc_up): Likewise.

[gdb/testsuite] Add gdb.base/valgrind-infcall-2.exp

In commit ee3c5f8968 "Fix GDB crash when registers cannot be modified", we
fix a GDB crash:
...
$ valgrind /usr/bin/sleep 10000
==31595== Memcheck, a memory error detector
==31595== Command: /usr/bin/sleep 10000
==31595==
$ gdb /usr/bin/sleep
(gdb) target remote | vgdb --pid=31595
Remote debugging using | vgdb --pid=31595
  ...
$hex in __GI___nanosleep () at nanosleep.c:27
27   return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
(gdb) p printf ("bla")
terminate called after throwing an instance of 'gdb_exception_error'
Aborted (core dumped)
...

This patch adds a test-case for it.

Unfortunately, I was not able to trigger the error condition using a regular
vgdb_start, so I've added a parameter active_at_startup, and when set to 0
this causes valgrind to be started without --vgdb-error=0.

Tested on x86_64-linux.

Tested with the commit mentioned above reverted, resulting in:
...
(gdb) p printf ("bla")^M
terminate called after throwing an instance of 'gdb_exception_error'^M
ERROR: GDB process no longer exists
GDB process exited with wait status 6152 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.base/valgrind-infcall-2.exp: do printf
...

gdb/testsuite/ChangeLog:

2020-07-17  Tom de Vries  <tdevries@suse.de>

* gdb.base/valgrind-infcall-2.c: New test.
* gdb.base/valgrind-infcall-2.exp: New file.
* lib/valgrind.exp (vgdb_start): Add and handle active_at_startup.

Use boolean literals in linux-nat.c

I noticed a couple of spots in linux-nat.c that use 0/1 where boolean
literals would be more idiomatic.  This patch makes this change.

gdb/ChangeLog
2020-07-17  Tom Tromey  <tromey@adacore.com>

* linux-nat.c (linux_nat_target::supports_non_stop)
(linux_nat_target::always_non_stop_p): Use "true".
(linux_nat_target::supports_disable_randomization): Use "true" and
"false".

[gdb/testsuite] Use MACRO_AT_{func,range}

Use dwarf assembly procs MACRO_AT_func and MACRO_AT_range in test-cases where
that's appropriate.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-17  Tom de Vries  <tdevries@suse.de>

* gdb.dlang/circular.c (found): Use found_label as label name.
* gdb.dwarf2/arr-subrange.c (main): Use main_label as label name.
* gdb.dwarf2/comp-unit-lang.c (func): Use func_label as label name.
* gdb.dlang/circular.exp: Use MACRO_AT_func and MACRO_AT_range.
* gdb.dwarf2/ada-linkage-name.exp: Same.
* gdb.dwarf2/arr-subrange.exp: Same.
* gdb.dwarf2/atomic-type.exp: Same.
* gdb.dwarf2/comp-unit-lang.exp: Same.
* gdb.dwarf2/cpp-linkage-name.exp: Same.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Same.
* gdb.dwarf2/dw2-lexical-block-bare.exp: Same.
* gdb.dwarf2/dw2-regno-invalid.exp: Same.
* gdb.dwarf2/implptr-64bit.exp: Same.
* gdb.dwarf2/imported-unit-abstract-const-value.exp: Same.
* gdb.dwarf2/imported-unit-runto-main.exp: Same.
* gdb.dwarf2/imported-unit.exp: Same.
* gdb.dwarf2/main-subprogram.exp: Same.
* gdb.dwarf2/missing-type-name.exp: Same.
* gdb.dwarf2/nonvar-access.exp: Same.
* gdb.dwarf2/struct-with-sig.exp: Same.
* gdb.dwarf2/typedef-void-finish.exp: Same.
* gdb.dwarf2/void-type.exp: Same.

[gdb/testsuite] Drop src arg of MACRO_AT_{func,range}

The dwarf assembly procs MACRO_AT_func and MACRO_AT_range have a src
parameter, which is set to $srcdir/$subdir/$srcfile in every single call.

Drop the src parameter and hardcode usage of $srcdir/$subdir/$srcfile in the
procs.

Build and reg-tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-17  Tom de Vries  <tdevries@suse.de>

* lib/dwarf.exp (Dwarf::MACRO_AT_func, Dwarf::MACRO_AT_range): Drop
src parameter.
* gdb.dlang/watch-loc.exp: Update MACRO_AT_{func,range} calls.
* gdb.dwarf2/bitfield-parent-optimized-out.exp: Same.
* gdb.dwarf2/dw2-ifort-parameter.exp: Same.
* gdb.dwarf2/dw2-opt-structptr.exp: Same.
* gdb.dwarf2/dwz.exp: Same.
* gdb.dwarf2/implptr-optimized-out.exp: Same.
* gdb.dwarf2/implref-array.exp: Same.
* gdb.dwarf2/implref-const.exp: Same.
* gdb.dwarf2/implref-global.exp: Same.
* gdb.dwarf2/implref-struct.exp: Same.
* gdb.dwarf2/info-locals-optimized-out.exp: Same.
* gdb.dwarf2/opaque-type-lookup.exp: Same.
* gdb.dwarf2/var-access.exp: Same.
* gdb.dwarf2/varval.exp: Same.
* gdb.trace/entry-values.exp: Same.

[gdb/testsuite] Remove Dwarf::extern

The file lib/dwarf.exp contains:
...
    # Declare a global label.  This is typically used to refer to
    # labels defined in other files, for example a function defined in
    # a .c file.
    proc extern {args} {
foreach name $args {
    _op .global $name
}
    }
...

The assembler directive to refer to labels defined in other files is
not .global, but .extern, and that one is ignored by gas.

Since we require gas for all dwarf assembly test-cases, remove the proc and
all it's uses.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-17  Tom de Vries  <tdevries@suse.de>

* lib/dwarf.exp (Dwarf::extern): Remove.
* gdb.compile/compile-ops.exp: Remove use of Dwarf::extern.
* gdb.dlang/circular.exp: Same.
* gdb.dwarf2/comp-unit-lang.exp: Same.
* gdb.dwarf2/dw2-ifort-parameter.exp: Same.
* gdb.dwarf2/dw2-symtab-includes.exp: Same.
* gdb.dwarf2/dwz.exp: Same.
* gdb.dwarf2/imported-unit-abstract-const-value.exp: Same.
* gdb.dwarf2/imported-unit-runto-main.exp: Same.
* gdb.dwarf2/imported-unit.exp: Same.
* gdb.dwarf2/opaque-type-lookup.exp: Same.

Automatic date update in version.in

mmix ld: move .init (and _init) first.

This both makes the section layout more similar to that of the general
default for ELF and fixes (makes true) an assumption that code and
rodata is located between _init and __etext, in
libgcc/config/mmix/crti.S.  Sadly, that's not actually true for ELF
(generally and for elf64mmix), where exception-tables and .rodata is
after _etext; I'm pondering what to do about that.

The original mmix simulator behavior is that memory magically appears
on access, initialized with 0, which is not preferable when chasing
bugs by throwing code the size of the gcc test-suite to the simulator.
The code in crti.S compatibly enables simulator machinery to identify
undefined memory and instead stopping the simulator with an error
(going to interactive mode for interactive runs).  See
http://gcc.gnu.org/legacy-ml/gcc-patches/2012-10/msg01871.html for
more, including the mmix-sim.ch "patch file".

This fixes only one error in the gcc testsuite,
gcc.c-torture/execute/pr20621-1.c with LTO, where for some reason
gcc/lto chooses to move (writable) data that is only used to read 0 to
.rodata.  An access (sufficiently far inside a block) in an
unregistered place is flagged as an invalid access.

The bpo-9m test that I had to adjust, actually exposes a wart: mmo
does not have the notion of symbol types (or sections) and the
test-case now has leading zeros at "Main" eventually leading to it
being misdiagnosed as being outside .text and .data, thus here mapped
to BFD as an absolute symbol.  The test is not intended to check the
mmo symbol-type machinery, so I'm just tweaking it to be
symbol-type-neutral for "Main".

Since you have to jump through hoops to see the problem, I don't think
this commit is worth putting on the 2.35-branch.

ld:
* scripttempt/mmo.sc: Move .init first in .text output section.
* testsuite/ld-mmix/bpo-9m.d: Adjust accordingly.

Fix POSIX-isms in gdb.base/shell.exp

Some recent tests added to gdb.base/shell.exp have been failing on
Windows host due to assumptions that the shell is a POSIX variant.  On
Windows, GDB uses CMD.EXE via the system() call to run shell commands
instead.

There seems to be no obvious CMD.EXE equivalent for "kill -2 $$" to
signal the shell process, so this patch skips those tests on Windows
host.  The second problem addressed here is that CMD.EXE only
recognizes double quotes, not single quotes; that change can be made
unconditionally since POSIX shells recognize double quotes as well.

2020-07-16  Sandra Loosemore  <sandra@codesourcery.com>

gdb/testsuite/
* gdb.base/shell.exp: Skip pipe tests dependent on sh on Windows host.
Use double quotes instead of single quotes.

gdb: fix issues with handling DWARF v5 rnglists & .dwo files.

While experimenting with GDB on DWARF 5 with split debug (dwo files),
I discovered that GDB was not reading the rnglist index
properly (it needed to be reprocessed in the same way the loclist
index does), and that there was no code for reading rnglists out of
dwo files at all.  Also, the rnglist address reading function
(dwarf2_rnglists_process) was adding the base address to all rnglist
entries, when it's only supposed to add it to the DW_RLE_offset_pair
entries (http://dwarfstd.org/doc/DWARF5.pdf, p. 53), and was not
handling several entry types.

- Added 'reprocessing' for reading rnglist index (as is done for loclist
  index).
- Added code for reading rnglists out of .dwo files.
- Added several missing rnglist forms to dwarf2_rnglists_process.
- Fixed bug that was alwayas adding base address for rnglists (only
  one form needs that).
- Updated dwarf2_rnglists_process to read rnglist out of dwo file when
  appropriate.
- Added new functions cu_debug_rnglist_section & read_rnglist_index.
- Added new testcase, dw5-rnglist-test.{cc,exp}

Special note about the new testcase:

In order for the test case to test anything meaningful, it must be
compiled with clang, not GCC.  The way to do this is as follows:

$ make check RUNTESTFLAGS="CC_FOR_TARGET=/path/to/clang CXX_FOR_TARGET=/path/to/clang++ dw5-rnglist-test.exp"

This following version of clang was used for this testing:

clang version 9.0.1-11
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Change-Id: I3053c5ddc345720b8ed81e23a88fe537ab38748d

[gdb/testsuite] Add pseudo line number program instruction: line

There's an idiom in dwarf assembly test-cases:
...
set line1 [gdb_get_line_number "line 1"]
set line2 [gdb_get_line_number "line 2"]
set line3 [gdb_get_line_number "line 3"]
  ...
            {DW_LNS_advance_line [expr $line1 - 1]}
  ...
            {DW_LNS_advance_line [expr $line2 - $line1]}
  ...
            {DW_LNS_advance_line [expr $line3 - $line2]}
...

Add a pseudo line number program instruction "line", such that we can simply
write:
...
            {line $line1}
  ...
            {line $line2}
  ...
            {line $line3}
...

Build and reg-tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-16  Tom de Vries  <tdevries@suse.de>

* lib/dwarf.exp (program): Initialize _line.
(DW_LNE_end_sequence): Reinitialize _line.
(DW_LNS_advance_line): Update _line.
(line): New proc.
* gdb.dwarf2/dw2-inline-many-frames.exp: Use line.
* gdb.dwarf2/dw2-inline-small-func.exp: Same.
* gdb.dwarf2/dw2-inline-stepping.exp: Same.
* gdb.dwarf2/dw2-is-stmt-2.exp: Same.
* gdb.dwarf2/dw2-is-stmt.exp: Same.
* gdb.dwarf2/dw2-ranges-func.exp: Same.

Automatic date update in version.in

gdb/testsuite: Update test pattern in ptype-on-functions.exp

It was pointed out that the recently added test
gdb.fortran/ptype-on-functions.exp fails on older versions of
gfortran.  This is because the ABI for passing string lengths changed
from a 4-byte to 8-byte value (on some targets).

This change is documented here:
  https://gcc.gnu.org/gcc-8/changes.html.

  Character variables longer than HUGE(0) elements are now possible on
  64-bit targets. Note that this changes the procedure call ABI for
  all procedures with character arguments on 64-bit targets, as the
  type of the hidden character length argument has changed. The hidden
  character length argument is now of type INTEGER(C_SIZE_T).

This commit just relaxes the pattern to accept any size of integer for
the string length argument.

gdb/testsuite/ChangeLog:

* gdb.fortran/ptype-on-functions.exp: Make the result pattern more
generic.

x86: Don't display eiz with no scale

Change

67 48 8b 1c 25 ef cd ab 89  mov    0x89abcdef(,%eiz,1),%rbx

to

67 48 8b 1c 25 ef cd ab 89  mov    0x89abcdef,%rbx

in AT&T syntax and

67 48 8b 1c 25 ef cd ab 89  mov    rbx,QWORD PTR [eiz*1+0x89abcdef]

to

67 48 8b 1c 25 ef cd ab 89  mov    rbx,QWORD PTR ds:0x89abcdef

in Intel syntax.

gas/

PR gas/26237
* testsuite/gas/i386/evex-no-scale-64.d: Updated.
* testsuite/gas/i386/addr32.d: Likewise.
* testsuite/gas/i386/x86-64-addr32-intel.d: Likewise.
* testsuite/gas/i386/x86-64-addr32.d: Likewise.

opcodes/

PR gas/26237
* i386-dis.c (OP_E_memory): Don't display eiz with no scale
without base nor index registers.

Fix the generation of relocs for missing build notes.

* write.c (create_note_reloc): Add desc2_size parameter.  Zero out
the addend field of REL relocations.  Store the full addend into
the note for REL relocations.

PR26239, memory leak in _bfd_dwarf2_slurp_debug_info

PR 26239
* coffgen.c (_bfd_coff_close_and_cleanup): Free dwarf2 info.

Fix an illegal memory access in the BFD library which can be triggered by attempting to parse a corrupt PE format file.

PR26240
* coffgen.c (coff_get_normalized_symtab): Fix off-by-one error in
check for aux entries that overflow the buufer.

[gdb/testsuite] Handle callq -> call disassembly change

We're currently running into:
...
FAIL: gdb.trace/entry-values.exp: disassemble bar
...

Since commit 36938cabf0 "x86: avoid attaching suffixes to unambiguous insns",
"callq" is disassembled as "call", and the test-case expects "callq".

Fix this by expecting "call" instead.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-15  Tom de Vries  <tdevries@suse.de>

* gdb.trace/entry-values.exp: Expect "call" instead of "callq" if
is_amd64_regs_target.

gdb/fortran: Handle dynamic string types when printing types

After commit:

  commit 8c2e4e0689ea244d0ed979171a3d09c9176b8175
  Date:   Sun Jul 12 22:58:51 2020 -0400

      gdb: add accessors to struct dynamic_prop

An existing bug was exposed in the Fortran type printing code.  When
GDB is asked to print the type of a function that takes a dynamic
string argument GDB will try to read the upper bound of the string.

The read of the upper bound is written as:

    if (type->bounds ()->high.kind () == PROP_UNDEFINED)
      // Treat the upper bound as unknown.
    else
      // Treat the upper bound as known and constant.

However, this is not good enough.  When printing a function type the
dynamic argument types will not have been resolved.  As a result the
dynamic property is not PROP_UNDEFINED, but nor is it constant.

By rewriting this code to specifically check for the PROP_CONST case,
and treating all other cases as the upper bound being unknown we avoid
incorrectly treating the dynamic property as being constant.

gdb/ChangeLog:

* f-typeprint.c (f_type_print_base): Allow for dynamic types not
being resolved.

gdb/testsuite/ChangeLog:

* gdb.fortran/ptype-on-functions.exp: Add more tests.
* gdb.fortran/ptype-on-functions.f90: Likewise.

x86: move putop() case labels to restore alphabetic sorting

... as far as non-fall-through behavior permits.

x86: make PUSH/POP disassembly uniform

Irrespective of their encoding the resulting output should look the
same. Therefore wire the handling of PUSH/POP with GPR operands
encoded in the main opcode byte to the same logic used for other
operands. This frees up yet another macro character.