Ajdust more tests for opcodes/i386: remove trailing whitespace

git commit 202be274a4 also missed adjusting a few testsuite files.
This fixes
i686-vxworks  +FAIL: VxWorks shared library test 1
i686-vxworks  +FAIL: VxWorks executable test 1 (dynamic)

Trailing spaces in objdump -r header

git commit 202be274a4 went a little wild in removing trailing spaces
in gas/testsuite/gas/i386/{secidx.d,secrel.d}, causing
x86_64-w64-mingw32  +FAIL: i386 secrel reloc
x86_64-w64-mingw32  +FAIL: i386 secidx reloc

I could have just replaced the trailing space, but let's fix the
objdump output instead.  Touches lots of testsuite files.

Automatic date update in version.in

gdb/testsuite: fix gdb.trace/signal.exp on x86

Patch

  202be274a41a ("opcodes/i386: remove trailing whitespace from insns with zero operands")

causes this regression:

  FAIL: gdb.trace/signal.exp: find syscall insn in kill

It's because the test still expects to match a whitespace after the
instruction, which the patch mentioned above removed.  Remove the
whitespaces for the regexp.

Change-Id: Ie194273cc942bfd91332d4035f6eec55b7d3a428

gdb/manual: Introduce location specs

The current "Specify Location" section of the GDB manual starts with:

 "Several @value{GDBN} commands accept arguments that specify a location
 of your program's code."

And then, such commands are documented as taking a "location"
argument.  For example, here's a representative subset:

 @item break @var{location}
 @item clear @var{location}
 @item until @var{location}
 @item list @var{location}
 @item edit @var{location}
 @itemx info line @var{location}
 @item info macros @var{location}
 @item trace @var{location}
 @item info scope @var{location}
 @item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression}

The issue here is that "location" isn't really correct for most of
these commands.  Instead, the "location" argument is really a
placeholder that represent an umbrella term for all of the
"linespecs", "explicit location", and "address location" input
formats.  GDB parses these and then finds the actual code locations
(plural) in the program that match.  For example, a "location"
specified like "-function func" will actually match all the code
locations in the program that correspond to the address/file/lineno of
all the functions named "func" in all the loaded programs and shared
libraries of all the inferiors.  A location specified like "-function
func -label lab" matches all the addresses of C labels named "lab" in
all functions named "func".  Etc.

This means that several of the commands that claim they accept a
"location", actually end up working with multiple locations, and the
manual doesn't explain that all that well.  In some cases, the command
will work with all the resolved locations.  In other cases, the
command aborts with an error if the location specification resolves to
multiple locations in the program.  In other cases, GDB just
arbitrarily and silently picks whatever is the first resolved code
location (which sounds like should be improved).

To clarify this, I propose we use the term "Location Specification",
with shorthand "locaction spec", when we're talking about the user
input, the argument or arguments that is/are passed to commands to
instruct GDB how to find locations of interest.  This is distinct from
the actual code locations in the program, which are what GDB finds
based on the user-specified location spec.  Then use "location
specification or the shorter "location spec" thoughout instead of
"location" when we're talking about the user input.

Thus, this commit does the following:

- renames the "Specify Location" section of the manual to "Location
  Specifications".

- It then introduces the term "Location Specification", with
  corresponding shorthand "location spec", as something distinct from
  an actual code location in the program.  It explains what a concrete
  code location is.  It explains that a location specification may be
  incomplete, and that may match multiple code locations in the
  program, or no code location at all.  It gives examples.  Some
  pre-existing examples were moved from the "Set Breaks" section, and
  a few new ones that didn't exist yet were added.  I think it is
  better to have these centralized in this "Location Specification"
  section, since all the other commands that accept a location spec
  have an xref that points there.

- Goes through the manual, and where "@var{location}" was used for a
  command argument, updated it to say "@var{locspec}" instead.  At the
  same time, tweaks the description of the affected commands to
  describe what happens when the location spec resolves to more than
  one location.  Most commands just did not say anything about that.

  One command -- "maint agent -at @var{location}" -- currently says it
  accepts a "location", suggesting it can accept address and explicit
  locations too, but that's incorrect.  In reality, it only accepts
  linespecs, so fix it accordingly.

  One MI command -- "-trace-find line" -- currently says it accepts a
  "line specification", but it can accept address and explicit
  locations too, so fix it accordingly.

Special thanks goes to Eli Zaretskii for reviews and rewording
suggestions.

Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b

Move 64-bit BFD files from ALL_TARGET_OBS to ALL_64_TARGET_OBS

Doing a 32-bit build with "--enable-targets=all --disable-sim" fails to link
properly.

--

