gdb/dwarf: move cutu_reader to read.h

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

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

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

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

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

For example, the prologue for

volatile char var;

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

may be

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

instead of the code as currently generated by GAS:

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

which consumes more stack, time and code than needed.

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

Fix imm20 range check in MSP430 port of gas

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

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

gas/listing: drop forward declarations

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

gas: centralize declaration of listing_tail

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

objdump: permit disassembling multiple individual functions

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

objdump: properly disassemble successive functions of the same name

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

Fix missing int argument warning

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

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

[gdb/tdep] Support REX2 and EVEX prefix

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

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

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

Tested on x86_64-linux.

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

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

[gdb/tdep] Fix vmovdqu decoding

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

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

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

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

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

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

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

Tested on x86_64-linux.

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

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

[gdb/tdep] Make amd64_get_insn_details more regular

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

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

Tested on x86_64-linux.

[gdb/tdep] Add vzeroupper and vzeroall in amd64-insn-decode selftest

After I posted a tentative patch for PR31952, Alexander Monakov pointed out
that the patch broke instruction decoding for instructions vzeroall and
vzeroupper.

Add selftests for these two instructions in amd64-insn-decode, both using
vex2 and vex3 prefixes.

Tested on x86_64-linux.

[gdb/tdep] Add vex2_to_vex3

I noticed here [1] that the vex2 prefix is essentially a special case of the
vex3 prefix, meaning it's possible to rewrite any insn with a vex2 prefix into
an equivalent one with a vex3 prefix.

Add function vex2_to_vex3 that does precisely that, in the selftests
namespace.

Add a selftest that exercises this function.

Tested on x86_64-linux.

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

[gdb/tdep] Factor out part of fixup_riprel

Factor out the part of fixup_riprel that patches the insn, and use it in a
unit test.

Tested on x86_64-linux.

[gdb/tdep] Fix rip-relative insn handling in amd64_get_used_input_int_reg

I wanted to add a unit test for an an rip-relative amd64 insn, so I did:
...
$ gcc -fPIE hello.c
...
and used an rip-relative insn from main:
...
  4005db:       48 8d 3d 1e 00 00 00    lea    0x1e(%rip),%rdi
...

While writing the unit test, I found that amd64_get_used_input_int_reg returns
rbp as input register.

Fix this by using rip_relative_p in amd64_get_used_input_int_reg to handle
this case.

Tested on x86_64-linux.

[gdb/tdep] Factor out rip_relative_p

Factor out rip_relative_p, and rewrite it to use MODRM_MOD_FIELD and
MODRM_RM_FIELD.

No functional changes.

Tested on x86_64-linux.

[gdb/tdep] Add amd64-insn-decode selftest

Add a selftest that checks the results of amd64_get_insn_details and related
functions for two basic instructions.

Add a parameter assumptions to amd64_get_used_input_int_regs, to make sure
that this selftest:
...
  /* INSN: add %eax,(%rcx).  */
  ...
  SELF_CHECK (amd64_get_used_input_int_regs (&details, false)
      == ((1 << EAX_REG_NUM) | (1 << ECX_REG_NUM)));
...
passes because it found the "%eax" in the insn, rather than passing because of
this assumption:
...
  /* Assume RAX is used.  If not, we'd have to detect opcodes that implicitly
     use RAX.  */
  used_regs_mask |= 1 << EAX_REG_NUM;
...

Tested on x86_64-linux.

[gdb/tdep] Factor out amd64_get_used_input_int_regs

The function amd64_get_unused_input_int_reg consists of two parts:
- finding the used int registers in an insn, and
- picking an unused int register.

Factor out the first part as new function amd64_get_used_input_int_regs.

No functional changes.

Tested on x86_64-linux.

[gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 3

While reading amd64_get_unused_input_int_reg, I noticed that it avoids picking
RSP, which has to do with how the result of the only call to it is going to be
used.

Likewise for picking a register in the RAX ... RDI range.

Fix this by:
- adding an allowed_regs_mask parameter to amd64_get_unused_input_int_reg, and
- properly documenting the value of the corresponding argument in fixup_riprel.

No functional changes.

Tested on x86_64-linux.

[gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 2

I noticed that amd64_get_unused_input_int_reg uses a signed int for a bit
mask:
...
  /* 1 bit for each reg */
  int used_regs_mask = 0;
...

There's an assert:
...
  gdb_assert (used_regs_mask < 256);
...
which is meant to assert on register numbers >= 8, but if for instance
sizeof (used_regs_mask) == 4 and used_regs_mask == (1 << 31), then that is not
caught because of the signedness.

We could fix this by changing the type to unsigned int, but that only
guarantees 16 bits in the reg mask.  Intel CPUs with the APX extension support
32 int registers.

The implementation of amd64_get_unused_input_int_reg doesn't support analyzing
registers with register number >= 8 yet, but now that we're changing the type,
it seems like a good idea to anticipate this.

Fix this by using uint32_t.

Likewise, update the loop over the reg mask:
...
    for (i = 0; i < 8; ++i)
      {
if (! (used_regs_mask & (1 << i)))
  return i;
...
to handle any used_regs_mask value rather than just those for
register number < 8.

Tested on x86_64-linux.

[gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 1

While reading amd64_get_unused_input_int_reg, I noticed that it first asserts,
then throws an internal_error if no unused register can be found.

Looking at the documentation of gdbarch_displaced_step_copy_insn, it seems
that a failure can be indicated less abruptly, by returning a nullptr.

Fix this by:
- returning -1 in case of failure to find an unused register in
  amd64_get_unused_input_int_reg, and
- propagating this to amd64_displaced_step_copy_insn.

Tested on x86_64-linux.

gas: leave expression symbols alone when processing equates

PR gas/32721
In this bogus piece of code distilled from fuzzing and slightly edited:

A=%eax|%!
Y=A
Z=A
or $6,Z

the first of the equates with A on the rhs changes A's section (due to
the use of S_GET_VALUE()), from expression to register, thus yielding Y
in the expression section (and X_op being O_symbol), but Z in the
register section (and X_op being O_register with X_add_value being -1).
There shouldn't be random O_register expressions, though, for targets
setting md_register_arithmetic to false. Plus both Y and Z would better
be exchangeable.

In pseudo_set() wire handling of O_symbol expressions referencing a
symbol in the expression section to that of other stuff ending up in
this section.

Also avoid bogus O_register expressions to be created, for targets
setting md_register_arithmetic to false: S_GET_VALUE() would resolve
any arithmetic, which must not happen for such targets. To be on the
safe side for such targets, also amend resolve_register(). Correct
another earlier oversight there too (affecting at least Z80), by using
the new expr_copy() helper there as well.

Undo 46b9f07dfe79 ("PR 32721, internal error in
tc-i386.c:parse_register"), albeit without losing the simplification it
did.

v850: improve linker scripts for relocatable linking

Quite a few constructs where unconditional when they should take
$RELOCATING into account. The original observation was that output of
"ld -r" had .text start at 0x00100000.

gas: fold is_end_of_line[] into lex_type[]

... by way of introducing LEX_EOL and LEX_EOS. As a prereq convert the
remaining open-coded accesses.

The Alpha change is actually a functional one: The array slot for '!'
having been set to 1 is very unlikely to have been correct. 1 means "end
of line", when surely "end of statement" was always meant.

include: drop bout.h

gas'es obj-bout.c was dropped about 20 years ago, while bfd's bout.c was
dropped almost 7 years ago. Time for the unused header to go away, too.

rl78: drop redundant statement separator check

With the switch to the use of is_end_of_stmt() in 2dd0370c433d
("rl78: use is_whitespace()") the open-coded checking against
line_separator_chars[] can be dropped.

Z8k: use is_end_of_stmt()

... instead of open-coding it.

x86: use is_end_of_stmt()

... instead of open-coding it.

VAX: use is_end_of_stmt()

... instead of open-coding it. This also fixes two array underrun
issues, when plain char is a signed type.

TILEPro: use is_end_of_stmt()

... instead of open-coding it. Also convert a variable to plain char
(allowing to drop two casts), which is how it's actually used.

Tile-Gx: use is_end_of_stmt()

... instead of open-coding it. Also convert a variable to plain char
(allowing to drop two casts), which is how it's actually used.

C6x: use is_end_of_stmt()

... instead of open-coding it.

C54x: use is_end_of_stmt()

... instead of open-coding it.

In tic54x_stringer() this also fixes an array overrun issue: Converting
plain char to unsigned int could have yielded huge values when plain
char is a signed type.

In subsym_substitute() also convert a local variable to plain char, as
that's what it's really holding (and how it's used everywhere else).

C4x: use is_end_of_stmt()

... instead of open-coding it.

C30: use is_end_of_stmt()

... instead of open-coding it.

Sparc: use is_end_of_stmt()

... instead of open-coding it. This also fixes two array underrun
issues, when plain char is a signed type.

SH: use is_end_of_stmt()

... instead of open-coding it.

Score: use is_end_of_stmt()

... instead of open-coding it.

RISC-V: use is_end_of_stmt()

... instead of open-coding it.

pru: use is_end_of_stmt()

... instead of open-coding it.

PPC: use is_end_of_stmt()

... instead of open-coding it.

MMIX: use is_end_of_stmt()

... instead of open-coding it.

MIPS: use is_end_of_stmt()

... instead of open-coding it.

MicroBlaze: use is_end_of_stmt()

... instead of open-coding it.

M68k: use is_end_of_stmt()

... instead of open-coding it.

M68HC1x: use is_end_of_stmt()

... instead of open-coding it. With this there's no need for op_end (and
hence op_start) to be other than pointer to plain char. Which in turn
eliminates the need for several questionable casts.

IQ2000: use is_end_of_stmt()

... instead of open-coding it.

LoongArch: use is_end_of_stmt()

... instead of open-coding it.

HP-PA: use is_end_of_stmt()

... instead of open-coding it.

dlx: use is_end_of_stmt()

... instead of open-coding it.

C-Sky: use is_end_of_stmt()

... instead of open-coding it.

cris: use is_end_of_stmt()

Fix use of is_end_of_line[] directly instead of through the
is_end_of_stmt() macro.

aarch64: use is_end_of_stmt()

... instead of open-coding it.

Arm: use is_end_of_stmt()

... instead of open-coding it. This also fixes an array underrun issue:
The wrong casting to plain int could have yielded negative values when
plain char is a signed type.

Alpha: use is_end_of_stmt()

... instead of open-coding it. Note that writes to the array need to be
left alone; they can only be converted when the array is folded into
lex_type[].

Mach-O: use is_end_of_stmt()

... instead of open-coding it.

ELF: use is_end_of_stmt()

... instead of open-coding it.

{,E}COFF: use is_end_of_stmt()

... instead of open-coding it. Convert a variable's type to plain char
then as well, as that's what it's really holding (and how it's used
everywhere else).

gprof: Update PR gprof/32764 test

1. Remove gmon.out first before generating it in the configure check.
2. Make tst-gmon-gprof.out depend on the gprof binary.
3. Check that gmon.out is non-empty.
4. Don't include <sys/cdefs.h> in tst-gmon.c.

PR gprof/32764
* configure.ac: Remove gmon.out first.
* configure: Regenerated.
* testsuite/Makefile.am (tst-gmon-gprof.out): Depend on
$(GPROF).
* testsuite/Makefile.in: Regenerated.
* testsuite/tst-gmon-gprof.sh: Check that gmon.out is non-empty.
* testsuite/tst-gmon.c: Don't include <sys/cdefs.h>.

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

RISC-V: Go PLT for CALL/JUMP/RVC_JUMP if `h->plt.offset' isn't -1

I got an request about the undefined behaviors, considering the following case,

$ cat test.c
void main ()
{
  foo();
}
$ cat lib.h
void foo(void);
$ riscv64-unknown-linux-gnu-gcc test.c
riscv64-unknown-linux-gnu/bin/ld: /tmp/ccRO8fJl.o: in function `main':
test.c:(.text+0x8): undefined reference to `foo'
collect2: error: ld returned 1 exit status
$ riscv64-unknown-linux-gnu-gcc test.c -Wl,--unresolved-symbols=ignore-in-object-files
$ qemu-riscv64 a.out
Segmentation fault (core dumped)

Testing with x86 and aarch64, they won't get the segfault since they go plt
for the undefined foo symbol.  So, after applying this patch, I can get the
following too,

$ qemu-riscv64 a.out
a.out: symbol lookup error: a.out: undefined symbol: foo

The change of this patch should only affect the call behavior, which refer
to an undefined (weak) symbol, when building an dynamic executable.  I think
the pic/pie behavior won't be affected as usual.

gprof: Copy a simple test from glibc

Copy a simple gprof test from glibc to test the basic gprof functionality.

1. Tested natively on Linux/x86-64 and Linux/i686.
2. Tested for the x86_64-solaris cross target without cross-compiler.
3. Tested for the aarch64-linux-gnu cross target with cross-compiler.

PR gprof/32764
* Makefile.am (SUBDIRS): Add testsuite
* configure.ac (AC_CONFIG_FILES): Removed.
(AC_OUTPUT): Add Makefile testsuite/Makefile
po/Makefile.in:po/Make-in.
(AM_CONDITIONAL): Add NATIVE.
* Makefile.in: Regenerated.
* configure: Likewise.
* testsuite/Makefile.am: New file.
* testsuite/tst-gmon-gprof.sh: Likewise.
* testsuite/tst-gmon.c: Likewise.
* testsuite/Makefile.in: Generated.

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

Automatic date update in version.in

Re: ld: Add a test for PR ld/25237

Delete the test.  It doesn't make sense to check a linker hack for
a meaningless p_offset.

[gdb] Fix typos in NEWS

Fix typos:
...
mainenance ==> maintenance
epilgoue ==> epilogue
commnds ==> commands
readibility ==> readability
informations ==> information
throwed ==> threw
compiletime ==> compile time
namepace ==> namespace
reqired ==> required
explicity ==> explicitly
reqired ==> required
...

[gdb/python] Fix typos

Fix typos:
...
gdb/python/py-framefilter.c:749: indention ==> indentation
gdb/python/py-framefilter.c:837: indention ==> indentation
gdb/python/py-lazy-string.c:35: sting ==> string
gdb/python/py-progspace.c:119: Retun ==> Return
gdb/python/py-progspace.c:139: Retun ==> Return
...

[gdb/python] Fix typos in lib

Fix typos:
...
gdb/python/lib/gdb/disassembler.py:84: dissables ==> disables
gdb/python/lib/gdb/command/xmethods.py:40: experession ==> expression
...

[gdb/guile] Fix typos

Fix typos:
...
gdb/guile/scm-lazy-string.c:41: sting ==> string
gdb/guile/lib/gdb/iterator.scm:65: satify ==> satisfy
...

[gdb/doc] Fix typos in gdb.texinfo

Fix typos:
...
preprend -> prepend
wth -> with
Connnections -> Connections
...

[gdb/doc] Fix typos in annotate.texinfo

Fix typos:
...
Dependant ==> Dependent
...

[gdb/doc] Fix typos in python.texi

Fix typos:
...
atribute ==> attribute
...

[gdb/nat] Fix typos

Fix typos:
...
exising ==> existing
afer ==> after
...

[gdb/tui] Fix typos

Fix typos:
...
gdb/tui/tui.c:64: releated ==> related
gdb/tui/tui-io.c:50: releated ==> related
...

[gdb/cli] Fix typos

Fix typos:
...
gdb/cli/cli-utils.h:85: fuction ==> function
gdb/cli/cli-decode.c:2457: Ambigous ==> Ambiguous
...

[gdb] Fix typos in gdbarch_components.py

Fix typos in gdbarch_components.py:
...
tranformations ==> transformations
charater ==> character
Noe -> Note
...
and regenerate gdb/gdbarch-gen.h.

Update ada_add_block_renamings for compiler changes

With the hierarchical name patches to GNAT, ada_add_block_renamings
must now be updated as well -- the comment there about the supported
forms of DW_TAG_imported_declaration is no longer correct, and now
full names must sometimes be constructed during the lookup process.

Add support for hierarchical Ada names

In the near future, GNAT will start emitting DWARF names in a more
standard way -- specifically, the package structure will be indicated
by nested DW_TAG_module DIEs and a given entity will be nested in its
package and only have a simple name.

This patch changes gdb to understand this style of naming, while still
supporting the existing GNAT output.

A few special cases are needed.  I've commented them.

The name-computing code for the full DWARF reader is very complicated
-- much too complicated, in my opinion.  There are already several
bugs in bugzilla about this (search for "physname"... but there are
others as well), so I haven't filed any new ones.

When I started this project, I thought it would solve some memory
overuse issues we sometimes see from how the index-sharding code
interacts with the GNAT-specific post-pass.  However, to my surprise,
the Ada code in gdb relies on some details of symbol naming, and so
I've had to add code here to synthesize "linkage" names in some cases.
This is unfortunate, but I think can eventually be fixed; I will file
a bug to track this issue.

Add "Ada linkage" mode to cooked_index_entry::full_name

Unfortunately, due to some details of how the Ada support in gdb
currently works, the DWARF reader will still have to synthesize some
"full name" entries after the cooked index has been constructed.

You can see one particular finding related to this in:

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

This patch adds a new flag to cooked_index_entry::full_name to enable
the construction of these names.

I hope to redo this part of the Ada support eventually, so that this
code can be removed and the full-name entries simply not created.

Store new Ada entries in cooked_index_shard::m_entries

handle_gnat_encoded_entry might create synthetic cooked index entries
for Ada packages.  These aren't currently kept in m_entries, but it
seems to me that they should be, particularly because a forthcoming
GNAT will emit explicit DW_TAG_module for these names -- with this
change, the indexes will be roughly equivalent regardless of which
compiler was used.

Handle DW_TAG_module for Ada

This updates read_module_type to turn DW_TAG_module into a
TYPE_CODE_NAMESPACE when the CU represents Ada code.

Note that the GNAT that generates this isn't generally available yet
and so this shouldn't have an impact on current code.

Add "synthetic" marker for index entries

Currently, gdb will synthesize DW_TAG_module entries for Ada names.
These entries are treated specially by the index writer,

When GNAT starts emitting DW_TAG_module, the special case will be
incorrect, because there will be non-synthetic DW_TAG_module entries
in the index.

This patch arranges to mark the synthetic entries and changes the
index writer to follow.

Use DW_TAG_module for Ada

In GCC we decided to use DW_TAG_module to represent Ada packages, so
make this same decision in gdb.  This also updates tag_matches_domain
to handle this case.

Use dwarf2_full_name when computing type names

This changes a few spots in the DWARF reader to use dwarf2_full_name
when computing the name of a type.  This gives the correct name when a
type is nested in a namespace.  This oddity probably wasn't noticed
before because some of the types in question are either normally
anonymous in C++ (e.g, array type) or do not appear in a namespace
(base type).

Compare unqualified names in ada_identical_enum_types_p

With the coming changes to GNAT, gdb must compare the unqualified
names of two enum types.

Currently, GNAT will fully-qualify enumeration constant names, so for
instance one might see "enum_with_gap__lit4" as the name.

GNAT also may emit a copy of an enumeration type when a newtype is
involved.  E.g., in the arr_acc_idx_w_gap.exp test case, this can
occur for the base type of this subtype:

   type Enum_Subrange is new Enum_With_Gaps range Lit1 .. Lit3;

(Note that the base type of this subrange is anonymous.)

With some forthcoming changes to GNAT, these names will no longer be
qualified -- and because the newtype is anonymous, they can't be
identically qualified.  But, in gdb we still want "lit4" to resolve
without ambiguity in this scenario.

The fix is to change ada_identical_enum_types_p to compare unqualified
enum names.  This will work correctly with both variants of the
compiler, and with -fgnat-encodings=all as well.

Use ada_identical_enum_types_p in ada_atr_enum_rep

With the coming changes to GNAT, we may see two distinct but
equivalent enum types in the DWARF.  In this case, it's better to use
ada_identical_enum_types_p rather than types_equal when comparing
these types... something that matters when using 'Enum_Rep.

Fixes to gdb.ada/fun_overload_menu.exp

This patch applies a few fixes to gdb.ada/fun_overload_menu.exp.

It adds some comments to the source and uses this to extract line
numbers.  This is used to ensure that two otherwise-equivalent results
are in fact different, so that the test really checks that the result
is correct.

It also changes the test_menu proc to accept a list of possible
results.  This lets the test work regardless of the order in which the
menu items are presented by gdb.

Finally, like an earlier patch, it changes the test to optionally
accept unqualified names from gdb.

Allow multiple locations in homonym.exp

With some forthcoming changes to GNAT, the two Get_Value functions in
this test case will end up with the same name (with the current GNAT,
one ends up with a "__2" suffix).  This change will cause one test to
set multiple breakpoints; this patch changes the test to work with
either version of the compiler.

Fix type name in ptype-o.exp

The "Rec" type in ptype-o.exp is currently named "prog__rec" by the
compiler.  However, with my changes to GNAT, the type will no longer
have a prefix, as it is local to a procedure.

Changing this to just use "rec" works fine with the new compiler, but
then fails with older compilers.  To allow correct operation with both
compilers, this patch simply moves the type into a new package.  This
doesn't affect the meaning of the test, which is just ensuring that
ptype/o works in a certain case.

Note that the more obvious fix of just using "ptype/o rec" does not
work with the current GNAT.  I haven't investigated this but I did
file a bug to track it:

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

Allow unqualified names in Ada tests

Currently, when a type is declared in a subprogram that isn't part of
a package, gdb will give this type a qualified name.  E.g., in the
program for gdb.ada/arr_arr.exp:

    procedure Foo is
       type Array2_First is array (24 .. 26) of Integer;

gdb will name this type 'foo.array2_first'.

However, with some coming changes to GNAT (and with the remainder of
this series applied as well), this will no longer happen.  Instead,
such types will be given their local name.  IMO this makes more sense
anyway.

This patch updates most of the Ada tests to allow either form in the
spots where it matters.  Both are accepted so that the tests continue
to work with older versions of GNAT.  (A few tests are handled in
separate patches; this patch only contains the straightforward
changes.)

Fix latent crash in ada_variant_discrim_name

ada_variant_discrim_name does this:

  for (discrim_end = name + strlen (name) - 6; discrim_end != name;

If NAME is too short, this will construct an invalid pointer, perhaps
causing a crash.

This patch arranges to check the length first.

Allow for anonymous Ada enumeration types

With some forthcoming changes to GNAT, gdb might see a nameless enum
in ada_resolve_enum, causing a crash.  This patch allows an anonymous
enum type to be considered identical to a named type when the contents
are identical.

Add a quit to maint_print_all_sections

If you have many sections, "maint print sections" can take a very long
time (due to a bug).  If you happen to "c" at the pagination prompt,
this can't be interrupted.  This patch adds a QUIT to the loop to at
least allow interruption.

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

[gdbserver] Drop abbreviations in gdbserver/xtensa-xtregs.cc

In gdbserver/xtensa-xtregs.cc, there's a table:
...
const xtensa_regtable_t  xtensa_regmap_table[] = {
  /* gnum,gofs,cpofs,ofs,siz,cp, dbnum,  name */
  {   44, 176,   0,   0,  4, -1, 0x020c, "scompare1" },
  { 0 }
};
...
on which codespell triggers:
...
$ codespell --config ./gdbserver/setup.cfg gdbserver
gdbserver/xtensa-xtregs.cc:34: siz ==> size, six
...

Fix this by laying out the table in vertical fashion, and using the full field
names instead of the abbreviations ("size" instead of "siz", "offset" instead
of "ofs", etc).

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

Use 'const' in some gdbarch methods

This changes a couple of gdbarch methods to use 'const' for an
"asymbol *" parameter.  These methods shouldn't be modifying the
underlying symbol in the BFD.

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

[gdbserver] Add codespell section in setup.cfg

Add a codespell section in new config file gdbserver/setup.cfg, similar to the
one in gdbsupport/setup.cfg.

There's just one item left:
...
$ codespell --config ./gdbserver/setup.cfg gdbserver
gdbserver/xtensa-xtregs.cc:34: siz ==> size, six
...

gdb/dwarf: remove unnecessary `this->` in read.c

I like using `this->` when it's unclear that the method or field
accessed is within the current class, but when accessing a private
member prefixed with `m_`, it's unnecessary, as the prefix makes it
clear.  Remove some instances of it (some coming from the previous
patch, other pre-existing) to de-clutter the code a bit.

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

gdb/dwarf: make all fields of cutu_reader private

Make all fields of cutu_reader private, then add getters for whatever
needs to be accessed outside of cutu_reader.  This should help spot
what's used by cutu_reader itself, and what is used by others.

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

gdb/dwarf: pass dwarf2_cu instead of cutu_reader to two functions

These functions don't need to receive a cutu_reader, they only use it to
obtain the contained dwarf2_cu, so change them to accept a dwarf2_cu.
This helps reduce the creep of cutu_reader a little bit.

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

gdb/dwarf: move a bunch of DIE-reading functions to cutu_reader

With the hope of organizing things better and spotting patterns that
could lead to simplification, move all these functions to be methods of
cutu_reader.  At least, this gives a good picture of what the entry
points for DIE and attribute reading are, by looking at what methods are
public.

Right now, my vague understanding of cutu_reader is that it does 3
things:

 - it provides means to navigate and read the DIE tree, abstracting
   things like whether the real content is in a DWO file or not
 - it builds a dwarf2_cu object, for its own use but also for the use of
   the caller
 - it fills in missing details in the passed in dwarf2_per_cu

In the future, I'd like to separate those concerns.  I think that
cutu_reader could retain the first one of those concerns, while the
other two could be done by other classes or functions, perhaps using
cutu_reader under the hood.

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

gdb/dwarf: add empty lines in cutu_reader::read_cutu_die_from_dwo comment

I find it much more readable this way, with one idea per paragraph.

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