loongarch-tdep.o: In function `loongarch_gdbarch_init':
binutils-gdb/gdb/loongarch-tdep.c:443: undefined reference to `loongarch_r_normal_name'
loongarch-tdep.o: In function `loongarch_fetch_instruction':
binutils-gdb/gdb/loongarch-tdep.c:37: undefined reference to `loongarch_insn_length'
loongarch-tdep.o: In function `loongarch_scan_prologue(gdbarch*, unsigned long long, unsigned long long, frame_info*, trad_frame_cache*) [clone .isra.4]':
binutils-gdb/gdb/loongarch-tdep.c:87: undefined reference to `loongarch_insn_length'
binutils-gdb/gdb/loongarch-tdep.c:88: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:89: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:90: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:91: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:92: undefined reference to `loongarch_decode_imm'

--

Given the list of 64-bit BFD files in
opcodes/Makefile.am:TARGET64_LIBOPCODES_CFILES, it looks like GDB's
ALL_TARGET_OBS list is including files that should be included in
ALL_64_TARGET_OBS instead.

This patch accomplishes this and enables a 32-bit build with
"--enable-targets=all --disable-sim" to complete.

Moving the bpf, tilegx and loongarch files to the correct list means GDB can
find the correct disassembler function instead of finding a null pointer.

We still need the "--disable-sim" switch (or "--enable-64-bit-bfd") to
make a 32-bit build with "--enable-targets=all" complete correctly

Fix failing test for armeb-gnu-eabi

The following test fails on the armeb-gnu-eabi target:

FAIL: Unwind information for Armv8.1-M.Mainline PACBTI extension

This patch adjusts the expected output for big endian.

Use a union to avoid casts in bfd/doc/chew.c

This fixes -Wpedantic warnings in chew.c.  Conversion between function
and object pointers is not guaranteed.  They can even be different
sizes, not that we're likely to encounter build machines like that
nowadays.

PR 29194
* doc/chew.c (pcu): New union typedef.
(dict_type, pc): Use it here.  Adjust uses of pc.
(add_to_definition): Make "word" param a pcu.  Adjust all uses
of function.
(stinst_type): Delete.

use libiberty xmalloc in bfd/doc/chew.c

Catch out of memory.

* doc/chew.c: Include libibery.h.
(init_string_with_size, nextword): Replace malloc with xmalloc.
(newentry, add_to_definition): Likewise.
(catchar, catbuf): Replace realloc with xrealloc.
(add_intrinsic): Replace strdup with xstrdup.
* doc/local.mk (LIBIBERTY): Define.
(chew): Link against libiberty.
* Makefile.in: Regenerate.

Update K&R functions in bfd/doc/chew.c

* doc/chew.c: Update function definitions to ISO C, remove
now unnecessary prototypes.

Reorganise bfd/doc/chew.c a little

This also removes some unused variables, and deletes support for the
"var" keyword which isn't used and was broken.  (No means to set
variables, and add_var used push_number inconsistent with its use
elsewhere.)

* doc/chew.c: Move typedefs before variables, variables before
functions.
(die): Move earlier.
(word_type, sstack, ssp): Delete.
(dict_type): Delete var field.
(add_var): Delete.
(compile): Remove "var" support.

RISC-V: Add zhinx extension supports.

The zhinx extension is a sub-extension in zfinx, corresponding to
zfh extension but use GPRs instead of FPRs.

This patch expanded the zfh insn class define, since zfh and zhinx
use the same opcodes, thanks for Nelson's works.

changelog in V2: Add missing classes of 'zfh' and 'zhinx' in
"riscv_multi_subset_supports_ext".

bfd/ChangeLog:

        * elfxx-riscv.c (riscv_multi_subset_supports): New extensions.
        (riscv_multi_subset_supports_ext): New extensions.

gas/ChangeLog:

        * testsuite/gas/riscv/fp-zhinx-insns.d: New test.
        * testsuite/gas/riscv/fp-zhinx-insns.s: New test.

include/ChangeLog:

        * opcode/riscv.h (enum riscv_insn_class): New INSN classes.

opcodes/ChangeLog:

        * riscv-opc.c: Modify INSN_CLASS.

Automatic date update in version.in

Automatic date update in version.in

gdb/python: improve formatting of help text for user defined commands

Consider this command defined in Python (in the file test-cmd.py):

  class test_cmd (gdb.Command):
    """
    This is the first line.
      Indented second line.
    This is the third line.
    """

    def __init__ (self):
      super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE)

    def invoke (self, arg, from_tty):
      print ("In test-cmd")

  test_cmd()

Now, within a GDB session:

  (gdb) source test-cmd.py
  (gdb) help test-cmd

    This is the first line.
      Indented second line.
    This is the third line.

  (gdb)

I think there's three things wrong here:

  1. The leading blank line,
  2. The trailing blank line, and
  3. Every line is indented from the left edge slightly.

The problem of course, is that GDB is using the Python doc string
verbatim as its help text.  While the user has formatted the help text
so that it appears clear within the .py file, this means that the text
appear less well formatted when displayed in the "help" output.

The same problem can be observed for gdb.Parameter objects in their
set/show output.

In this commit I aim to improve the "help" output for commands and
parameters.

To do this I have added gdbpy_fix_doc_string_indentation, a new
function that rewrites the doc string text following the following
rules:

  1. Leading blank lines are removed,
  2. Trailing blank lines are removed, and
  3. Leading whitespace is removed in a "smart" way such that the
  relative indentation of lines is retained.

With this commit in place the above example now looks like this:

  (gdb) source ~/tmp/test-cmd.py
  (gdb) help test-cmd
  This is the first line.
    Indented second line.
  This is the third line.
  (gdb)

Which I think is much neater.  Notice that the indentation of the
second line is retained.  Any blank lines within the help text (not
leading or trailing) will be retained.

I've added a NEWS entry to note that there has been a change in
behaviour, but I didn't update the manual.  The existing manual is
suitably vague about how the doc string is used, so I think the new
behaviour is covered just as well by the existing text.

gdb: use gdb::unique_xmalloc_ptr<char> for docs in cmdpy_init

Make use of gdb::unique_xmalloc_ptr<char> to hold the documentation
string in cmdpy_init (when creating a custom GDB command in Python).
I think this is all pretty straight forward, the only slight weirdness
is the removal of the call to free toward the end of this function.

Prior to this commit, if an exception was thrown after the GDB command
was created then we would (I think) end up freeing the documentation
string even though the command would remain registered with GDB, which
would surely lead to undefined behaviour.

After this commit we release the doc string at the point that we hand
it over to the command creation routines.  If we throw _after_ the
command has been created within GDB then the doc string will be left
live.  If we throw during the command creation itself (either from
add_prefix_cmd or add_cmd) then it is up to those functions to free
the doc string (I suspect we don't, but I think in general the
commands are pretty bad at cleaning up after themselves, so I don't
think this is a huge problem).

gprofng: fix build with -mx32

gprofng/ChangeLog
2022-05-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/28983
PR gprofng/29143
* src/Experiment.cc (write_header): Fix argument for ctime.
Fix -Wformat= warnings.
* src/Dbe.cc: Likewise.
* src/DwarfLib.h: Fix [-Wsign-compare] warnings.
* src/Experiment.h: Likewise.
* src/ipc.cc: Fix -Wformat= warnings.

Automatic date update in version.in

Fix crash with "maint print arc"

Luis noticed that "maint print arc" would crash, because the command
handler did not find "show" in the command name, violating an
invariant.  This patch fixes the bug by changing the registration to
use add_basic_prefix_cmd instead.

opcodes/i386: remove trailing whitespace from insns with zero operands

While working on another patch[1] I had need to touch this code in
i386-dis.c:

  ins->obufp = ins->mnemonicendp;
  for (i = strlen (ins->obuf) + prefix_length; i < 6; i++)
    oappend (ins, " ");
  oappend (ins, " ");
  (*ins->info->fprintf_styled_func)
    (ins->info->stream, dis_style_mnemonic, "%s", ins->obuf);

What this code does is add whitespace after the instruction mnemonic
and before the instruction operands.

The problem I ran into when working on this code can be seen by
assembling this input file:

    .text
    nop
    retq

Now, when I disassemble, here's the output.  I've replaced trailing
whitespace with '_' so that the issue is clearer:

    Disassembly of section .text:

    0000000000000000 <.text>:
       0: 90                    nop
       1: c3                    retq___

Notice that there's no trailing whitespace after 'nop', but there are
three spaces after 'retq'!

What happens is that instruction mnemonics are emitted into a buffer
instr_info::obuf, then instr_info::mnemonicendp is setup to point to
the '\0' character at the end of the mnemonic.

When we emit the whitespace, this is then added starting at the
mnemonicendp position.  Lets consider 'retq', first the buffer is
setup like this:

  'r' 'e' 't' 'q' '\0'

Then we add whitespace characters at the '\0', converting the buffer
to this:

  'r' 'e' 't' 'q' ' ' ' ' ' ' '\0'

However, 'nop' is actually an alias for 'xchg %rax,%rax', so,
initially, the buffer is setup like this:

  'x' 'c' 'h' 'g' '\0'

Then in NOP_Fixup we spot that we have an instruction that is an alias
for 'nop', and adjust the buffer to this:

  'n' 'o' 'p' '\0' '\0'

The second '\0' is left over from the original buffer contents.
However, when we rewrite the buffer, we don't afjust mnemonicendp,
which still points at the second '\0' character.

Now, when we insert whitespace we get:

  'n' 'o' 'p' '\0' ' ' ' ' ' ' ' ' '\0'

Notice the whitespace is inserted after the first '\0', so, when we
print the buffer, the whitespace is not printed.

The fix for this is pretty easy, I can change NOP_Fixup to adjust
mnemonicendp, but now a bunch of tests start failing, we now produce
whitespace after the 'nop', which the tests don't expect.

So, I could update the tests to expect the whitespace....

...except I'm not a fan of trailing whitespace, so I'd really rather
not.

Turns out, I can pretty easily update the whitespace emitting code to
spot instructions that have zero operands and just not emit any
whitespace in this case.  So this is what I've done.

I've left in the fix for NOP_Fixup, I think updating mnemonicendp is
probably a good thing, though this is not really required any more.

I've then updated all the tests that I saw failing to adjust the
expected patterns to account for the change in whitespace.

[1] https://sourceware.org/pipermail/binutils/2022-April/120610.html

Replace bfd_hostptr_t with uintptr_t

bfd_hostptr_t is defined as a type large enough to hold either a long
or a pointer.  It mostly appears in the coff backend code in casts.
include/coff/internal.h struct internal_syment and union
internal_auxent have the only uses in data structures, where
comparison with include/coff/external.h and other code reveals that
the type only needs to be large enough for a 32-bit integer or a
pointer.  That should mean replacing with uintptr_t is OK.

Remove much of BFD_HOST configury

This patch removes the definition of bfd_uint64_t and bfd_int64_t as
well as most BFD_HOST_* which are now unused.

Remove use of bfd_uint64_t and similar

Requiring C99 means that uses of bfd_uint64_t can be replaced with
uint64_t, and similarly for bfd_int64_t, BFD_HOST_U_64_BIT, and
BFD_HOST_64_BIT.  This patch does that, removes #ifdef BFD_HOST_*
and tidies a few places that print 64-bit values.

gprofng: fix build with --disable-shared

gprofng/ChangeLog
2022-05-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* libcollector/configure.ac: Use AC_MSG_WARN instead of AC_MSG_ERROR
* libcollector/configure: Rebuild.

x86/Intel: allow MASM representation of embedded rounding / SAE

MASM doesn't support the separate operand form; the modifier belongs
after the instruction instead. Accept this form alongside the original
(now legacy) one. Short of having access to a MASM version to actually
check in how far "after the instruction" is a precise statement in their
documentation, allow both that and the SDM mandated form where the
modifier is on the last register operand (with a possible immediate
operand following).

Sadly the split out function, at least for the time being, needs to cast
away constness at some point, as the two callers disagree in this
regard.

Adjust some, but not all of the testcases.

x86: re-work AVX512 embedded rounding / SAE

As a preparatory step to allowing proper non-operand forms of specifying
embedded rounding / SAE, convert the internal representation to non-
operand form. While retaining properties (and in a few cases perhaps
providing more meaningful diagnostics), this means doing away with a few
hundred standalone templates, thus - as a nice side effect - reducing
memory consumption / cache occupancy.

x86/Intel: adjust representation of embedded rounding / SAE

MASM doesn't consider {sae} and alike a separate operand; it is attached
to the last register operand instead, just like spelled out by the SDM.
Make the disassembler follow this first, before also adjusting the
assembler (such that it'll be easy to see that the assembler change
doesn't alter generated code).

x86/Intel: allow MASM representation of embedded broadcast

MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
DWORD PTR) and alike are to be used there instead. Accept these forms
alongside the original (now legacy) ones.

Acceptance of the original {1to<n>} operand suffix is retained both for
backwards compatibility and to disambiguate VFPCLASSP{S,D,H} and vector
conversions with shrinking element sizes. I have no insight (yet) into
how MASM expects those to be disambiguated.

Adjust some, but not all of the testcases.

x86/Intel: adjust representation of embedded broadcast

MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
DWORD PTR) and alike are to be used there instead. Make the disassembler
follow this first, before also adjusting the assembler (such that it'll
be easy to see that the assembler change doesn't alter generated code).

For VFPCLASSP{S,D,H} and vector conversions with shrinking element sizes
the original {1to<n>} operand suffix is retained, to disambiguate
output. I have no insight (yet) into how MASM expects those to be
disambiguated.

gprofng: fix build with -mx32

gprofng/ChangeLog
2022-05-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/28983
* libcollector/libcol_util.h (__collector_getsp, __collector_getfp,
__collector_getpc): Adapt for build with -mx32
* libcollector/heaptrace.c: Fix -Wpointer-to-int-cast warnings.
* libcollector/hwprofile.h: Likewise.
* libcollector/mmaptrace.c: Likewise.
* libcollector/synctrace.c: Likewise.
* libcollector/unwind.c: Likewise.

Automatic date update in version.in

ld: cris*-elf: Default to --no-warn-rwx-segment

ld:
configure.tgt (cris-*-*, crisv32-*-* sans *-aout and *-linux): Unless
specified through the --enable-* -option, default to
--no-warn-rwx-segment.

Change-Id: I846bcd3e6762da807b17215a9fe337461ea0d710

cris: bfd: Correct default to no execstack

In the now-historical CRIS glibc port, the default stack permission
was no-exec as in "#define DEFAULT_STACK_PERMS (PF_R|PF_W)", and the
gcc port only emits the executable-stack marker when needed; when
emitting code needing it.  In other words, the binutils setting
mismatches.  It doesn't matter much, except being confusing and
defaulting to "off" is more sane.

ld:

* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Switch to 0
for cris*-*-*.

bfd:
* elf32-cris.c (elf_backend_default_execstack): Define to 0.

Change-Id: I52f37598f119b19111c7a6546c00a627fca0f396

aarch64-fbsd-nat: Move definition of debug_regs_probed under HAVE_DBREG.

This fixes the build on older FreeBSD systems without support for
hardware breakpoints/watchpoints.

gdb: Change psymbol_functions::require_partial_symbols to partial_symbols

The previous patch ensured that partial symbols are read before calling
most of the quick_function's methods.

The psymbol_functions class has the require_partial_symbols method which
serves this exact purpose, and does not need to do it anymore.

This patch renames this method to partial_symbols and makes it an accessor
which asserts that partial symbols have been read at this point.

Regression tested on x86_64-linux.

gdb: Require psymtab before calling quick_functions in objfile

The recent DWARF indexer rewrite introduced a regression when debugging
a forking program.

Here is a way to reproduce the issue (there might be other ways, but one
is enough and this one mimics the situation we encountered).  Consider a
program which forks, and the child loads a shared library and calls a
function in this shared library:

    if (fork () == 0)
      {
        void *solib = dlopen (some_solib, RTLD_NOW);
        void (*foo) () = dlsym (some_solib, "foo");
        foo ();
      }

Suppose that this program is compiled without debug info, but the shared
library it loads has debug info enabled.

When debugging such program with the following options:

  - set detach-on-fork off
  - set follow-fork-mode child

we see something like:

    (gdb) b foo
    Function "foo" not defined.
    Make breakpoint pending on future shared library load? (y or [n]) y
    Breakpoint 1 (foo) pending.
    (gdb) run
    Starting program: a.out
    [Attaching after process 19720 fork to child process 19723]
    [New inferior 2 (process 19723)]
    [Switching to process 19723]

    Thread 2.1 "a.out" hit Breakpoint 1, 0x00007ffff7fc3101 in foo () from .../libfoo.so
    (gdb) list

    Fatal signal: Segmentation fault
    ----- Backtrace -----
    0x55a278f77d76 gdb_internal_backtrace_1
            ../../gdb/bt-utils.c:122
    0x55a278f77f83 _Z22gdb_internal_backtracev
            ../../gdb/bt-utils.c:168
    0x55a27940b83b handle_fatal_signal
            ../../gdb/event-top.c:914
    0x55a27940bbb1 handle_sigsegv
            ../../gdb/event-top.c:987
    0x7effec0343bf ???
            /build/glibc-sMfBJT/glibc-2.31/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
    0x55a27924c9d3 _ZNKSt15__uniq_ptr_implI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE6_M_ptrEv
            /usr/include/c++/9/bits/unique_ptr.h:154
    0x55a279248bc9 _ZNKSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE3getEv
            /usr/include/c++/9/bits/unique_ptr.h:361
    0x55a2792ae718 _ZN27dwarf2_base_index_functions23find_last_source_symtabEP7objfile
            ../../gdb/dwarf2/read.c:3164
    0x55a279afb93e _ZN7objfile23find_last_source_symtabEv
            ../../gdb/symfile-debug.c:139
    0x55a279aa3040 _Z20select_source_symtabP6symtab
            ../../gdb/source.c:365
    0x55a279aa22a1 _Z34set_default_source_symtab_and_linev
            ../../gdb/source.c:268
    0x55a27903c44c list_command
            ../../gdb/cli/cli-cmds.c:1185
    0x55a279051233 do_simple_func
            ../../gdb/cli/cli-decode.c:95
    0x55a27905f221 _Z8cmd_funcP16cmd_list_elementPKci
            ../../gdb/cli/cli-decode.c:2514
    0x55a279c3b0ba _Z15execute_commandPKci
            ../../gdb/top.c:660
    0x55a27940a6c3 _Z15command_handlerPKc
            ../../gdb/event-top.c:598
    0x55a27940b032 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE
            ../../gdb/event-top.c:797
    0x55a279caf401 tui_command_line_handler
            ../../gdb/tui/tui-interp.c:278
    0x55a279409098 gdb_rl_callback_handler
            ../../gdb/event-top.c:230
    0x55a279ed5df2 rl_callback_read_char
            ../../../readline/readline/callback.c:281
    0x55a279408bd8 gdb_rl_callback_read_char_wrapper_noexcept
            ../../gdb/event-top.c:188
    0x55a279408de7 gdb_rl_callback_read_char_wrapper
            ../../gdb/event-top.c:205
    0x55a27940a061 _Z19stdin_event_handleriPv
            ../../gdb/event-top.c:525
    0x55a27a23771e handle_file_event
            ../../gdbsupport/event-loop.cc:574
    0x55a27a237f5f gdb_wait_for_event
            ../../gdbsupport/event-loop.cc:700
    0x55a27a235d81 _Z16gdb_do_one_eventv
            ../../gdbsupport/event-loop.cc:237
    0x55a2796c2ef0 start_event_loop
            ../../gdb/main.c:418
    0x55a2796c3217 captured_command_loop
            ../../gdb/main.c:478
    0x55a2796c717b captured_main
            ../../gdb/main.c:1340
    0x55a2796c7217 _Z8gdb_mainP18captured_main_args
            ../../gdb/main.c:1355
    0x55a278d0b381 main
            ../../gdb/gdb.c:32
    ---------------------
    A fatal error internal to GDB has been detected, further
    debugging is not possible.  GDB will now terminate.

    This is a bug, please report it.  For instructions, see:
    <https://www.gnu.org/software/gdb/bugs/>.

The first issue observed is in the message printed when hitting the
breakpoint.  It says that there was a break in the .so file as if there
was no debug info associated with it, but there is.  Later, if we try to
display the source where the execution stopped, we have a segfault.

Note that not having the debug info on the main binary is not strictly
required to encounter some issues, it only is to encounter the segfault.
If the main binary has debug information, GDB shows some source form the
main binary, unrelated to where we stopped.

The core of the issue is that GDB never loads the psymtab for the
library.  It is not loaded when we first see the .so because in case of
detach-on-fork off, follow-fork-mode child, infrun.c sets
child_inf->symfile_flags = SYMFILE_NO_READ to delay the psymtab loading
as much as possible.  If we compare to what was done to handle this
before the new indexer was activated, the psymatb construction for the
shared library was done under
psymbol_functions::expand_symtabs_matching:

    bool
    psymbol_functions::expand_symtabs_matching (...)
    {
        for (partial_symtab *ps : require_partial_symbols (objfile))
        ...
    }

The new indexer's expand_symtabs_matching callback does not have a call
to the objfile's require_partial_symbols, so if the partial symbol table
is not loaded at this point, there is no mechanism to fix this.

Instead of requiring each implementation of the quick_functions to check
that partial symbols have been read, I think it is safer to enforce this
when calling the quick functions.  The general pattern for calling the
quick functions is:

    for (auto *iter : qf)
      iter->the_actual_method_call (...)

This patch proposes to wrap the access of the `qf` field with an accessor
which ensures that partial symbols have been read before iterating:
qf_require_partial_symbols.  All calls to quick functions are updated
except:

- quick_functions::dump
- quick_functions::read_partial_symbols (from
  objfile::require_partial_symbols)
- quick_functions::can_lazily_read_symbols and quick_functions::has_symbols
  (from objfile::has_partial_symbols)

Regression tested on x86_64-gnu-linux.

Change-Id: I39a13a937fdbaae613a5cf68864b021000554546

Fix crash in new DWARF indexer

PR gdb/29128 points out a crash in the new DWARF index code.  This
happens if the aranges for a CU claims a PC, but the symtab that is
created during CU expansion does not actually contain the PC.  This
can only occur due to bad debuginfo, but at the same time, gdb should
not crash.

This patch fixes the bug and further merges some code into
dwarf2_base_index_functions.  This merger helps prevent the same issue
from arising from the other index implementations.

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

Finalize each cooked index separately

After DWARF has been scanned, the cooked index code does a
"finalization" step in a worker thread.  This step combines all the
index entries into a single master list, canonicalizes C++ names, and
splits Ada names to synthesize package names.

While this step is run in the background, gdb will wait for the
results in some situations, and it turns out that this step can be
slow.  This is PR symtab/29105.

This can be sped up by parallelizing, at a small memory cost.  Now
each index is finalized on its own, in a worker thread.  The cost
comes from name canonicalization: if a given non-canonical name is
referred to by multiple indices, there will be N canonical copies (one
per index) rather than just one.

This requires changing the users of the index to iterate over multiple
results.  However, this is easily done by introducing a new "chained
range" class.

When run on gdb itself, the memory cost seems rather low -- on my
current machine, "maint space 1" reports no change due to the patch.

For performance testing, using "maint time 1" and "file" will not show
correct results.  That approach measures "time to next prompt", but
because the patch only affects background work, this shouldn't (and
doesn't) change.  Instead, a simple way to make gdb wait for the
results is to set a breakpoint.

Before:

    $ /bin/time -f%e ~/gdb/install/bin/gdb -nx -q -batch \
        -ex 'break main' /tmp/gdb
    Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
    2.00

After:

    $ /bin/time -f%e ./gdb/gdb -nx -q -batch \
        -ex 'break main' /tmp/gdb
    Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
    0.65

Regression tested on x86-64 Fedora 34.

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

bit-rot in target before_parse function

Copy initialisation over from the elf.em before_parse.  Commit
ba951afb999 2022-05-03 changed behaviour on arm and score regarding
exec stack.  This patch restores the previous behaviour.

* emultempl/aarch64elf.em (before_parse): Init separate_code,
warn_execstack, no_warn_rwx_segments and default_execstack.
* emultempl/armelf.em (before_parse): Likewise.
* emultempl/scoreelf.em (before_parse): Likewise.
* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Return
true for arm and nacl.

 arm: avoid use of GNU builtin function in s_arm_unwind_save_mixed

Whilst reviewing Luis' proposed change to s_arm_unwind_save_mixed
yesterday I noticed that we were making use of __builting_clzl
directly within the main function, which is not guaranteed to be
portable.  Whilst studying the code further, I also realized that it
could be rewritten without using it and also reworked to remove a lot
of unnecessary iterations steps.  So this patch does that (and also
removes the source of the warning that Luis was trying to fix).
Finally, with the rewrite we can also simplify the caller of this
routine as the new version can handle all the cases directly.

* config/tc-arm.c (s_arm_unwind_save_mixed): Rewrite without
using __builtin_clzl.
(s_arm_unwind_save): Simplify logic for simple/mixed register saves.

gdb/linux-nat: xfer_memory_partial return E_IO on error

When accessing /proc/PID/mem, if pread64/pwrite64/read/write encounters
an error and return -1, linux_proc_xfer_memory_partial return
TARGET_XFER_EOF.

I think it should return TARGET_XFER_E_IO in this case.  TARGET_XFER_EOF
is returned when pread64/pwrite64/read/frite returns 0, which indicates
that the address space is gone and the whole process has exited or
execed.

This patch makes this change.

Regression tested on x86_64-linux-gnu.

Change-Id: I6030412459663b8d7933483fdda22a6c2c5d7221

gdb/testsuite: prefer gdb_test in gdb.dwarf2/calling-convention

Since ed01945057c "Make gdb_test's question non-optional if specified",
if the question and response parameters are given to gdb_test, the
framework enforces that GDB asks the question.  Before this patch, tests
needed to use gdb_test_multiple to enforce this.

This patch updates the gdb.dwarf2/calling-convention.exp testcase to use
gdb_test to check that GDB asks a question.  This replaces the more
complicated gdb_test_multiple based implementation.

Tested on x86_64-gnu-linux.

Change-Id: I7216e822ca68f2727e0450970097d74c27c432fe

bfd: Add Support for DW_FORM_strx* and DW_FORM_addrx*

ld: add --package-metadata

Generate a .note.package FDO package metadata ELF note, following
the spec: https://systemd.io/ELF_PACKAGE_METADATA/

If the jansson library is available at build time (and it is explicitly
enabled), link ld to it, and use it to validate that the input is
correct JSON, to avoid writing garbage to the file. The
configure option --enable-jansson has to be used to explicitly enable
it (error out when not found). This allows bootstrappers (or others who
are not interested) to seamlessly skip it without issues.

Automatic date update in version.in

Re: Add bionutils support for DWARF v5's DW_OP_addrx

Testsuite files belonging to commit 3ac9da49378c.

Show enabled locations with disabled breakpoint parent as "y-"

Currently, breakpoint locations that are enabled while their parent
breakpoint is disabled are displayed with "y" in the Enb colum of
"info breakpoints":

 (gdb) info breakpoints
 Num     Type           Disp Enb Address            What
 1       breakpoint     keep n   <MULTIPLE>
 1.1                         y   0x00000000000011b6 in ...
 1.2                         y   0x00000000000011c2 in ...
 1.3                         n   0x00000000000011ce in ...

Such locations won't trigger a break, so to avoid confusion, show "y-"
instead.  For example:

 (gdb) info breakpoints
 Num     Type           Disp Enb Address            What
 1       breakpoint     keep n   <MULTIPLE>
 1.1                         y-  0x00000000000011b6 in ...
 1.2                         y-  0x00000000000011c2 in ...
 1.3                         n   0x00000000000011ce in ...

The "-" sign is inspired on how the TUI represents breakpoints on the
left side of the source window, with "b-" for a disabled breakpoint.

Change-Id: I9952313743c51bf21b4b380c72360ef7d4396a09

Add bionutils support for DWARF v5's DW_OP_addrx.

gdb: Fix DUPLICATE and PATH regressions throughout

The previous patch to add -prompt/-lbl to gdb_test introduced a
regression: Before, you could specify an explicit empty message to
indicate you didn't want to PASS, like so:

  gdb_test COMMAND PATTERN ""

After said patch, gdb_test no longer distinguishes
no-message-specified vs empty-message, so tests that previously would
be silent on PASS, now started emitting PASS messages based on
COMMAND.  This in turn introduced a number of PATH/DUPLICATE
violations in the testsuite.

This commit fixes all the regressions I could see.

This patch uses the new -nopass feature introduced in the previous
commit, but tries to avoid it if possible.  Most of the patch fixes
DUPLICATE issues the usual way, of using with_test_prefix or explicit
unique messages.

See previous commit's log for more info.

In addition to looking for DUPLICATEs, I also looked for cases where
we would now end up with an empty message in gdb.sum, due to a
gdb_test being passed both no message and empty command.  E.g., this
in gdb.ada/bp_reset.exp:

 gdb_run_cmd
 gdb_test "" "Breakpoint $decimal, foo\\.nested_sub \\(\\).*"

was resulting in this in gdb.sum:

 PASS: gdb.ada/bp_reset.exp:

I fixed such cases by passing an explicit message.  We may want to
make such cases error out.

Tested on x86_64 GNU/Linux, native and native-extended-gdbserver.  I
see zero PATH cases now.  I get zero DUPLICATEs with native testing
now.  I still see some DUPLICATEs with native-extended-gdbserver, but
those were preexisting, unrelated to the gdb_test change.

Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2

Add -nopass option to gdb_test/gdb_test_multiple

The previous patch to add -prompt/-lbl to gdb_test introduced a
regression: Before, you could specify an explicit empty message to
indicate you didn't want to PASS, like so:

  gdb_test COMMAND PATTERN ""

After said patch, gdb_test no longer distinguishes
no-message-specified vs empty-message, so tests that previously would
be silent on PASS, now started emitting PASS messages based on
COMMAND.  This in turn introduced a number of PATH/DUPLICATE
violations in the testsuite.

I think that not issuing a PASS should be restricted to only a few
cases -- namely in shared routines exported by gdb.exp, which happen
to use gdb_test internally.  In tests that iterate an unknown number
of tests exercising some racy scenario.  In the latter case, if we
emit PASSes for each iteration, we run into the situation where
different testsuite runs emit a different number of PASSes.

Thus, this patch preserves the current behavior, and, instead, adds a
new "-nopass" option to gdb_test and gdb_test_no_output.  Compared to
the old way of supressing PASS with an empty message, this has the
advantage that you can specify a FAIL message that is distinct from
the command string, and, it's also more explicit.

Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2

RISC-V: Fix RV32Q conflict

This commit makes RV32 + 'Q' extension (version 2.2 or later) not
conflicting since this combination is no longer prohibited by the
specification.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_parse_check_conflicts): Remove conflict
detection that prohibits RV32Q on 'Q' version 2.2 or later.

gas/ChangeLog:

* testsuite/gas/riscv/march-fail-rv32iq.d: Removed.
* testsuite/gas/riscv/march-fail-rv32iq.l: Likewise.
* testsuite/gas/riscv/march-fail-rv32iq2p0.d: New test
showing RV32IQ fails on 'Q' extension version 2.0.
* testsuite/gas/riscv/march-fail-rv32iq2p0.l: Likewise.
* testsuite/gas/riscv/march-fail-rv32iq2.d: Likewise.
* testsuite/gas/riscv/march-fail-rv32iq-isa-2p2.d: New test
showing RV32IQ fails on ISA specification version 2.2.
* testsuite/gas/riscv/march-ok-rv32iq2p2.d: New test
showing RV32IQ succesds on 'Q' extension version 2.2.
* testsuite/gas/riscv/march-ok-rv32iq-isa-20190608.d: New test
showing RV32IQ succesds on ISA specification 20190608.

opcodes: introduce BC field; fix isel

Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB
field present in binutils sources. Also, per 1.6.2, BC has the same
semantics as BA and BB fields, so this should keep the same flags and
mask, only with the different offset.

opcodes/
        * ppc-opc.c
        (BC): Define new field, with the same definition as CRB field,
        but with the PPC_OPERAND_CR_BIT flag present.
gas/
        * testsuite/gas/ppc/476.d: Update.
        * testsuite/gas/ppc/a2.d: Update.
        * testsuite/gas/ppc/e500.d: Update.
        * testsuite/gas/ppc/power7.d: Update.

ppc: extend opindex to 16 bits

With the upcoming SVP64 extension[0] to PowerPC architecture, it became
evident that PowerPC operand indices no longer fit 8 bits. This patch
switches the underlying type to uint16_t, also introducing a special
typedef so that any future extension goes even smoother.

[0] https://libre-soc.org

include/
* opcode/ppc.h (ppc_opindex_t): New typedef.
(struct powerpc_opcode): Use it.
(PPC_OPINDEX_MAX): Define.
gas/
* write.h (struct fix): Increase size of fx_pcrel_adjust.
Reorganise.
* config/tc-ppc.c (insn_validate): Use ppc_opindex_t for operands.
(md_assemble): Likewise.
(md_apply_fix): Likewise.  Mask fx_pcrel_adjust with PPC_OPINDEX_MAX.
(ppc_setup_opcodes): Adjust opcode index assertion.
opcodes/
* ppc-dis.c (skip_optional_operands): Use ppc_opindex_t for
operand pointer.
(lookup_powerpc, lookup_prefix, lookup_vle, lookup_spe2): Likewise.
(print_insn_powerpc): Likewise.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.opt/clobbered-registers-O2.exp with clang

When running test-case gdb.opt/clobbered-registers-O2.exp with clang 12.0.1, I
get:
...
(gdb) run ^M
Starting program: clobbered-registers-O2 ^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
gen_movsd (operand0=<optimized out>, operand1=<optimized out>) at \
  clobbered-registers-O2.c:31^M
31              return *start_sequence(operand0, operand1);^M
(gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: runto: run to start_sequence
...

The problem is that the breakpoint in start_sequence doesn't trigger, because:
- the call to start_sequence in gen_movsd is optimized away, despite the
  __attribute__((noinline)), so the actual function start_sequence doesn't get
  called, and
- the debug info doesn't contain inlined function info, so there's only one
  breakpoint location.

Adding noclone and noipa alongside the noinline attribute doesn't fix this.

Adding the clang-specific attribute optnone in start_sequence does, but since
it inhibits all optimization, that's not a preferred solution in a gdb.opt
test-case, and it would work only for clang and not other compilers that
possibly have the same issue.

Fix this by moving functions start_sequence and gen_movsd into their own
files, as a way of trying harder to enforce noinline/noipa/noclone.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.opt/clobbered-registers-O2.exp with gcc-12

When running test-case gdb.opt/clobbered-registers-O2.exp with gcc-12, I run
into:
...
(gdb) PASS: gdb.opt/clobbered-registers-O2.exp: backtracing
print operand0^M
$1 = (unsigned int *) 0x7fffffffd070^M
(gdb) print *operand0^M
$2 = 4195541^M
(gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: print operand0
...

The problem is that starting gcc-12, the assignments to x and y in main are
optimized away:
...
int main(void)
{
  unsigned x, y;

  x = 13;
  y = 14;
  return (int)gen_movsd (&x, &y);
...

Fix this by making x and y volatile.

Note that the test-case intends to check the handling of debug info for
optimized code in function gen_movsd, so inhibiting optimization in main
doesn't interfere with that.

Tested on x86_64-linux.

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

gdb: LoongArch: Define LOONGARCH_LINUX_NUM_GREGSET as 45

LOONGARCH_LINUX_NUM_GREGSET should be defined as 45 (32 + 1 + 1 + 11)
due to reserved 11 for extension in glibc, otherwise when execute:

  make check-gdb TESTS="gdb.base/corefile.exp"

there exists the following failed testcase:

  (gdb) core-file /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile.core
  [New LWP 7742]
  warning: Unexpected size of section `.reg/7742' in core file.
  Core was generated by `/home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile'.
  Program terminated with signal SIGABRT, Aborted.
  warning: Unexpected size of section `.reg/7742' in core file.
  #0  0x000000fff76f4e24 in raise () from /lib/loongarch64-linux-gnu/libc.so.6
  (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free

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

AArch64: add support for DFP (Decimal Floating point)

This small patch adds support for TYPE_CODE_DECFLOAT in
aapcs_is_vfp_call_or_return_candidate_1 and pass_in_v_vfp_candidate,
so that GDB for AArch64 knows how to pass DFP parameters and how to
read DFP results when calling a function.

Tested on aarch64-linux-gnu, with a GCC with DFP support in the PATH,
all of GDB's DFP tests pass.

Merge config/ changes from GCC, to enable DFP on AArch64

2022-04-28  Christophe Lyon  <christophe.lyon@arm.com>

config/
* dfp.m4 (enable_decimal_float): Enable BID for AArch64.

libdecnumber/
* configure: Regenerate.

PR29171, invalid read causing SIGSEGV

The fix here is to pass "section" down to read_and_display_attr_value.
The test in read_and_display_attr_value is a little bit of hardening.

PR 29171
* dwarf.c (display_debug_macro, display_debug_names): Pass section
to read_and_display_attr_value2.
(read_and_display_attr_value): Don't attempt to check for .dwo
section name when section is NULL.

PR29170, divide by zero displaying fuzzed .debug_names

PR 29170
* dwarf.c (display_debug_names): Don't attempt to display bucket
clashes when bucket count is zero.

PR29169, invalid read displaying fuzzed .gdb_index

PR 29169
* dwarf.c (display_gdb_index): Combine sanity checks.  Calculate
element counts, not word counts.

Automatic date update in version.in

Tweak the std::hash<> specialization for aarch64_features.

Move the specialization into an explicit std namespace to workaround a
bug in older compilers.  GCC 6.4.1 at least fails to compile the previous
version with the following error:

gdb/arch/aarch64.h:48:13: error: specialization of 'template<class _Tp> struct std::hash' in different namespace [-fpermissive]

  struct std::hash<aarch64_features>

Fix loongarch_iterate_over_regset_sections for non-native targets.

Define a constant for the number of registers stored in a register set
and use this with register_size to compute the size of the
general-purpose register set in core dumps.

This also fixes the build on hosts such as FreeBSD that do not define
an elf_gregset_t type.

gdb: LoongArch: Implement the iterate_over_regset_sections gdbarch method

When execute the following command on LoongArch:

  make check-gdb TESTS="gdb.base/auxv.exp"

there exist the following unsupported and failed testcases:

  UNSUPPORTED: gdb.base/auxv.exp: gcore
  FAIL: gdb.base/auxv.exp: load core file for info auxv on native core dump
  FAIL: gdb.base/auxv.exp: info auxv on native core dump
  FAIL: gdb.base/auxv.exp: matching auxv data from live and core
  UNSUPPORTED: gdb.base/auxv.exp: info auxv on gcore-created dump
  UNSUPPORTED: gdb.base/auxv.exp: matching auxv data from live and gcore

we can see the following messages in gdb/testsuite/gdb.log:

  gcore /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/auxv/auxv.gcore
  Target does not support core file generation.
  (gdb) UNSUPPORTED: gdb.base/auxv.exp: gcore

In order to fix the above issues, implement the iterate_over_regset_sections
gdbarch method to iterate over core file register note sections on LoongArch.

By the way, with this patch, the failed testcases in gdb.base/corefile.exp
and gdb.base/gcore.exp can also be fixed.

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

[gdb/testsuite] Fix -prompt handling in gdb_test

With check-read1 I run into:
...
   [infrun] maybe_set_commit_resumed_all_targets: not requesting
commit-resumed for target native, no resumed threads^M
(gdb) FAIL: gdb.base/ui-redirect.exp: debugging: continue
[infrun] fetch_inferior_event: exit^M
...

The problem is that proc gdb_test doesn't pass down the -prompt option to proc
gdb_test_multiple, due to a typo making this lappend without effect:
...
    set opts {}
    lappend "-prompt $prompt"
...

Fix this by actually appending to opts.

Tested on x86_64-linux.

[gdbsupport] Fix UB in print-utils.cc:int_string

When building gdb with -fsanitize=undefined, I run into:
...
(gdb) PASS: gdb.ada/access_to_packed_array.exp: set logging enabled on
maint print symbols^M
print-utils.cc:281:29:runtime error: negation of -9223372036854775808 cannot \
  be represented in type 'long int'; cast to an unsigned type to negate this \
  value to itself
(gdb) FAIL: gdb.ada/access_to_packed_array.exp: maint print symbols
...

By running in a debug session, we find that this happens during printing of:
...
   typedef system.storage_elements.storage_offset: \
     range -9223372036854775808 .. 9223372036854775807;
...
Possibly, an ada test-case could be created that exercises this in isolation.

The problem is here in int_string, where we negate a val with type LONGEST:
...
         return decimal2str ("-", -val, width);
...

Fix this by, as recommend, using "-(ULONGEST)val" instead.

Tested on x86_64-linux.

[gdb/exp] Fix UB in scalar_binop

When building gdb with -fsanitize=undefined, I run into:
...
$ gdb -q -batch -ex "p -(-0x7fffffffffffffff - 1)"
src/gdb/valarith.c:1385:10: runtime error: signed integer overflow: \
  0 - -9223372036854775808 cannot be represented in type 'long int'
$1 = -9223372036854775808
...

Fix this by performing the substraction in scalar_binop using unsigned types.

Tested on x86_64-linux.

[gdb/ada] Fix gdb.ada/dynamic-iface.exp with gcc 7

This test in test-case gdb.ada/dynamic-iface.exp passes with gcc 8:
...
(gdb) print obj^M
$1 = (n => 3, a => "ABC", value => 93)^M
(gdb) PASS: gdb.ada/dynamic-iface.exp: print local as interface
...
but fails with gcc 7:
...
(gdb) print obj^M
$1 = ()^M
(gdb) FAIL: gdb.ada/dynamic-iface.exp: print local as interface
...

More concretely, we have trouble finding the type of obj.  With gcc 8:
...
$ gdb -q -batch main -ex "b concrete.adb:20" -ex run -ex "ptype obj"
  ...
type = <ref> new concrete.intermediate with record
    value: integer;
end record
...
and with gcc 7:
...
type = <ref> tagged record null; end record
...

The translation from tagged type to "full view" type happens in
ada_tag_value_at_base_address, where we hit this code:
...
  /* Storage_Offset'Last is used to indicate that a dynamic offset to
     top is used.  In this situation the offset is stored just after
     the tag, in the object itself.  */
  if (offset_to_top == last)
    {
      struct value *tem = value_addr (tag);
      tem = value_ptradd (tem, 1);
      tem = value_cast (ptr_type, tem);
      offset_to_top = value_as_long (value_ind (tem));
    }
...
resulting in an offset_to_top for gcc 8:
...
(gdb) p offset_to_top
$1 = -16
...
and for gcc 7:
...
(gdb) p offset_to_top
$1 = 16
...

The difference is expected, it bisects to gcc commit d0567dc0dbf ("[multiple
changes]") which mentions this change.

There's some code right after the code quoted above that deals with this
change:
...
  else if (offset_to_top > 0)
    {
      /* OFFSET_TO_TOP used to be a positive value to be subtracted
 from the base address.  This was however incompatible with
 C++ dispatch table: C++ uses a *negative* value to *add*
 to the base address.  Ada's convention has therefore been
 changed in GNAT 19.0w 20171023: since then, C++ and Ada
 use the same convention.  Here, we support both cases by
 checking the sign of OFFSET_TO_TOP.  */
      offset_to_top = -offset_to_top;
    }
...
but it's not activated because of the 'else'.

Fix this by removing the 'else'.

Tested on x86_64-linux, with gcc 7.5.0.

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

ld: use definitions in generate_reloc rather than raw literals

[gdb/testsuite] Skip language auto in gdb.base/parse_number.exp

In test-case gdb.base/parse_number.exp, we skip architecture auto in the
$supported_archs loop, to prevent duplicate testing.

Likewise, skip language auto and its alias local in the $::all_languages
loop.  This reduces the number of tests from 17744 to 15572.

Tested on x86_64-linux, with a build with --enable-targets=all.

Automatic date update in version.in

Accept functions with DW_AT_linkage_name present

Currently GDB is not able to debug (Binary generated with Clang) variables
present in shared/private clause of OpenMP Task construct. Please note that
LLVM debugger LLDB is able to debug.

In case of OpenMP, compilers generate artificial functions which are not
present in actual program. This is done to apply parallelism to block of
code.

For non-artifical functions, DW_AT_name attribute should contains the name
exactly as present in actual program.
(Ref# http://wiki.dwarfstd.org/index.php?title=Best_Practices)
Since artificial functions are not present in actual program they not having
DW_AT_name and having DW_AT_linkage_name instead should be fine.

Currently GDB is invalidating any function not havnig DW_AT_name which is why
it is not able to debug OpenMP (Clang).

It should be fair to fallback to check DW_AT_linkage_name in case DW_AT_name
is absent.

Automatic date update in version.in

Automatic date update in version.in

Rename base_breakpoint -> code_breakpoint

Even after the previous patches reworking the inheritance of several
breakpoint types, the present breakpoint hierarchy looks a bit
surprising, as we have "breakpoint" as the superclass, and then
"base_breakpoint" inherits from "breakpoint".  Like so, simplified:

   breakpoint
       base_breakpoint
          ordinary_breakpoint
  internal_breakpoint
  momentary_breakpoint
  ada_catchpoint
  exception_catchpoint
       tracepoint
       watchpoint
       catchpoint
  exec_catchpoint
  ...

The surprising part to me is having "base_breakpoint" being a subclass
of "breakpoint".  I'm just refering to naming here -- I mean, you'd
expect that it would be the top level baseclass that would be called
"base".

Just flipping the names of breakpoint and base_breakpoint around
wouldn't be super great for us, IMO, given we think of every type of
*point as a breakpoint at the user visible level.  E.g., "info
breakpoints" shows watchpoints, tracepoints, etc.  So it makes to call
the top level class breakpoint.

Instead, I propose renaming base_breakpoint to code_breakpoint.  The
previous patches made sure that all code breakpoints inherit from
base_breakpoint, so it's fitting.  Also, "code breakpoint" contrasts
nicely with a watchpoint also being typically known as a "data
breakpoint".

After this commit, the resulting hierarchy looks like:

   breakpoint
       code_breakpoint
          ordinary_breakpoint
  internal_breakpoint
  momentary_breakpoint
  ada_catchpoint
  exception_catchpoint
       tracepoint
       watchpoint
       catchpoint
  exec_catchpoint
  ...

... which makes a lot more sense to me.

I've left this patch as last in the series in case people want to
bikeshed on the naming.

"code" has a nice property that it's exactly as many letters as
"base", so this patch didn't require any reindentation.  :-)

Change-Id: Id8dc06683a69fad80d88e674f65e826d6a4e3f66

Test "set multiple-symbols on" creating multiple breakpoints

To look for code paths that lead to create_breakpoints_sal creating
multiple breakpoints, I ran the whole testsuite with this hack:

  --- a/gdb/breakpoint.c
  +++ b/gdb/breakpoint.c
  @@ -8377,8 +8377,7 @@ create_breakpoints_sal (struct gdbarch *gdbarch,
  int from_tty,
  int enabled, int internal, unsigned flags)
   {
  -  if (canonical->pre_expanded)
  -    gdb_assert (canonical->lsals.size () == 1);
  +  gdb_assert (canonical->lsals.size () == 1);

surprisingly, the assert never failed...

The way to get to create_breakpoints_sal with multiple lsals is to use
"set multiple-symbols ask" and then select multiple options from the
menu, like so:

 (gdb) set multiple-symbols ask
 (gdb) b overload1arg
 [0] cancel
 [1] all
 [2] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg()
 [3] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(char)
 [4] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(double)
 [5] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(float)
 [6] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(int)
 [7] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(long)
 [8] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(short)
 [9] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(signed char)
 [10] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned char)
 [11] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned int)
 [12] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned long)
 [13] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned short)
 > 2-3
 Breakpoint 2 at 0x1532: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 107.
 Breakpoint 3 at 0x154b: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 110.
 warning: Multiple breakpoints were set.
 Use the "delete" command to delete unwanted breakpoints.

... which would trigger the assert.

This commit makes gdb.cp/ovldbreak.exp test this scenario.  It does
that by making set_bp_overloaded take a list of expected created
breakpoints rather than just one breakpoint.  It converts the
procedure to use gdb_test_multiple instead of send_gdb/gdb_expect
along the way.

Change-Id: Id87d1e08feb6670440d926f5344e5081f5e37c8e

Make sure momentary breakpoints are always thread-specific

This adds a new ctor to momentary_breakpoints with a few parameters
that are always necessary for momentary breakpoints.

In particular, I noticed that set_std_terminate_breakpoint doesn't
make the breakpoint be thread specific, which looks like a bug to me.

The point of that breakpoint is to intercept std::terminate calls that
happen as result of the called thread throwing an exception that won't
be caught by the dummy frame.  If some other thread calls
std::terminate, IMO, it's no different from some other thread calling
exit/_exit, for example.

Change-Id: Ifc5ff4a6d6e58b8c4854d00b86725382d38a1a02

Momentary breakpoints should have no breakpoint number

Momentary breakpoints have no breakpoint number, their breakpoint
number should be always 0, to avoid constantly incrementing (or
decrementing) the internal breakpoint count.

Indeed, set_momentary_breakpoint installs the created breakpoint
without a number.

However, momentary_breakpoint_from_master incorrectly gives an
internal breakpoint number to the new breakpoint.  This commit fixes
that.

Change-Id: Iedcae5432cdf232db9e9a6e1a646d358abd34f95

Add/tweak intro comments of struct breakpoint and several subclasses

This tweaks the intro comments of the following classes:

 internal_breakpoint
 momentary_breakpoint
 breakpoint
 base_breakpoint
 watchpoint
 catchpoint

Change-Id: If6b31f51ebbb81705fbe5b8435f60ab2c88a98c8

Move add_location(sal) to base_breakpoint

After the previous patches, only base_breakpoint subclasses use
add_location(sal), so we can move it to base_breakpoint (a.k.a. base
class for code breakpoints).

This requires a few casts here and there, but always at spots where
you can see from context what the breakpoint's type actually is.

I inlined new_single_step_breakpoint into its only caller exactly for
this reason.

I did try to propagate more use of base_breakpoint to avoid casts, but
that turned out unwieldy for this patch.

Change-Id: I49d959322b0fdce5a88a216bb44730fc5dd7c6f8

Move common bits of catchpoint/exception_catchpoint to breakpoint's ctor

Move common bits of catchpoint and exception_catchpoint to
breakpoint's ctor, to avoid duplicating code.

Change-Id: I3a115180f4d496426522f1d89a3875026aea3cf2

Make catchpoint inherit breakpoint, eliminate init_raw_breakpoint

struct catchpoint's ctor currently calls init_raw_breakpoint, which is
a bit weird, as that ctor-like function takes a sal argument, but
catchpoints don't have code locations.

Instead, make struct catchpoint's ctor add the catchpoint's dummy
location using add_dummy_location.

init_raw_breakpoint uses add_location under the hood, and with a dummy
sal it would ultimately use the breakpoint's gdbarch for the
location's gdbarch, so replace the references to loc->gdbarch (which
is now NULL) in syscall_catchpoint to references to the catchpoint's
gdbarch.

struct catchpoint's ctor was the last user of init_raw_breakpoint, so
this commit eliminates the latter.

Since catchpoint locations aren't code locations, make struct
catchpoint inherit struct breakpoint instead of base_breakpoint.  This
let's us delete the tracepoint::re_set override too.

Change-Id: Ib428bf71efb09fdaf399c56e4372b0f41d9c5869

Make breakpoint_address_bits look at the location kind

Software watchpoints allocate a special dummy location using
software_watchpoint_add_no_memory_location, and then
breakpoint_address_bits checks whether the location is that special
location to decide whether the location has a meaninful address to
print.

Introduce a new bp_loc_software_watchpoint location kind, and make
breakpoint_address_bits use bl_address_is_meaningful instead, which
returns false for bp_loc_other, which is in accordance with we
document for bp_location::address:

  /* (... snip ...)  Valid for all types except
     bp_loc_other.  */
  CORE_ADDR address = 0;

Rename software_watchpoint_add_no_memory_location to
add_dummy_location, and simplify it.  This will be used by catchpoints
too in a following patch.

Note that neither "info breakpoints" nor "maint info breakpoints"
actually prints the addresses of watchpoints, but I think it would be
useful to do so in "maint info breakpoints".  This approach let's us
implement that in the future.

Change-Id: I50e398f66ef618c31ffa662da755eaba6295aed7

Make exception_catchpoint inherit base_breakpoint instead of catchpoint

exception_catchpoint is really a code breakpoint, with locations set
by sals, re-set like other code breakpoints, etc., so make it inherit
base_breakpoint.

This adds a bit of duplicated code to exception_catchpoint's ctor
(copied from struct catchpoint's ctor), but it will be eliminated in a
following patch.

Change-Id: I9fbb2927491120e9744a4f5e5cb5e6870ca07009

Refactor momentary breakpoints, eliminate set_raw_breakpoint{,_without_location}

This commit makes set_momentary_breakpoint allocate the breakpoint
type without relying on set_raw_breakpoint, and similarly,
momentary_breakpoint_from_master not rely on
set_raw_breakpoint_without_location.  This will let us convert
init_raw_breakpoint to a ctor in a following patch.

The comment about set_raw_breakpoint being used in gdbtk sources is
stale.  gdbtk no longer uses it.

Change-Id: Ibbf77731e4b22e18ccebc1b5799bbec0aff28c8a

Refactor set_internal_breakpoint / internal_breakpoint ctor

This moves initialization of internal_breakpoint's breakpoint fields
to internal_breakpoint's ctor, and stops using
new_breakpoint_from_type for internal_breakpoint breakpoints.

Change-Id: I898ed0565f47cb00e4429f1c6446e6f9a385a78d

Convert init_ada_exception_catchpoint to a ctor

Currently, init_ada_exception_catchpoint is defined in breakpoint.c, I
presume so it can call the static describe_other_breakpoints function.
I think this is a dependency inversion.
init_ada_exception_catchpoint, being code specific to Ada catchpoints,
should be in ada-lang.c, and describe_other_breakpoints, a core
function, should be exported.

And then, we can convert init_ada_exception_catchpoint to an
ada_catchpoint ctor.

Change-Id: I07695572dabc5a75d3d3740fd9b95db1529406a1

Make ada_catchpoint_location's owner ctor parameter be ada_catchpoint

This commit changes ada_catchpoint_location's ctor from:

  ada_catchpoint_location (breakpoint *owner)

to:

  ada_catchpoint_location (ada_catchpoint *owner)

just to make the code better document intention.

To do this, we need to move the ada_catchpoint_location type's
definition to after ada_catchpoint is defined, otherwise the compiler
doesn't know that ada_catchpoint is convertible to struct breakpoint.

Change-Id: Id908b2e38bde30b262381e00c5637adb9bf0129d

init_breakpoint_sal -> base_breakpoint::base_breakpoint

This converts init_breakpoint_sal to a base_breakpoint constructor.

It removes a use of init_raw_breakpoint.

To avoid manually adding a bunch of parameters to
new_breakpoint_from_type, and manually passing them down to the
constructors of a number of different base_breakpoint subclasses, make
new_breakpoint_from_type a variable template function.

Change-Id: I4cc24133ac4c292f547289ec782fc78e5bbe2510

Remove "internal" parameter from a couple functions

None of init_breakpoint_sal, create_breakpoint_sal, and
strace_marker_create_breakpoints_sal make use of their "internal"
parameter, so remove it.

Change-Id: I943f3bb44717ade7a7b7547edf8f3ff3c37da435

More breakpoint_ops parameter elimination

Remove breakpoint_ops parameters from a few functions that don't need
it.

Change-Id: Ifcf5e1cc688184acbf5e19b8ea60138ebe63cf28

Make a few functions work with base_breakpoint instead of breakpoint

This makes tracepoints inherit from base_breakpoint, since their
locations are code locations.  If we do that, then we can eliminate
tracepoint::re_set and tracepoint::decode_location, as they are doing
the same as the base_breakpoint implementations.

With this, all breakpoint types created by new_breakpoint_from_type
are code breakpoints, i.e., base_breakpoint subclasses, and thus we
can make it return a base_breakpoint pointer.

Finally, init_breakpoint_sal can take a base_breakpoint pointer as
"self" pointer too.  This will let us convert this function to a
base_breakpoint ctor in a following patch.

Change-Id: I3a4073ff1a4c865f525588095c18dc42b744cb54

ranged_breakpoint: move initialization to ctor

Move initialization of ranged_breakpoint's fields to its ctor.

Change-Id: If7b842861f3cc6a429ea329d45598b5852283ba3

ranged_breakpoint: use install_breakpoint

This commit replaces a chunk of code in break_range_command by an
equivalent call to install_breakpoint.

Change-Id: I31c06cabd36f5be91740aab029265f678aa78e35

ranged_breakpoint: don't use init_raw_breakpoint

ranged_breakpoint's ctor already sets the breakpoint's type to
bp_hardware_breakpoint.

Since this is a "regular" breakpoint, b->pspace should remain NULL.

Thus, the only thing init_raw_breakpoint is needed for, is to add the
breakpoint's location.  Do that directly.

Change-Id: I1505de94c3919881c2b300437e2c0da9b05f76bd

Make structs breakpoint/base_breakpoint/catchpoint be abstract

You should never instanciate these types directly.

Change-Id: I8086c74c415eadbd44924bb0ef20f34b5b97ee6f

add_location_to_breakpoint -> breakpoint::add_location

Make add_location_to_breakpoint be a method of struct breakpoint.

A patch later in the series will move this to base_breakpoint, but for
now, it needs to be here.

Change-Id: I5bdc2ec1a7c2d66f26f51bf6f6adc8384a90b129

PowerPC: Make test gdb.arch/powerpc-power10.exp Endian independent.

The .quad statement stores the 64-bit hex value in Endian order.  When used
to store a 64-bit prefix instructions on Big Endian (BE) systems, the .quad
statement stores the 32-bit suffix followed by the 32-bit prefix rather
than the expected order of prefix word followed by the suffix word.  GDB
fetches 32-bits at a time when disassembling instructions.  The disassembly
on BE gets messed up since GDB fetches the suffix first and interprets it
as a word instruction not a prefixed instruction.  When gdb fetches the
prefix part of the instruction, following the initial suffix word, gdb
associates the prefix word incorrectly with the following 32-bits as the
suffix for the instruction when in fact it is the following instruction.

For example on BE we have two prefixed instructions stored using the
.quad statement as follows:

 addr    word                GDB action
---------------------------------------------
  1      suffix inst A   <- GDB interprets as a word instruction
  2      prefix inst A   <- GDB uses this prefix with

  3      suffix inst B   <- this suffix rather than the suffix at addr 1.
  4      prefix inst B

This patch changes the .quad statement into two .longs to explicitly store
the prefix followed by the suffix of the instruction.

The patch rearranges the instructions to put all of the word instructions
together followed by the prefix instructions for clarity.

The patch has been tested on Power 10 and Power 7 BE and LE to verify
the change works as expected.