make objcopy fail if it is asked to redefine symbols in an object file containing LTO information.

* objcopy.c (filter_symbols): Fail if attempting to dredefine
symbols in an LTO object file.

[gdb/testsuite] Fix full buffer in gdb.rust/dwindex.exp

On ubuntu 18.04.5, I run into:
...
(gdb) mt print objfiles dwindex^M
^M
Object file build/gdb/testsuite/outputs/gdb.rust/dwindex/dwindex:  \
  Objfile at 0x55dab0b87a50, bfd at 0x55dab0b0cfa0, 1095 minsyms^M
^M
Psymtabs:^M
vendor/compiler_builtins/src/int/specialized_div_rem/mod.rs at 0x55dab0db0720^M
  ...
library/std/src/sys/unix/stdio.rs at 0x55dab0d96320^M
ERROR: internal buffer is full.
UNRESOLVED: gdb.rust/dwindex.exp: check if index present
...

Fix this by using -lbl in proc ensure_gdb_index.

Tested on x86_64-linux.

Add Solaris specific ELF note processing

Add elfcore_grok_solaris_note function that enables to
obtain process status, register values, and program info
from Solaris's core files.

bfd/
* elf.c (elfcore_grok_solaris_note): Solaris specific ELF
note parser. Better GDB's coredump analysis on Solaris...
(elfcore_grok_solaris_note_impl): New function.
(elfcore_grok_solaris_prstatus): New function.
(elfcore_grok_solaris_info): New function.
(elfcore_grok_solaris_lwpstatus): New function.
(elf_parse_notes): Added "CORE" groker element.
include/
* elf/common.h: Add note segment constants for core files on
Solaris systems.

Add support to readelf for reading OpenBSD ELF core notes.

* readelf.c (get_openbsd_elfcore_note_type): New function.
(process_note): Add support for OpenBSD core notes.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/break-interp.exp for ld.so without debug

When running test-case gdb.base/break-interp.exp on openSUSE Leap 42.3, I get:
...
(gdb) info addr dl_main^M
Symbol "dl_main" is at 0x1750 in a file compiled without debugging.^M
(gdb) FAIL: gdb.base/break-interp.exp: info addr dl_main
...
while the regexp expects "Symbol \"dl_main\" is a function at address $hex\\."

Fix this by also accepting this variant.

Tested on x86_64-linux.

Add a testcase for PR binutils/27202

PR binutils/27202
* testsuite/gas/elf/dwarf-5-loc0.d: New file.
* testsuite/gas/elf/dwarf-5-loc0.s: Likewise.
* testsuite/gas/elf/elf.exp: Run dwarf-5-loc0.

Fix gdb.multi/multi-term-settings.exp race

The gdb.multi/multi-term-settings.exp testcase sometimes fails like so:

 Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.multi/multi-term-settings.exp ...
 FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT)

It's easier to reproduce if you stress the machine at the same time, like e.g.:

  $ stress -c 24

Looking at gdb.log, we see:

 (gdb) attach 60422
 Attaching to program: build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings, process 60422
 [New Thread 60422.60422]
 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
 Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so...
 Reading symbols from /lib64/ld-linux-x86-64.so.2...
 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
 0x00007f2fc2485334 in __GI___clock_nanosleep (clock_id=<optimized out>, clock_id@entry <mailto:clock_id@entry>=0, flags=flags@entry <mailto:flags@entry>=0, req=req@entry <mailto:req@entry>=0x7ffe23126940, rem=rem@entry <mailto:rem@entry>=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
 78 ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory.
 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: inf2: attach
 set schedule-multiple on
 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: set schedule-multiple on
 info inferiors
   Num  Description       Connection                         Executable
   1    process 60404     1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings
 * 2    process 60422     1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings
 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: info inferiors
 pid=60422, count=46
 pid=60422, count=47
 pid=60422, count=48
 pid=60422, count=49
 pid=60422, count=50
 pid=60422, count=51
 pid=60422, count=52
 pid=60422, count=53
 pid=60422, count=54
 pid=60422, count=55
 pid=60422, count=56
 pid=60422, count=57
 pid=60422, count=58
 pid=60422, count=59
 pid=60422, count=60
 pid=60422, count=61
 pid=60422, count=62
 pid=60422, count=63
 pid=60422, count=64
 pid=60422, count=65
 pid=60422, count=66
 pid=60422, count=67
 pid=60422, count=68
 pid=60422, count=69
 pid=60404, count=54
 pid=60404, count=55
 pid=60404, count=56
 pid=60404, count=57
 pid=60404, count=58
 PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: continue
 Quit
 (gdb) FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT)

If you look at the testcase's sources, you'll see that the intention
is to resumes the program with "continue", wait to see a few of those
"pid=..., count=..." lines, and then interrupt the program with
Ctrl-C.  But somehow, that resulted in GDB printing "Quit", instead of
the Ctrl-C stopping the program with SIGINT.

Here's what is happening:

 #1 - those "pid=..., count=..." lines we see above weren't actually
      output by the inferior after it has been continued (see #1).
      Note that "inf1_how" and "inf2_how" are "attach".  What happened
      is that those "pid=..., count=..." lines were output by the
      inferiors _before_ they were attached to.  We see them at that
      point instead of earlier, because that's where the testcase
      reads from the inferiors' spawn_ids.

 #2 - The testcase mistakenly thinks those "pid=..., count=..." lines
      happened after the continue was processed by GDB, meaning it has
      waited enough, and so sends the Ctrl-C.  GDB hasn't yet passed
      the terminal to the inferior, so the Ctrl-C results in that
      Quit.

The fix here is twofold:

 #1 - flush inferior output right after attaching

 #2 - consume the "Continuing" printed by "continue", indicating the
      inferior has the terminal.  This is the same as done throughout
      the testsuite to handle this exact problem of sending Ctrl-C too
      soon.

gdb/testsuite/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net <mailto:pedro@palves.net>>

* gdb.multi/multi-term-settings.exp (create_inferior): Flush
inferior output.
(coretest): Use $gdb_test_name.  After issuing "continue", wait
for "Continuing".

Change-Id: Iba7671dfe1eee6b98d29cfdb05a1b9aa2f9defb9

[gdb/testsuite] Disable vgdb tests if xml not supported

I build gdb without xml support using --without-expat, and ran into:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M
relaying data between gdb and process 22032^M
warning: Can not parse XML target description; XML support was disabled at \
  compile time^M
  ...
(gdb) PASS: gdb.base/valgrind-infcall.exp: continue #1
p gdb_test_infcall ()^M
Remote 'g' packet reply is too long (expected 560 bytes, got 800 bytes): ...^M
(gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall ()
...

After googling the error message with context valgrind gdbserver, I found
indications that the Remote 'g' packet reply error is due to missing xml
support.

And here ( https://www.valgrind.org/docs/manual/manual-core-adv.html ) I
found:
...
GDB version needed for ARM and PPC32/64.

You must use a GDB version which is able to read XML target description sent
by a gdbserver.  This is the standard setup if GDB was configured and built
with the "expat" library.  If your GDB was not configured with XML support, it
will report an error message when using the "target" command.  Debugging will
not work because GDB will then not be able to fetch the registers from the
Valgrind gdbserver.
...

So I guess I'm running into the same problem for x86_64.

Fix this by skipping all gdb.base/valgrind-*.exp tests if xml support is not
available.  Although only the gdb.base/valgrind-infcall*.exp produce fails,
the Remote 'g' packet reply error occurs in all tests, so it seems prudent to
disable them all.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.python/py-breakpoint.exp with python 2

With a gdb build using python 2.7, I run into:
...
(gdb) python \
  gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M
  File "<string>", line 1^M
    gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M
                                                          ^^M
SyntaxError: invalid syntax^M
Error while executing Python code.^M
(gdb) FAIL: gdb.python/py-breakpoint.exp: test_bkpt_auto_disable: \
  trap breakpoint_modified event
...

This is caused by the following:
- a lambda function body needs to be an expression
- in python 2, print is a statement, while in python 3 it's a function
- a function call is an expression, and a statement is not.

Fix this by defining a function print_bp_enabled:
...
def print_bp_enabled (bp):
    print (bp.enabled)
end
...
and using that instead.

Tested on x86_64-linux.

[gdb/testsuite] Fix breakpoint detection in gdb.gdb/python-helper.exp

With a gdb configured to be somewhat minimal, while still supporting python:
...
$ gdb --configuration
This GDB was configured as follows:
   configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --without-expat
             --with-gdb-datadir=$install/share/gdb (relocatable)
             --with-jit-reader-dir=$install/lib64/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --without-babeltrace
             --without-intel-pt
             --with-mpfr
             --without-xxhash
             --with-python=/usr
             --with-python-libdir=/usr/lib
             --with-debuginfod
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/usr/lib/debug
             --with-system-gdbinit=$devel/system-gdbinit
...
and using gcc 4.8 to build gdb (causing std::thread not to be used due to
PR28318) I ran into:
...
(gdb) PASS: gdb.gdb/python-helper.exp: start inner gdb
print 1^M
^M
Breakpoint 2, value_print () at src/gdb/valprint.c:1174^M
1174      scoped_value_mark free_values;^M
(xgdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in inner gdb (timeout)
...

The problem is that the regexp expects "hit Breakpoint $decimal".  The "hit"
part is missing.

The "hit" is printed by maybe_print_thread_hit_breakpoint, when
show_thread_that_caused_stop returns true:
...
int
show_thread_that_caused_stop (void)
{
  return highest_thread_num > 1;
}
...
Apparently, that's not the case.

Fix this by removing "hit" from the regexp, making the regexp more similar to
what is used in say, continue_to_breakpoint.

Tested on x86_64-linux.

gdb: fix build when libbacktrace and execinfo backtrace are not available

In this commit:

  commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0
  Date:   Wed Aug 11 13:24:33 2021 +0100

      gdb: use libbacktrace to create a better backtrace for fatal signals

The build of GDB was broken iff, the execinfo backtrace API is not
available, and, libbacktrace is either disabled, or not usable.  In
this case you'll see build errors like this:

      CXX    bt-utils.o
    /home/username/src/binutils-gdb/gdb/bt-utils.c: In function 'void gdb_internal_backtrace()':
    /home/username/src/binutils-gdb/gdb/bt-utils.c:165:5: error: 'gdb_internal_backtrace_1' was not declared in this scope
         gdb_internal_backtrace_1 ();
         ^~~~~~~~~~~~~~~~~~~~~~~~

This commit fixes the issue by guarding the call to
gdb_internal_backtrace_1 with '#ifdef GDB_PRINT_INTERNAL_BACKTRACE',
which is only defined when one of the backtrace libraries are
available.

gdb/doc: use 'standard error stream' instead of 'stderr' in some places

With this commit:

  commit 91f2597bd24d171c1337a4629f8237aa47c59082
  Date:   Thu Aug 12 18:24:59 2021 +0100

      gdb: print backtrace for internal error/warning

I included some references to 'stderr', which, it was pointed out,
would be better written as 'standard error stream'.  See:

  https://sourceware.org/pipermail/gdb-patches/2021-September/182225.html

This commit replaces the two instances of 'stderr' that I introduced.

gdb: fix manor -> manner typo in some comments

In a recent commit I used 'manor' in some comments rather than
'manner'.  This commit fixes those two mistakes.

I also looked through the gdb/ tree and found one additional instance
of this mistake that this commit also fixes.

PR27202, readelf -wL doesn't work on ".loc 0"

For DWARF revision 4 and earlier, display_debug_lines_decoded
populates the file_table array with entries read from .debug_line
after the directory table.  file_table[0] contains the first entry.
DWARF rev 4 line number programs index this entry as file number one.
DWARF revision 5 changes .debug_line format quite extensively, and in
particular gives file number zero a meaning.

PR 27202
* dwarf.c (display_debug_lines_decoded): Correct indexing used
for DWARF5 files.

gdb: enable target_async around stop_all_threads call in process_initial_stop_replies

The following scenario hangs:

 - maint set target-non-stop on
 - `gdbserver --attach`
 - a multi-threaded program

For example:

Terminal 1:

    $ gnome-calculator&
    [1] 495731
    $ ../gdbserver/gdbserver --once --attach :1234 495731
    Attached; pid = 495731
    Listening on port 1234

Terminal 2:

    $ ./gdb -nx -q --data-directory=data-directory /usr/bin/gnome-calculator -ex "maint set target-non-stop on" -ex "tar rem :1234"
    Reading symbols from /usr/bin/gnome-calculator...
    (No debugging symbols found in /usr/bin/gnome-calculator)
    Remote debugging using :1234
    * hangs *

What happens is:

 - The protocol between gdb and gdbserver is in non-stop mode, but the
   user-visible behavior is all-stop
 - On connect, gdbserver sends one stop reply for one thread that is
   stops, the others stay running
 - In process_initial_stop_replies, gdb calls stop_all_threads to stop
   these other threads, because we are using the all-stop user-visible
   mode
 - stop_all_threads sends a stop request for all the running threads and
   then waits for resulting events
 - At this point, the remote target is in target_async(0) mode, which
   makes stop_all_threads not consider it for events
 - stop_all_threads loops indefinitely (it does not even block
   indefinitely, it is in an infinite busy loop) because there are no
   event sources.  wait_one_event returns a TARGET_WAITKIND_NO_RESUMED
   wait status.

Fix that by making the remote target async around the stop_all_threads
call.

I haven't implemented it because I'm not sure how to do it, but I think
it would be a good idea to have, in stop_all_threads / wait_one /
handle_one, an assert to check that if we are expecting one or more
event, then there are some targets that are in a state where they can
supply some events.  Otherwise, we'll necessarily be stuck in this
infinite loop, and it's probably due to a bug in GDB.  I'm not too sure
where to put this or how to express it though.  Perhaps in
stop_all_threads, here:

  for (int i = 0; i < waits_needed; i++)
    {
      wait_one_event event = wait_one ();
      *here*
      if (handle_one (event))
break;
    }

If at that point, the returned event is TARGET_WAITKIND_NO_RESUMED,
there's a problem.  We expect some event, because we've asked some
threads to stop, but all targets are answering that they won't have any
events for us.  That's a contradiction, and a sign that something has
gone wrong.  It could perhaps event be:

    gdb_assert (event.ws.kind != TARGET_WAITKIND_NO_RESUMED);

in handle_one, as the idea is the same in prepare_for_detach.

A bit more sophisticated would be: we know which targets we are
expecting waits from, since we know which threads we have asked to
stop.  So if any of these targets returns TARGET_WAITKIND_NO_RESUMED,
something is fishy.

Add a test that tests attaching with gdbserver's --attach flag to a
multi-threaded program, and then connecting to it.  Without the fix, the
test reproduces the hang.

Change-Id: If6f6690a4887ca66693ef1af64791dda4c65f24f

Automatic date update in version.in

gdb: fix darwin-nat build (again)

I made a mistake in the previous patch.  Adjust the format string to
match the arguments.

Change-Id: I4d45e0e0adb78eb3b5a06ba1a5287155940056ba

gdb: fix darwin-nat build

There are two errors of this kind:

      CXX    darwin-nat.o
    /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1175:19: error: format specifies type 'unsigned long' but the argument has type 'ULONGEST' (aka 'unsigned long long') [-Werror,-Wformat]
 ptid.pid (), ptid.tid ());
      ^~~~~~~~~~~

Fix them by using ptid_t's to_string method.

Change-Id: I52087d5f7ee0fc01ac8b3f87d4db0217cb0d7cc7

gdb.base/foll-fork.exp: accept "info breakpoints" output in any order

The test currently requires the "inf 1" breakpoint to be before the "inf
2" breakpoint.  This is not always the case:

    info breakpoints 2
    Num     Type           Disp Enb Address            What
    2       breakpoint     keep y   <MULTIPLE>
    2.1                         y   0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 2
    2.2                         y   0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 1
    (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info breakpoints

Since add_location_to_breakpoint uses only the address as a criterion to
sort locations, the order of locations at the same address is not
stable: it will depend on the insertion order.  Here, the insertion
order comes from the order of SALs when creating the breakpoint, which
can vary from machine to machine.  While it would be more user-friendly
to have a more stable order for printed breakpoint locations, it doesn't
really matter for this test, and it would be hard to define an order
that will be the same everywhere, all the time.

So, loosen the regexp to accept "inf 1" and "inf 2" in any order.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I5ada2e0c6ad0669e0d161bfb6b767229c0970d16

RISC-V: Fix wrong version number when arch contains 'p'.

When specify a default version for p extension in
riscv_supported_std_ext[](elfxx-riscv.c) and assembling with
-march=rv32imacp, the c extension's version in attribute will become
0p0, the expectation is 2p0.

TODO: Remember to add testcase when we have supported standrad p in
the future.

bfd/
PR gas/28372
* elfxx-riscv.c (riscv_parsing_subset_version): Break if p
represent the 'p' extension.

Change-Id: Ia4e0cf26f3d7d07acaee8cefd86707ecac663a59

RISC-V: Allow to add numbers in the prefixed extension names.

We need to allow adding numbers in the prefixed extension names, since
the zve<32,64><d,f,x> extensions are included in the forzen rvv v1.0 spec
recently.  But there are two restrictions as follows,

* The extension name ends with <number>p is invalid, since this may
be confused with extension with <number>.0 version.  We report errors
for this case.

Invalid format: [z|h|s|zvm|x][0-9a-z]+[0-9]+p

* The extension name ends with numbers is valid, but the numbers will
be parsed as major version, so try to avoid naming extensions like this.

bfd/
* elfxx-riscv.c (riscv_recognized_prefixed_ext): Renamed from
riscv_valid_prefixed_ext/
(riscv_parsing_subset_version): The extensions end with <number>p
is forbidden, we already report the detailed errors in the
riscv_parse_prefixed_ext, so clean the code and unused parameters.
(riscv_parse_std_ext): Updated.
(riscv_parse_prefixed_ext): Rewrite the parser to allow numbers
in the prefixed extension names.
gas/
* testsuite/gas/riscv/march-fail-invalid-x-01.d: New testcases.
* testsuite/gas/riscv/march-fail-invalid-x-02.d: Likewise.
* testsuite/gas/riscv/march-fail-invalid-z-01.d: Likewise.
* testsuite/gas/riscv/march-fail-invalid-z-02.d: Likewise.
* testsuite/gas/riscv/march-fail-invalid.l: Likewise.
* testsuite/gas/riscv/march-fail-version-x.d: Removed.
* testsuite/gas/riscv/march-fail-version-z.d: Likewise.
* testsuite/gas/riscv/march-fail-version.l: Likewise.

gdb: print backtrace for internal error/warning

This commit builds on previous work to allow GDB to print a backtrace
of itself when GDB encounters an internal-error or internal-warning.
This fixes PR gdb/26377.

There's not many places where we call internal_warning, and I guess in
most cases the user would probably continue their debug session.  And
so, in order to avoid cluttering up the output, by default, printing
of a backtrace is off for internal-warnings.

In contrast, printing of a backtrace is on by default for
internal-errors, as I figure that in most cases hitting an
internal-error is going to be the end of the debug session.

Whether a backtrace is printed or not can be controlled with the new
settings:

  maintenance set internal-error backtrace on|off
  maintenance show internal-error backtrace

  maintenance set internal-warning backtrace on|off
  maintenance show internal-warning backtrace

Here is an example of what an internal-error now looks like with the
backtrace included:

  (gdb) maintenance internal-error blah
  ../../src.dev-3/gdb/maint.c:82: internal-error: blah
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  ----- Backtrace -----
  0x5c61ca gdb_internal_backtrace_1
   ../../src.dev-3/gdb/bt-utils.c:123
  0x5c626d _Z22gdb_internal_backtracev
   ../../src.dev-3/gdb/bt-utils.c:165
  0xe33237 internal_vproblem
   ../../src.dev-3/gdb/utils.c:393
  0xe33539 _Z15internal_verrorPKciS0_P13__va_list_tag
   ../../src.dev-3/gdb/utils.c:470
  0x1549652 _Z14internal_errorPKciS0_z
   ../../src.dev-3/gdbsupport/errors.cc:55
  0x9c7982 maintenance_internal_error
   ../../src.dev-3/gdb/maint.c:82
  0x636f57 do_simple_func
   ../../src.dev-3/gdb/cli/cli-decode.c:97
   .... snip, lots more backtrace lines ....
  ---------------------
  ../../src.dev-3/gdb/maint.c:82: internal-error: blah
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Quit this debugging session? (y or n) y

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

  ../../src.dev-3/gdb/maint.c:82: internal-error: blah
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Create a core file of GDB? (y or n) n

My hope is that this backtrace might make it slightly easier to
diagnose GDB issues if all that is provided is the console output, I
find that we frequently get reports of an assert being hit that is
located in pretty generic code (frame.c, value.c, etc) and it is not
always obvious how we might have arrived at the assert.

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

gdb: use libbacktrace to create a better backtrace for fatal signals

GDB recently gained the ability to print a backtrace when a fatal
signal is encountered.  This backtrace is produced using the backtrace
and backtrace_symbols_fd API available in glibc.

However, in order for this API to actually map addresses to symbol
names it is required that the application (GDB) be compiled with
-rdynamic, which GDB is not by default.

As a result, the backtrace produced often looks like this:

  Fatal signal: Bus error
  ----- Backtrace -----
  ./gdb/gdb[0x80ec00]
  ./gdb/gdb[0x80ed56]
  /lib64/libc.so.6(+0x3c6b0)[0x7fc2ce1936b0]
  /lib64/libc.so.6(__poll+0x4f)[0x7fc2ce24da5f]
  ./gdb/gdb[0x15495ba]
  ./gdb/gdb[0x15489b8]
  ./gdb/gdb[0x9b794d]
  ./gdb/gdb[0x9b7a6d]
  ./gdb/gdb[0x9b943b]
  ./gdb/gdb[0x9b94a1]
  ./gdb/gdb[0x4175dd]
  /lib64/libc.so.6(__libc_start_main+0xf3)[0x7fc2ce17e1a3]
  ./gdb/gdb[0x4174de]
  ---------------------

This is OK if you have access to the exact same build of GDB, you can
manually map the addresses back to symbols, however, it is next to
useless if all you have is a backtrace copied into a bug report.

GCC uses libbacktrace for printing a backtrace when it encounters an
error.  In recent commits I added this library into the binutils-gdb
repository, and in this commit I allow this library to be used by
GDB.  Now (when GDB is compiled with debug information) the backtrace
looks like this:

  ----- Backtrace -----
  0x80ee08 gdb_internal_backtrace
   ../../src/gdb/event-top.c:989
  0x80ef0b handle_fatal_signal
   ../../src/gdb/event-top.c:1036
  0x7f24539dd6af ???
  0x7f2453a97a5f ???
  0x154976f gdb_wait_for_event
   ../../src/gdbsupport/event-loop.cc:613
  0x1548b6d _Z16gdb_do_one_eventv
   ../../src/gdbsupport/event-loop.cc:237
  0x9b7b02 start_event_loop
   ../../src/gdb/main.c:421
  0x9b7c22 captured_command_loop
   ../../src/gdb/main.c:481
  0x9b95f0 captured_main
   ../../src/gdb/main.c:1353
  0x9b9656 _Z8gdb_mainP18captured_main_args
   ../../src/gdb/main.c:1368
  0x4175ec main
   ../../src/gdb/gdb.c:32
  ---------------------

Which seems much more useful.

Use of libbacktrace is optional.  If GDB is configured with
--disable-libbacktrace then the libbacktrace directory will not be
built, and GDB will not try to use this library.  In this case GDB
would try to use the old backtrace and backtrace_symbols_fd API.

All of the functions related to writing the backtrace of GDB itself
have been moved into the new files gdb/by-utils.{c,h}.

src-release.sh: add libbacktrace to GDB_SUPPORT_DIRS

After the previous commit that imported libbacktrace from gcc, this
commit updates src-release.sh so that the libbacktrace directory is
included in the gdb release tar file.

ChangeLog:

* src-release.sh (GDB_SUPPPORT_DIRS): Add libbacktrace.

Copy in libbacktrace from gcc

This copies in libbacktrace from the gcc repository as it was in the
commit 62e420293a293608f383d9b9c7f2debd666e9fc9.  GDB is going to
start using this library soon.

A dependency between GDB and libbacktrace has already been added to
the top level Makefile, so, after this commit, when building GDB,
libbacktrace will be built first.  However, libbacktrace is not yet
linked into GDB, or used by GDB in any way.

It is possible to stop libbacktrace being built by configuring the
tree with --disable-libbacktrace.

This commit does NOT update src-release.sh, that will be done in the
next commit, this commit ONLY imports libbacktrace from gcc.  This
means that if you try to make a release of GDB from exactly this
commit then the release tar file will not include libbacktrace.
However, as libbacktrace is an optional dependency this is fine.

gdb: Add a dependency between gdb and libbacktrace

GDB is going to start using libbacktrace, so add a build dependency.

ChangeLog:

* Makefile.def: Add all-gdb dependency on all-libbacktrace.
* Makefile.in: Regenerate.

top-level configure: setup target_configdirs based on repository

The top-level configure script is shared between the gcc repository
and the binutils-gdb repository.

The target_configdirs variable in the configure.ac script, defines
sub-directories that contain components that should be built for the
target using the target tools.

Some components, e.g. zlib, are built as both host and target
libraries.

This causes problems for binutils-gdb.  If we run 'make all' in the
binutils-gdb repository we end up trying to build a target version of
the zlib library, which requires the target compiler be available.
Often the target compiler isn't immediately available, and so the
build fails.

The problem with zlib impacted a previous attempt to synchronise the
top-level configure scripts from gcc to binutils-gdb, see this thread:

  https://sourceware.org/pipermail/binutils/2019-May/107094.html

And I'm in the process of importing libbacktrace in to binutils-gdb,
which is also a host and target library, and triggers the same issues.

I believe that for binutils-gdb, at least at the moment, there are no
target libraries that we need to build.

In the configure script we build three lists of things we want to
build, $configdirs, $build_configdirs, and $target_configdirs, we also
build two lists of things we don't want to build, $skipdirs and
$noconfigdirs.  We then remove anything that is in the lists of things
not to build, from the list of things that should be built.

My proposal is to add everything in target_configdirs into skipdirs,
if the source tree doesn't contain a gcc/ sub-directory.  The result
is that for binutils-gdb no target tools or libraries will be built,
while for the gcc repository, nothing should change.

If a user builds a unified source tree, then the target tools and
libraries should still be built as the gcc/ directory will be present.

I've tested a build of gcc on x86-64, and the same set of target
libraries still seem to get built.  On binutils-gdb this change
resolves the issues with 'make all'.

ChangeLog:

* configure: Regenerate.
* configure.ac (skipdirs): Add the contents of target_configdirs if
we are not building gcc.

PR28391, strip/objcopy --preserve-dates *.a: cannot set time

After commit 985e0264516 copy_archive function began to pass invalid
values to the utimensat(2) function when it tries to preserve
timestamps in ar archives.  This happens because the bfd_stat_arch_elt
implementation for ar archives fills only the st_mtim.tv_sec part of
the st_mtim timespec structure, but leaves the st_mtim.tv_nsec part
and the whole st_atim timespec untouched leaving them uninitialized

PR 28391
* ar.c (extract_file): Clear buf for preserve_dates.
* objcopy.c (copy_archive): Likewise.

sim: drop weak func attrs on module inits

When I first wrote this, I was thinking we'd scan all source files
that existed and generate a complete init list.  That means for any
particular build, we'd probably have a few functions that didn't
exist, so weak attributes was necessary.  What I ended up scanning
though was only the source files that went into a particular build.

There was another concern too: a source file might be included, but
the build settings would cause all of its contents to be skipped
(via CPP defines).  So scanning via naive grep would pick up names
not actually available.  A check of the source tree shows that we
never do this, and it's pretty easy to institute a policy that we
don't start (by at the very least including a stub init func).

The use of weak symbols ends up causing a problem in practice: for
a few modules (like profiling), nothing else pulls it in, so the
linker omits it entirely, which leads to the profiling module never
being available.  So drop the weak markings since we know all these
funcs will be available.

x86: Print {bad} on invalid broadcast in OP_E_memory

Don't print broadcast for scalar_mode, and print {bad} for invalid broadcast.

gas/

PR binutils/28381
* testsuite/gas/i386/bad-bcast.s: Add a new testcase.
* testsuite/gas/i386/bad-bcast.d: Likewise.
* testsuite/gas/i386/bad-bcast-intel.d: New.

opcodes/

PR binutils/28381
* i386-dis.c (static struct): Add no_broadcast.
(OP_E_memory): Mark invalid broadcast with no_broadcast=1 and Print "{bad}"for it.
(intel_operand_size): mark invalid broadcast with no_broadcast=1.
(OP_XMM): Mark scalar_mode with no_broadcast=1.

gdb: use intrusive_list for linux-nat lwp_list

Replace the manually maintained linked list of lwp_info objects with
intrusive_list.  Replace the ALL_LWPS macro with all_lwps, which returns
a range.  Add all_lwps_safe as well, for use in iterate_over_lwps, which
currently iterates in a safe manner.

Change-Id: I355313502510acc0103f5eaf2fbde80897d6376c

gdb: add destructor to lwp_info

Replace the lwp_free function with a destructor.  Make lwp_info
non-copyable, since there is now a destructor (we wouldn't want an
lwp_info object getting copied and this->arch_private getting deleted
twice).

Change-Id: I09fcbe967e362566d3a06fed2abca2a9955570fa

gdb: make lwp_info non-POD

Initialize all fields in the class declaration directly.  This opens the
door to using intrusive_list, done in the following patch.

Change-Id: I38bb27410cd9ebf511d310bb86fe2ea1872c3b05

Automatic date update in version.in

gdb: don't share aspace/pspace on fork with "detach-on-fork on" and "follow-fork-mode child"

We found that when handling forks, two inferiors can unexpectedly share
their program space and address space.  To reproduce:

 1. Using a test program that forks...
 2. "set follow-fork-mode child"
 3. "set detach-on-fork on" (the default)
 4. run to a breakpoint somewhere after the fork

Step 4 should have created a new inferior:

    (gdb) info inferiors
      Num  Description       Connection           Executable
      1    <null>                                 /home/smarchi/build/wt/amd/gdb/fork
    * 2    process 251425    1 (native)           /home/smarchi/build/wt/amd/gdb/fork

By inspecting the state of GDB, we can see that the two inferiors now
share one program space and one address space:

Inferior 1:

    (top-gdb) p inferior_list.m_front.num
    $2 = 1
    (top-gdb) p inferior_list.m_front.aspace
    $3 = (struct address_space *) 0x5595e2520400
    (top-gdb) p inferior_list.m_front.pspace
    $4 = (struct program_space *) 0x5595e2520440

Inferior 2:

    (top-gdb) p inferior_list.m_front.next.num
    $5 = 2
    (top-gdb) p inferior_list.m_front.next.aspace
    $6 = (struct address_space *) 0x5595e2520400
    (top-gdb) p inferior_list.m_front.next.pspace
    $7 = (struct program_space *) 0x5595e2520440

You can then run inferior 1 again and the two inferiors will still
erroneously share their spaces, but already at this point this is wrong.

The cause of the bad {a,p}space sharing is in follow_fork_inferior.
When following the child and detaching from the parent, we just re-use
the parent's spaces, rather than cloning them.  When we switch back to
inferior 1 and run again, we find ourselves with two unrelated inferiors
sharing spaces.

Fix that by creating new spaces for the parent after having moved them
to the child.  My initial implementation created new spaces for the
child instead.  Doing this breaks doing "next" over fork().  When "next"
start, we record the symtab of the starting location.  When the program
stops, we compare that symtab with the symtab the program has stopped
at.  If the symtab or the line number has changed, we conclude the
"next" is done.  If we create a new program space for the child and copy
the parent's program space to it with clone_program_space, it creates
new symtabs for the child as well.  When the child stop, but still on
the fork() line, GDB thinks the "next" is done because the symtab
pointers no longer match.  In reality they are two symtab instances that
represent the same file.  But moving the spaces to the child and
creating new spaces for the parent, we avoid this problem.

Note that the problem described above happens today with "detach-on-fork
off" and "follow-fork-mode child", because we create new spaces for the
child.  This will have to be addressed later.

Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is
expected to have a location in each inferiors.  Without the fix, when
the two inferiors erroneously share a program space, GDB reports a
single location.

Change-Id: Ifea76e14f87b9f7321fc3a766217061190e71c6e

gdb.base/foll-fork.exp: use foreach_with_prefix to handle prefixes

No behavior change in the test expected, other than in the test names.

Change-Id: I111137483858ab0f23138439f2930009779a2b3d

gdb.base/foll-fork.exp: rename variables

Rename the variables / parameters used to match the corresponding GDB
setting name, I find that easier to follow.

Change-Id: Idcbddbbb369279fcf1e808b11a8c478f21b2a946

gdb.base/foll-fork.exp: refactor to restart GDB between each portion of the test

This test is difficult to follow and modify because the state of GDB is
preserved some tests.  Add a setup proc, which starts a new GDB and runs
to main, and use it in all test procs.  Use proc_with_prefix to avoid
duplicates.

The check_fork_catchpoints proc also seems used to check for follow-fork
support by checking if catchpoints are supported.  If they are not, it
uses "return -code return", which makes its caller return.  I find this
unnecessary complex, versus just returning a boolean.  Modify it to do
so.

Change-Id: I23e62b204286c5e9c5c86d2727f7d33fb126ed08

gdb.base/foll-fork.exp: remove gating based on target triplet

It looks like this test has some code to check at runtime the support of
fork handling of the target (see check_fork_catchpoints).  So, it seems
to me that the check based on target triplet at the beginning of the
test is not needed.  This kind of gating is generally not desirable,
because we wouldn't think of updating it when adding fork support to a
target.  For example, FreeBSD supports fork, but it wasn't listed here.

Change-Id: I6b55f2298edae6b37c3681fb8633d8ea1b5aabee

gdb.base/foll-fork.exp: remove DUPLICATEs

Remove DUPLICATEs, and and at the same time replace two uses of
gdb_test_multiple with gdb_test.  I don't think using gdb_test_multiple
is necessary here.

Change-Id: I8dcf097c3364e92d4f0e11f0c0f05dbb88e86742

libctf, lookup: fix bounds of pptrtab lookup

An off-by-one bug in the check for pptrtab lookup meant that we could
access the pptrtab past its bounds (*well* past its bounds),
particularly if we called ctf_lookup_by_name in a child dict with "*foo"
where "foo" is a type that exists in the parent but not the child and no
previous lookups by name have been carried out.  (Note that "*foo" is
not even a valid thing to call ctf_lookup_by_name with: foo * is.
Nonetheless, users sometimes do call ctf_lookup_by_name with invalid
content, and it should return ECTF_NOTYPE, not crash.)

ctf_pptrtab_len, as its name suggests (and as other tests of it in
ctf-lookup.c confirm), is one higher than the maximum valid permissible
index, so the comparison is wrong.

(Test added, which should fail pretty reliably in the presence of this
bug on any machine with 4KiB pages.)

libctf/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* ctf-lookup.c (ctf_lookup_by_name_internal): Fix pptrtab bounds.
* testsuite/libctf-writable/pptrtab-writable-page-deep-lookup.*:
New test.

libctf, testsuite: fix various warnings in tests

These warnings are all off by default, but if they do fire you get
spurious ERRORs when running make check-libctf.

libctf/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* testsuite/libctf-lookup/enum-symbol.c: Remove unused label.
* testsuite/libctf-lookup/conflicting-type-syms.c: Remove unused
variables.
* testsuite/libctf-regression/pptrtab.c: Likewise.
* testsuite/libctf-regression/type-add-unnamed-struct.c: Likewise.
* testsuite/libctf-writable/pptrtab.c: Likewise.
* testsuite/libctf-writable/reserialize-strtab-corruption.c:
Likewise.
* testsuite/libctf-regression/nonstatic-var-section-ld-r.c: Fix
format string.
* testsuite/libctf-regression/nonstatic-var-section-ld.c:
Likewise.
* testsuite/libctf-regression/nonstatic-var-section-ld.lk: Adjust.
* testsuite/libctf-writable/symtypetab-nonlinker-writeout.c: Fix
initializer.

libctf: fix handling of CTF symtypetab sections emitted by older GCC

Older (pre-upstreaming) GCC emits a function symtypetab section of a
format never read by any extant libctf.  We can detect such CTF dicts by
the lack of the CTF_F_NEWFUNCINFO flag in their header, and we do so
when reading in the symtypetab section -- but if the set of symbols with
types is sufficiently sparse, even an older GCC will emit a function
index section.

In NEWFUNCINFO-capable compilers, this section will always be the exact
same length as the corresponding function section (each is an array of
uint32_t, associated 1:1 with each other). But this is not true for the
older compiler, for which the sections are different lengths.  We check
to see if the function symtypetab section and its index are the same
length, but we fail to skip this check when this is not a NEWFUNCINFO
dict, and emit a spurious corruption error for a CTF dict we could
have perfectly well opened and used.

Fix trivial: check the flag (and fix the terrible grammar of the error
message at the same time).

libctf/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* ctf-open.c (ctf_bufopen_internal): Don't complain about corrupt
function index symtypetab sections if this is an old-format
function symtypetab section (which should be ignored in any case).
Fix bad grammar.

configure: regenerate in all projects that use libtool.m4

(including sim/, which has no changelog.)

bfd/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* configure: Regenerate.

binutils/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* configure: Regenerate.

gas/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* configure: Regenerate.

gprof/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* configure: Regenerate.

ld/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* configure: Regenerate.

libctf/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* configure: Regenerate.
* Makefile.in: Regenerate.

opcodes/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* configure: Regenerate.

zlib/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

* configure: Regenerate.

libctf: try several possibilities for linker versioning flags

Checking for linker versioning by just grepping ld --help output for
mentions of --version-script is inadequate now that Solaris 11.4
implements a --version-script with different semantics.  Try linking a
test program with a small wildcard-using version script with each
supported set of flags in turn, to make sure that linker versioning is
not only advertised but actually works.

The Solaris "GNU-compatible" linker versioning is not quite
GNU-compatible enough, but we can work around the differences by
generating a new version script that removes the comments from the
original (Solaris ld requires #-style comments), and making another
version script for libctf-nonbfd in particular which doesn't mention any
of the symbols that appear in libctf.la, to avoid Solaris ld introducing
corresponding new NOTYPE symbols to match the version script.

libctf/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

PR libctf/27967
* configure.ac (VERSION_FLAGS): Replace with...
(ac_cv_libctf_version_script): ... this multiple test.
(VERSION_FLAGS_NOBFD): Substitute this too.
* Makefile.am (libctf_nobfd_la_LDFLAGS): Use it.  Split out...
(libctf_ldflags_nover): ... non-versioning flags here.
(libctf_la_LDFLAGS): Use it.
* libctf.ver: Give every symbol not in libctf-nobfd a comment on
the same line noting as much.

libtool.m4: fix nm BSD flag detection

Libtool needs to get BSD-format (or MS-format) output out of the system
nm, so that it can scan generated object files for symbol names for
-export-symbols-regex support.  Some nms need specific flags to turn on
BSD-formatted output, so libtool checks for this in its AC_PATH_NM.
Unfortunately the code to do this has a pair of interlocking flaws:

 - it runs the test by doing an nm of /dev/null.  Some platforms
   reasonably refuse to do an nm on a device file, but before now this
   has only been worked around by assuming that the error message has a
   specific textual form emitted by Tru64 nm, and that getting this
   error means this is Tru64 nm and that nm -B would work to produce
   BSD-format output, even though the test never actually got anything
   but an error message out of nm -B.  This is fixable by nm'ing *nm
   itself* (since we necessarily have a path to it).

 - the test is entirely skipped if NM is set in the environment, on the
   grounds that the user has overridden the test: but the user cannot
   reasonably be expected to know that libtool wants not only nm but
   also flags forcing BSD-format output.  Worse yet, one such "user" is
   the top-level Cygnus configure script, which neither tests for
   nor specifies any BSD-format flags.  So platforms needing BSD-format
   flags always fail to set them when run in a Cygnus tree, breaking
   -export-symbols-regex on such platforms.  Libtool also needs to
   augment $LD on some platforms, but this is done unconditionally,
   augmenting whatever the user specified: the nm check should do the
   same.

   One wrinkle: if the user has overridden $NM, a path might have been
   provided: so we use the user-specified path if there was one, and
   otherwise do the path search as usual.  (If the nm specified doesn't
   work, this might lead to a few extra pointless path searches -- but
   the test is going to fail anyway, so that's not a problem.)

(Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a
symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where
*that* is a symlink to /usr/bin/nm.)

ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

PR libctf/27967
* libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided
NM, if there is one.  Run nm on itself, not on /dev/null, to avoid
errors from nms that refuse to work on non-regular files.  Remove
other workarounds for this problem.  Strip out blank lines from the
nm output.

libtool.m4: augment symcode for Solaris 11

This reports common symbols like GNU nm, via a type code of 'C'.

ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

PR libctf/27967
* libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for
Solaris 11.

libctf: link against libiberty before linking in libbfd or libctf-nobfd

This ensures that the CTF_LIBADD, which always contains at least this
when doing a shared link:

-L`pwd`/../libiberty/pic -liberty

appears in the link line before any requirements pulled in by libbfd.la,
which include -liberty but because it is install-time do not include the
-L`pwd`/../libiberty/pic portion (in an indirect dep like this, the path
comes from the libbfd.la file, and is an install path).  libiberty also
appears after libbfd in the link line by virtue of libctf-nobfd.la,
because libctf-nobfd has to follow libbfd in the link line, and that
needs symbols from libiberty too.

Without this, an installed liberty might well be pulled in by libbfd,
and if --enable-install-libiberty is not specified this libiberty might
be completely incompatible with what is being installed and break either
or boht of libbfd and libctf. (The specific problem observed here is
that bsearch_r was not present, but other problems might easily be
observed in future too.)

Because ld links against libctf, this has a tendency to break the system
linker at install time too, if installing with --prefix=/usr.  That's
quite unpleasant to recover from.

libctf/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

PR libctf/27360
* Makefile.am (libctf_la_LIBADD): Link against libiberty
before pulling in libbfd.la or pulling in libctf-nobfd.la.
* Makefile.in: Regenerate.

[gdb/build] Fix build with g++-4.8

When building g++-4.8, we run into:
...
src/gdb/dwarf2/read.c:919:5: error: multiple fields in union \
  'partial_die_info::<anonymous union>' initialized
...

This is due to:
...
    union
    {
      struct
      {
       CORE_ADDR lowpc = 0;
       CORE_ADDR highpc = 0;
      };
      ULONGEST ranges_offset;
    };
...

The error looks incorrect, given that only one union member is initialized,
and does not reproduce with newer g++.

Nevertheless, work around this by moving the initialization to a constructor.

[ I considered just removing the initialization, with the idea that access
should be guarded by has_pc_info, but I ran into one failure in the testsuite,
for gdb.base/check-psymtab.exp due to add_partial_symbol using lowpc without
checking has_pc_info. ]

Tested on x86_64-linux.

gdb: add setting to disable reading source code files

In some situations it is possible that a user might not want GDB to
try and access source code files, for example, the source code might
be stored on a slow to access network file system.

It is almost certainly possible that using some combination of 'set
directories' and/or 'set substitute-path' a user can trick GDB into
being unable to find the source files, but this feels like a rather
crude way to solve the problem.

In this commit a new option is add that stops GDB from opening and
reading the source files.  A user can run with source code reading
disabled if this is required, then re-enable later if they decide
that they now want to view the source code.

gdb: remove duplicate cmd_list_element declarations

For some reason we have two locations where cmd_list_elements are
declared, cli/cli-cmds.h and gdbcmd.h.  Worse still there is
duplication between these two locations.

In this commit I have moved all of the cmd_list_element declarations
from gdbcmd.h into cli/cli-cmds.h and removed the duplicates.

There should be no user visible changes after this commit.

gdb: prevent an assertion when computing the frame_id for an inline frame

I ran into this assertion while GDB was trying to unwind the stack:

  gdb/inline-frame.c:173: internal-error: void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion `frame_id_p (*this_id)' failed.

That is, when building the frame_id for an inline frame, GDB asks for
the frame_id of the previous frame.  Unfortunately, no valid frame_id
was returned for the previous frame, and so the assertion triggers.

What is happening is this, I had a stack that looked something like
this (the arrows '->' point from caller to callee):

  normal_frame -> inline_frame

However, for whatever reason (e.g. broken debug information, or
corrupted stack contents in the inferior), when GDB tries to unwind
"normal_frame", it ends up getting back effectively the same frame,
thus the call stack looks like this to GDB:

  .-> normal_frame -> inline_frame
  |     |
  '-----'

Given such a situation we would expect GDB to terminate the stack with
an error like this:

  Backtrace stopped: previous frame identical to this frame (corrupt stack?)

However, the inline_frame causes a problem, and here's why:

When unwinding we start from the sentinel frame and call
get_prev_frame.  We eventually end up in get_prev_frame_if_no_cycle,
in here we create a raw frame, and as this is frame #0 we immediately
return.

However, eventually we will try to unwind the stack further.  When we
do this we inevitably needing to know the frame_id for frame #0, and
so, eventually, we end up in compute_frame_id.

In compute_frame_id we first find the right unwinder for this frame,
in our case (i.e. for inline_frame) the $pc is within the function
normal_frame, but also within a block associated with the inlined
function inline_frame, as such the inline frame unwinder claims this
frame.

Back in compute_frame_id we next compute the frame_id, for our
inline_frame this means a call to inline_frame_this_id.

The ID of an inline frame is based on the id of the previous frame, so
from inline_frame_this_id we call get_prev_frame_always, this
eventually calls get_prev_frame_if_no_cycle again, which creates
another raw frame and calls compute_frame_id (for frames other than
frame 0 we immediately compute the frame_id).

In compute_frame_id we again identify the correct unwinder for this
frame.  Our $pc is unchanged, however, the fact that the next frame is
of type INLINE_FRAME prevents the inline frame unwinder from claiming
this frame again, and so, the standard DWARF frame unwinder claims
normal_frame.

We return to compute_frame_id and call the standard DWARF function to
build the frame_id for normal_frame.

With the frame_id of normal_frame figured out we return to
compute_frame_id, and then to get_prev_frame_if_no_cycle, where we add
the ID for normal_frame into the frame_id cache, and return the frame
back to inline_frame_this_id.

From inline_frame_this_id we build a frame_id for inline_frame and
return to compute_frame_id, and then to get_prev_frame_if_no_cycle,
which adds the frame_id for inline_frame into the frame_id cache.

So far, so good.

However, as we are trying to unwind the complete stack, we eventually
ask for the previous frame of normal_frame, remember, at this point
GDB doesn't know the stack is corrupted (with a cycle), GDB still
needs to figure that out.

So, we eventually end up in get_prev_frame_if_no_cycle where we create
a raw frame and call compute_frame_id, remember, this is for the frame
before normal_frame.

The first task for compute_frame_id is to find the unwinder for this
frame, so all of the frame sniffers are tried in order, this includes
the inline frame sniffer.

The inline frame sniffer asks for the $pc, this request is sent up the
stack to normal_frame, which, due to its cyclic behaviour, tells GDB
that the $pc in the previous frame was the same as the $pc in
normal_frame.

GDB spots that this $pc corresponds to both the function normal_frame
and also the inline function inline_frame.  As the next frame is not
an INLINE_FRAME then GDB figures that we have not yet built a frame to
cover inline_frame, and so the inline sniffer claims this new frame.
Our stack is now looking like this:

  inline_frame -> normal_frame -> inline_frame

But, we have not yet computed the frame id for the outer most (on the
left) inline_frame.  After the frame sniffer has claimed the inline
frame GDB returns to compute_frame_id and calls inline_frame_this_id.

In here GDB calls get_prev_frame_always, which eventually ends up
in get_prev_frame_if_no_cycle again, where we create a raw frame and
call compute_frame_id.

Just like before, compute_frame_id tries to find an unwinder for this
new frame, it sees that the $pc is within both normal_frame and
inline_frame, but the next frame is, again, an INLINE_FRAME, so, just
like before the standard DWARF unwinder claims this frame.  Back in
compute_frame_id we again call the standard DWARF function to build
the frame_id for this new copy of normal_frame.

At this point the stack looks like this:

  normal_frame -> inline_frame -> normal_frame -> inline_frame

After compute_frame_id we return to get_prev_frame_if_no_cycle, where
we try to add the frame_id for the new normal_frame into the frame_id
cache, however, unlike before, we fail to add this frame_id as it is
a duplicate of the previous normal_frame frame_id.  Having found a
duplicate get_prev_frame_if_no_cycle unlinks the new frame from the
stack, and returns nullptr, the stack now looks like this:

  inline_frame -> normal_frame -> inline_frame

The nullptr result from get_prev_frame_if_no_cycle is fed back to
inline_frame_this_id, which forwards this to get_frame_id, which
immediately returns null_frame_id.  As null_frame_id is not considered
a valid frame_id, this is what triggers the assertion.

In summary then:

 - inline_frame_this_id currently assumes that as the inline frame
   exists, we will always get a valid frame back from
   get_prev_frame_always,

 - get_prev_frame_if_no_cycle currently assumes that it is safe to
   return nullptr when it sees a cycle.

Notice that in frame.c:compute_frame_id, this code:

  fi->this_id.value = outer_frame_id;
  fi->unwind->this_id (fi, &fi->prologue_cache, &fi->this_id.value);
  gdb_assert (frame_id_p (fi->this_id.value));

The assertion makes it clear that the this_id function must always
return a valid frame_id (e.g. null_frame_id is not a valid return
value), and similarly in inline_frame.c:inline_frame_this_id this
code:

  *this_id = get_frame_id (get_prev_frame_always (this_frame));
  /* snip comment */
  gdb_assert (frame_id_p (*this_id));

Makes it clear that every inline frame expects to be able to get a
previous frame, which will have a valid frame_id.

As I have discussed above, these assumptions don't currently hold in
all cases.

One possibility would be to move the call to get_prev_frame_always
forward from inline_frame_this_id to inline_frame_sniffer, however,
this falls foul of (in frame.c:frame_cleanup_after_sniffer) this
assertion:

  /* No sniffer should extend the frame chain; sniff based on what is
     already certain.  */
  gdb_assert (!frame->prev_p);

This assert prohibits any sniffer from trying to get the previous
frame, as getting the previous frame is likely to depend on the next
frame, I can understand why this assertion is a good thing, and I'm in
no rush to alter this rule.

The solution proposed here takes onboard feedback from both Pedro, and
Simon (see the links below).  The get_prev_frame_if_no_cycle function
is renamed to get_prev_frame_maybe_check_cycle, and will now not do
cycle detection for inline frames, even when we spot a duplicate frame
it is still returned.  This is fine, as, if the normal frame has a
duplicate frame-id then the inline frame will also have a duplicate
frame-id.  And so, when we reject the inline frame, the duplicate
normal frame, which is previous to the inline frame, will also be
rejected.

In inline-frame.c the call to get_prev_frame_always is no longer
nested inside the call to get_frame_id.  There are reasons why
get_prev_frame_always can return nullptr, for example, if there is a
memory error while trying to get the previous frame, if this should
happen then we now give a more informative error message.

Historical Links:

 Patch v2: https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html
 Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/180651.html
           https://sourceware.org/pipermail/gdb-patches/2021-July/180663.html

 Patch v3: https://sourceware.org/pipermail/gdb-patches/2021-July/181029.html
 Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/181035.html

 Additional input: https://sourceware.org/pipermail/gdb-patches/2021-September/182040.html

[gdb/testsuite] Fix gdb.base/dcache-flush.exp

When running test-case gdb.base/dcache-flush.exp on ubuntu 18.04.5, I run into:
...
(gdb) PASS: gdb.base/dcache-flush.exp: p var2
info dcache^M
Dcache 4096 lines of 64 bytes each.^M
Contains data for Thread 0x7ffff7fc6b80 (LWP 3551)^M
Line 0: address 0x7fffffffd4c0 [47 hits]^M
Line 1: address 0x7fffffffd500 [31 hits]^M
Line 2: address 0x7fffffffd5c0 [7 hits]^M
Cache state: 3 active lines, 85 hits^M
(gdb) FAIL: gdb.base/dcache-flush.exp: check dcache before flushing
...
The regexp expects "Contains data for process $decimal".

This is another case of thread_db_target::pid_to_str being used.

Fix this by updating the regexp.

Tested on x86_64-linux.

[gdb/testsuite] Test sw watchpoint in gdb.threads/process-dies-while-detaching.exp

The test-case gdb.threads/process-dies-while-detaching.exp takes about 20s
when using hw watchpoints, but when forcing sw watchpoints (using the patch
mentioned in PR28375#c0), the test-case takes instead 3m14s.

Also, it show a FAIL:
...
(gdb) continue^M
Continuing.^M
Cannot find user-level thread for LWP 10324: generic error^M
(gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process:
continue: watchpoint: continue
...
for which PR28375 was filed.

Modify the test-case to:
- add the hw/sw axis to the watchpoint testing, to ensure that we
  observe the sw watchpoint behaviour also on can-use-hw-watchpoints
  architectures.
- skip the hw breakpoint testing if not supported
- set the sw watchpoint later to avoid making the test
  too slow.  This still triggers the same PR, but now takes just 24s.

This patch adds a KFAIL for PR28375.

Tested on x86_64-linux.

gdb: fix indentation in gdbtypes.c

Change-Id: I7bfbb9d349a1f474256800c45e28fe3b1de08771

Automatic date update in version.in

Automatic date update in version.in

PowerPC: Enable mfppr mfppr32, mtppr and mtppr32 extended mnemonics on POWER5

SPR 896 and the mfppr mfppr32, mtppr and mtppr32 extended mnemonics were added
in ISA 2.03, so enable them on POWER5 and later.

opcodes/
* ppc-opc.c (powerpc_opcodes) <mfppr, mfppr32, mtppr, mtppr32>: Enable
on POWER5 and later.

gas/
* testsuite/gas/ppc/power5.s: New test.
* testsuite/gas/ppc/power5.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
* testsuite/gas/ppc/power7.s: Remove tests for mfppr, mfppr32, mtppr
and mtppr32.
* testsuite/gas/ppc/power7.d: Likewise.

[gdb/testsuite] Minimize gdb restarts

Minimize gdb restarts, applying the following rules:
- don't use prepare_for_testing unless necessary
- don't use clean_restart unless necessary

Also, if possible, replace build_for_executable + clean_restart
with prepare_for_testing for brevity.

Touches 68 test-cases.

Tested on x86_64-linux.

PR28346, segfault attempting to disassemble raw binary

Don't attempt to access elf_section_data for non-ELF sections.

PR 28346
* elf32-xtensa.c (xtensa_read_table_entries): Return zero entries
for non-ELF.

Automatic date update in version.in

gas/testsuite/ld-elf/dwarf2-21.d: Pass -W

Required for the expected "CU:" to be emitted for long
source-paths.  See binutils/dwarf.c:

 if (do_wide || strlen (directory) < 76)
   printf (_("CU: %s/%s:\n"), directory, file_table[0].name);
 else
   printf ("%s:\n", file_table[0].name);

See also commit 5f410aa50ce2c, "testsuite/ld-elf/pr26936.d:
Pass -W."

gas/ChangeLog:
* testsuite/ld-elf/dwarf2-21.d: Pass -W.

gdb: change thread_info::name to unique_xmalloc_ptr, add helper function

This started out as changing thread_info::name to a unique_xmalloc_ptr.
That showed that almost all users of that field had the same logic to
get a thread's name: use thread_info::name if non-nullptr, else ask the
target.  Factor out this logic in a new thread_name free function.  Make
the field private (rename to m_name) and add some accessors.

Change-Id: Iebdd95f4cd21fbefc505249bd1d05befc466a2fc

Move value_true to value.h

I noticed that value_true is declared in language.h and defined in
language.c.  However, as part of the value API, I think it would be
better in one of those files.  And, because it is very short, I
changed it to be an inline function in value.h.  I've also removed a
comment from the implementation, on the basis that it seems obsolete
-- if the change it suggests was needed, it probably would have been
done by now; and if it is needed in the future, odds are it would be
done differently anyway.

Finally, this patch also changes value_true and value_logical_not to
return a bool, and updates some uses.

Make dcache multi-target-safe

By inspection, I noticed that this code in dcache.c is not
multi-target-aware:

  /* If this is a different inferior from what we've recorded,
     flush the cache.  */

  if (inferior_ptid != dcache->ptid)

This doesn't take into account that threads of different targets may
have the same ptid.

Fixed by also storing/comparing the process_stratum_target.

Tested on x86-64-linux-gnu, native and gdbserver.

Change-Id: I4d9d74052c696b72d28cb1c77b697b911725c8d3

Fix 'FAIL: gdb.perf/disassemble.exp: python Disassemble().run()'

We currently have one FAIL while running "make check-perf":

  PerfTest::assemble, run ...
  python Disassemble().run()
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 64, in run
      self.warm_up()
    File "<string>", line 25, in warm_up
  gdb.error: No symbol "ada_evaluate_subexp" in current context.
  Error while executing Python code.
  (gdb) FAIL: gdb.perf/disassemble.exp: python Disassemble().run()
  ...

The gdb.perf/disassemble.exp testcase debugs GDB with itself, runs to
main, and then disassembles a few GDB functions.  The problem is that
most(!) functions it is trying to disassemble are now gone...

This commit fixes the issue by simply picking some other functions to
disassemble.

It would perhaps be better to come up with some test program to
disassemble, one that would stay the same throughout the years,
instead of disassembling GDB itself.  I don't know why that wasn't
done to begin with.  I'll have to leave that for another rainy day,
though.

gdb/testsuite/
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

* gdb.perf/disassemble.py (Disassemble::warm_up): Disassemble
evaluate_subexp_do_call instead of ada_evaluate_subexp.
(Disassemble::warm_up): Disassemble "captured_main",
"run_inferior_call" and "update_global_location_list" instead of
"evaluate_subexp_standard" and "c_parse_internal".

Change-Id: I89d1cca89ce2e495dea5096e439685739cc0d3df

Fix all PATH problems in testsuite/gdb.perf/

Currently "make check-perf" triggers ~40 PATH messages in gdb.sum:

  ...
  PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build/gdb/../../src/gdb/testsuite/gdb.perf/lib"))
  PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ())
  ...

This commit fixes them.  E.g. before/after gdb.sum diff:

 -PASS: gdb.perf/backtrace.exp: python import os, sys
 -PASS: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib"))
 -PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib"))
 -PASS: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ())
 -PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ())
 +PASS: gdb.perf/backtrace.exp: setup perftest: python import os, sys
 +PASS: gdb.perf/backtrace.exp: setup perftest: python sys.path.insert(0, os.path.abspath("${srcdir}/gdb.perf/lib"))
 +PASS: gdb.perf/backtrace.exp: setup perftest: python exec (open ('${srcdir}/gdb.perf/backtrace.py').read ())

gdb/testsuite/
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

* lib/perftest.exp (PerfTest::_setup_perftest): Use
with_test_prefix.  Add explicit test names to python invocations,
with "$srcdir" not expanded.

Change-Id: I50a31b04b7abdea754139509e4a34ae9263118a4

Fix all DUPLICATE problems in testsuite/gdb.perf/

Currently running "make check-perf" shows:

 ...
 # of duplicate test names       6008
 ...

All those duplicate test names come from gdb.perf/skip-command.exp.
This commit fixes them, using with_test_prefix.

gdb/testsuite/
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

* gdb.perf/skip-command.exp (run_skip_bench): Wrap each for
iteration in with_test_prefix.

Change-Id: I38501cf70bc6b60306ee7228996ee7bcd858dc1b

Fix handling of DW_AT_data_bit_offset

A newer version of GCC will now emit member locations using just
DW_AT_data_bit_offset, like:

 <3><14fe>: Abbrev Number: 1 (DW_TAG_member)
    <14ff>   DW_AT_name        : (indirect string, offset: 0x215e): nb_bytes
    <1503>   DW_AT_decl_file   : 1
    <1503>   DW_AT_decl_line   : 10
    <1504>   DW_AT_decl_column : 7
    <1505>   DW_AT_type        : <0x150b>
    <1509>   DW_AT_bit_size    : 31
    <150a>   DW_AT_data_bit_offset: 64

whereas earlier versions would emit something like:

 <3><164f>: Abbrev Number: 7 (DW_TAG_member)
    <1650>   DW_AT_name        : (indirect string, offset: 0x218d): nb_bytes
    <1654>   DW_AT_decl_file   : 1
    <1655>   DW_AT_decl_line   : 10
    <1656>   DW_AT_decl_column : 7
    <1657>   DW_AT_type        : <0x165f>
    <165b>   DW_AT_byte_size   : 4
    <165c>   DW_AT_bit_size    : 31
    <165d>   DW_AT_bit_offset  : 1
    <165e>   DW_AT_data_member_location: 8

That is, DW_AT_data_member_location is not emitted any more.  This is
a change due to the switch to DWARF 5 by default.

This change pointed out an existing bug in gdb, namely that the
attr_to_dynamic_prop depends on the presence of
DW_AT_data_member_location.  This patch moves the handling of
DW_AT_data_bit_offset into handle_data_member_location, and updates
attr_to_dynamic_prop to handle this new case.

A new test case is included.  This test fails with GCC 11, but passes
with an earlier version of GCC.

[gdb/testsuite] Don't leave gdb instance running after function_range

A typical dwarf assembly test-case start like this:
...
standard_testfile .c -debug.S

set asm_file [standard_output_file $srcfile2]
Dwarf::assemble $asm_file {
  ...
}

if { [prepare_for_testing "failed to prepare" ${testfile} \
  [list $srcfile $asm_file] {nodebug}] } {
    return -1
}
...

When accidentally using build_for_executable instead of
prepare_for_testing (or intentionally using it but forgetting to add
clean_restart $binfile or some such) the mistake may not be caught, because
another gdb instance is still running, and we may silently end up testing
compiler-generated DWARF.

This can be caused by something relatively obvious, like an earlier
prepare_for_testing or clean_restart, but also by something more obscure like
function_range, which may even be triggered by dwarf assembly like this:
...
  {MACRO_AT_func {main}}
...

Fix this by calling gdb_exit at the end of function_range.

Also fix the fallout of that in test-case gdb.dwarf2/dw2-bad-elf.exp, where a
get_sizeof call used the gdb instance left lingering by function_range.

[ A better and more complete fix would add a new proc get_exec_info, that would
be called at the start of the dwarf assembly body:
...
Dwarf::assemble $asm_file {
  get_exec_info {main foo} {int void*}
...
that would:
- do a prepare_for_testing with $srcfile (roughtly equivalent to what
  MACRO_AT_func does,
- call function_range for all functions main and foo, without starting a
  new gdb instance
- set corresponding variables at the call-site: main_start, main_len,
  main_end, foo_start, foo_len, foo_end.
- get size for types int and void*
- set corresponding variables at the call-site: int_size, void_ptr_size.
- do a gdb_exit. ]

Tested on x86_64-linux.

[gdb/testsuite] Use pie instead of -fpie/-pie

I noticed two test-cases where -fpie is used.  Using the canonical pie option
will usually get one -fPIE instead.

That choice is justified here in gdb_compile:
...
  # For safety, use fPIE rather than fpie. On AArch64, m68k, PowerPC
  # and SPARC, fpie can cause compile errors due to the GOT exceeding
  # a maximum size.  On other architectures the two flags are
  # identical (see the GCC manual). Note Debian9 and Ubuntu16.10
  # onwards default GCC to using fPIE.  If you do require fpie, then
  # it can be set using the pie_flag.
  set flag "additional_flags=-fPIE"
...

There is no indication that using -fpie rather than -fPIE is on purpose, so
use pie instead.

Tested on x86_64-linux.

[gdb/testsuite] Factor out dump_info in gdb.testsuite/dump-system-info.exp

Factor out new proc dump_info in test-case gdb.testsuite/dump-system-info.exp,
and in the process:
- fix a few typos
- remove unnecessary "test -r /proc/cpuinfo"

Tested on x86_64-linux.

Co-Authored-By: Pedro Alves <pedro@palves.net>

gdb/testsuite: Make it possible to use TCL variables in DWARF assembler loclists

It is currently not possible to use variables in locations lists.  For
example, with:

  diff --git a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
  index 6b4f5c8cbb8..cdbf948619f 100644
  --- a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
  +++ b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
  @@ -30,6 +30,8 @@ if {![dwarf2_support]} {
       return 0
   }

  +set myconst 0x123456
  +
   # Test with 32-bit and 64-bit DWARF.
   foreach_with_prefix is_64 {false true} {
       if { $is_64 } {
  @@ -49,6 +51,7 @@ foreach_with_prefix is_64 {false true} {
  global func1_addr func1_len
  global func2_addr func2_len
  global is_64
  +       global myconst

  # The CU uses the DW_FORM_loclistx form to refer to the .debug_loclists
  # section.
  @@ -107,7 +110,7 @@ foreach_with_prefix is_64 {false true} {
  list_ {
      # When in func1.
      start_length $func1_addr $func1_len {
  -                       DW_OP_constu 0x123456
  +                       DW_OP_constu $myconst
  DW_OP_stack_value
      }

we get:

  $ make check TESTS="*/loclists-multiple-cus.exp"
  ...
  gdb compile failed, build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S: Assembler messages:
  build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S:78: Error: leb128 operand is an undefined symbol: $myconst
  ...

That means $myconst was copied literally to the generated assembly
file.

This patch fixes it, by running subst on the location list body, in
the context of the caller.  The fix is applied to both
Dwarf::loclists::table::list_::start_length and
Dwarf::loclists::table::list_::start_end.

Reported-by: Zoran Zaric <Zoran.Zaric@amd.com>
Change-Id: I615a64431857242d9f477d5699e3732df1b31322

[gdb/testsuite] Fix DUPLICATEs in gdb.dwarf2/implptr-64bit.exp

When running test-case gdb.dwarf2/implptr-64bit.exp with target board
unix/-m32, I noticed:
...
DUPLICATE: gdb.dwarf2/implptr-64bit.exp: failed to prepare
...

Fix this by using with_test_prefix.

Tested on x86_64-linux.

[gdb/testsuite] Fix DUPLICATEs gdb.dwarf2/dw2-is-stmt.exp

Fix these DUPLICATEs by using with_test_prefix:
...
DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 1
DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 2
...

Tested on x86_64-linux.

[gdb/testsuite] Fix set $var val in gdb.dwarf2/dw2-is-stmt.exp

When doing a testrun with:
...
$ make check RUNTESTFLAGS=$(cd $src/gdb/testsuite/; echo gdb.dwarf2/*.exp)
...
I ran into:
...
ERROR: tcl error sourcing gdb.dwarf2/dw2-is-stmt.exp.
ERROR: expected integer but got "dw2-abs-hi-pc-world.c"
    while executing
"incr i"
...

The variable i is set in gdb.dwarf2/dw2-abs-hi-pc.exp, and leaks to
gdb.dwarf2/dw2-is-stmt.exp.  It's not removed by gdb_cleanup_globals because i
is set as global variable by runtest.exp, which does:
...
for { set i 0 } { $i < $argc } { incr i } {
...
at toplevel but forgets to unset the variable.

Fix this by removing '$' in front of the variable name when doing set:
...
-set $i 0
+set i 0
...

Tested on x86_64-linux.

[gdb/testsuite] Fix DUPLICATE in gdb.base/load-command.exp

Fix this duplicate:
...
DUPLICATE: gdb.base/load-command.exp: check initial value of the_variable
...
by using with_test_prefix.

Tested on x86_64-linux.

[gdb/testsuite] Use pie/nopie instead of ldflags=-pie/-no-pie

I noticed two test-case that use ldflags=-pie and ldflags-no-pie, instead of
the canonical pie and nopie options, which would typically also add
additional_flags=-fPIE respectively additional_flags=-fno-pie.

There is no indication that this is on purpose, so replace these with pie and
nopie.

Tested on x86_64-linux.

[gdb/testsuite] Add gdb.testsuite/dump-system-info.exp

When interpreting the testsuite results, it's often relevant what kind of
machine the testsuite ran on.  On a local machine one can just do
/proc/cpuinfo, but in case of running tests using a remote system
that distributes test runs to other remote systems that are not directly
accessible, that's not possible.

Fix this by dumping /proc/cpuinfo into the gdb.log, as well as lsb_release -a
and uname -a.

We could do this at the start of each test run, by putting it into unix.exp
or some such.  However, this might be too verbose, so we choose to put it into
its own test-case, such that it get triggered in a full testrun, but not when
running one or a subset of tests.

We put the test-case into the gdb.testsuite directory, which is currently the
only place in the testsuite where we do not test gdb.   [ Though perhaps this
could be put into a new gdb.info directory, since the test-case doesn't
actually test the testsuite. ]

Tested on x86_64-linux.

Automatic date update in version.in

Change pointer_type to a method of struct type

I noticed that pointer_type is declared in language.h and defined in
language.c.  However, it really has to do with types, so it should
have been in gdbtypes.h all along.

This patch changes it to be a method on struct type.  And, I went
through uses of TYPE_IS_REFERENCE and updated many spots to use the
new method as well.  (I didn't update ones that were in arch-specific
code, as I couldn't readily test that.)

[gdb/testsuite] Support -fPIE/-fno-PIE/-pie/-no-pie in gdb_compile_rust

When running gdb.rust/*.exp test-cases with target board unix/-fPIE/-pie, I
run into:
...
builtin_spawn -ignore SIGHUP rustc --color never gdb.rust/watch.rs \
  -g -lm -fPIE -pie -o outputs/gdb.rust/watch/watch^M
error: Unrecognized option: 'f'^M
^M
compiler exited with status 1
...

The problem is that -fPIE and -fpie are gcc options, but for rust we use
rustc, which has different compilation options.

Fix this by translating the gcc options to rustc options in gdb_compile_rust,
similar to how that is done for ada in target_compile_ada_from_dir.

Likewise for unix/-fno-PIE/-no-pie.

Tested on x86_64-linux, with:
- native
- unix/-fPIE/-pie
- unix/-fno-PIE/-no-pie
specifically, on openSUSE Leap 15.2 both with package gcc-PIE:
- installed (making gcc default to PIE)
- uninstalled (making gcc default to non-PIE).
and rustc 1.52.1.

[gdb/testsuite] Use pie instead of -fPIE -pie

Replace {additional_flags=-fPIE ldflags=-pie} with {pie}.

This makes sure that the test-cases properly error out when using target board
unix/-fno-PIE/-no-pie.

Tested on x86_64-linux.

[gdb/testsuite] Fix probe test in gdb.base/break-interp.exp

When running test-case gdb.base/break-interp.exp on ubuntu 18.04.5, we have:
...
 (gdb) bt^M
 #0  0x00007eff7ad5ae12 in ?? () from break-interp-LDprelinkNOdebugNO^M
 #1  0x00007eff7ad71f50 in ?? () from break-interp-LDprelinkNOdebugNO^M
 #2  0x00007eff7ad59128 in ?? () from break-interp-LDprelinkNOdebugNO^M
 #3  0x00007eff7ad58098 in ?? () from break-interp-LDprelinkNOdebugNO^M
 #4  0x0000000000000002 in ?? ()^M
 #5  0x00007fff505d7a32 in ?? ()^M
 #6  0x00007fff505d7a94 in ?? ()^M
 #7  0x0000000000000000 in ?? ()^M
 (gdb) FAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: \
         first backtrace: dl bt
...

Using the backtrace, the test-case tries to establish that we're stopped in
dl_main.

However, the backtrace only shows an address, because:
- the dynamic linker contains no minimal symbols and no debug info, and
- gdb is build without --with-separate-debug-dir so it can't find the
  corresponding .debug file, which does contain the mimimal symbols and
  debug info.

As in "[gdb/testsuite] Improve probe detection in gdb.base/break-probes.exp",
fix this by doing info probes and grepping for the address.

Tested on x86_64-linux.

[gdb/testsuite] Improve probe detection in gdb.base/break-probes.exp

When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have:
...
 (gdb) run^M
 Starting program: break-probes^M
 Stopped due to shared library event (no libraries added or removed)^M
 (gdb) bt^M
 #0  0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M
 #1  0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M
 #2  0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M
 #3  0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M
 #4  0x0000000000000001 in ?? ()^M
 #5  0x00007fffffffdaac in ?? ()^M
 #6  0x0000000000000000 in ?? ()^M
 (gdb) UNSUPPORTED: gdb.base/break-probes.exp: probes not present on this system
...

Using the backtrace, the test-case tries to establish that we're stopped in
dl_main, which is used as proof that we're using probes.

However, the backtrace only shows an address, because:
- the dynamic linker contains no minimal symbols and no debug info, and
- gdb is build without --with-separate-debug-dir so it can't find the
  corresponding .debug file, which does contain the mimimal symbols and
  debug info.

Fix this by instead printing the pc and grepping for the value in the
info probes output:
...
(gdb) p /x $pc^M
$1 = 0x7ffff7dd6e12^M
(gdb) info probes^M
Type Provider Name           Where              Object                      ^M
  ...
stap rtld     init_start     0x00007ffff7dd6e12 /lib64/ld-linux-x86-64.so.2 ^M
  ...
(gdb)
...

Tested on x86_64-linux.

[gdb/testsuite] Handle failing probe detection in gdb.base/break-probes.exp

When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have:
...
 (gdb) bt^M
 #0  0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M
 #1  0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M
 #2  0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M
 #3  0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M
 #4  0x0000000000000001 in ?? ()^M
 #5  0x00007fffffffdaac in ?? ()^M
 #6  0x0000000000000000 in ?? ()^M
 (gdb) FAIL: gdb.base/break-probes.exp: ensure using probes
...

The test-case intends to emit an UNTESTED in this case, but fails to do so
because it tries to do it in a regexp clause in a gdb_test_multiple, which
doesn't trigger.  Instead, a default clause triggers which produces the FAIL.

Also the use of UNTESTED is not appropriate, and we should use UNSUPPORTED
instead.

Fix this by silencing the FAIL, and emitting an UNSUPPORTED after the
gdb_test_multiple:
...
 if { ! $using_probes } {
+    unsupported "probes not present on this system"
     return -1
 }
...

Tested on x86_64-linux.

[gdb/testsuite] Use early-out style in gdb.base/break-probes.exp

Reduce indentation and improve readability in test-case
gdb.base/break-probes.exp by replacing:
...
if { <cond> } {
  <lots-of-code>
}
...
with:
...
if { ! <cond> } {
  return -1
}
<lots-of-code>
...

Tested on x86_64-linux.

Test that frame info/IDs are stable/consistent

This adds a testcase that tests that the unwinder produces consistent
frame info and frame IDs by making sure that "info frame" shows the
same result when stopped at a function (level == 0), compared to when
we find the same frame in the stack at a level > 0.

E.g., on x86-64, right after running to main, we see:

  (gdb) info frame
  Stack level 0, frame at 0x7fffffffd340:
   rip = 0x555555555168 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3
   source language c.
   Arglist at 0x7fffffffd330, args:
   Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340
   Saved registers:
    rbp at 0x7fffffffd330, rip at 0x7fffffffd338
  (gdb)

and then after continuing to a function called by main, and selecting
the "main" frame again, we see:

  (gdb) info frame
  Stack level 3, frame at 0x7fffffffd340:
   rip = 0x555555555172 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3
   caller of frame at 0x7fffffffd330
   source language c.
   Arglist at 0x7fffffffd330, args:
   Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340
   Saved registers:
    rbp at 0x7fffffffd330, rip at 0x7fffffffd338
  (gdb)

The only differences should be in the stack level, the 'rip = '
address, and the presence of the "caller of frame at" info.  All the
rest should be the same.  If it isn't, it probably means that the
frame base, the frame ID, etc. aren't stable & consistent.

The testcase exercises both the DWARF and the heuristic unwinders,
using "maint set dwarf unwinder on/off".

Tested on {x86-64 -m64, x86-64 -m32, Aarch64, Power8} GNU/Linux.

Change-Id: I795001c82cc70d543d197415e3f80ce5dc7f3452

Change get_ada_task_ptid parameter type

get_ada_task_ptid currently takes a 'long' as its 'thread' parameter
type.  However, on some platforms this is actually a pointer, and
using 'long' can sometimes end up with the value being sign-extended.
This sign extension can cause problems later, if the tid is then later
used as an address again.

This patch changes the parameter type to ULONGEST and updates all the
uses.  This approach preserves sign extension on the targets where it
is apparently intended, while avoiding it on others.

Co-Authored-By: John Baldwin <jhb@FreeBSD.org>

Change ptid_t::tid to ULONGEST

The ptid_t 'tid' member is normally used as an address in gdb -- both
bsd-uthread and ravenscar-thread use it this way.  However, because
the type is 'long', this can cause problems with sign extension.

This patch changes the type to ULONGEST to ensure that sign extension
does not occur.

Remove defaulted 'tid' parameter to ptid_t constructor

I wanted to find, and potentially modify, all the spots where the
'tid' parameter to the ptid_t constructor was used.  So, I temporarily
removed this parameter and then rebuilt.

In order to make it simpler to search through the "real" (nonzero)
uses of this parameter, something I knew I'd have to do multiple
times, I removed any ", 0" from constructor calls.

Co-Authored-By: John Baldwin <jhb@FreeBSD.org>

Style the "XXX" text in ptype/o

This patch changes gdb to use the 'highlight' style on the "XXX" text
in the output of ptype/o.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.python/py-events.exp

With test-case gdb.python/py-events.exp on ubuntu 18.04.5 we run into:
...
(gdb) info threads^M
  Id   Target Id                                     Frame ^M
* 1    Thread 0x7ffff7fc3740 (LWP 31467) "py-events" do_nothing () at \
         src/gdb/testsuite/gdb.python/py-events-shlib.c:19^M
(gdb) FAIL: gdb.python/py-events.exp: get current thread
...

The info thread commands uses "Thread" instead of "process" because
libpthread is already loaded:
...
new objfile name: /lib/x86_64-linux-gnu/libdl.so.2^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M
event type: new_objfile^M
new objfile name: /lib/x86_64-linux-gnu/libpthread.so.0^M
...
and consequently thread_db_target::pid_to_str is used.

Fix this by parsing the "Thread" expression.

Tested on x86_64-linux.

[gdb] Add maint selftest -verbose option

The print_one_insn selftest in gdb/disasm-selftests.c contains:
...
  /* If you want to see the disassembled instruction printed to gdb_stdout,
     set verbose to true.  */
  static const bool verbose = false;
...

Make this parameter available in the maint selftest command using a new option
-verbose, such that we can do:
...
(gdb) maint selftest -verbose print_one_insn
...

Tested on x86_64-linux.

dwarf2 sub-section test

This is a testcase for the bug fixed by commit 5b4846283c3d.  When
running the testcase on ia64 targets I found timeouts along with lots
of memory being consumed, due to ia64 gas not tracking text
sub-sections.  Trying to add nops for ".nop 16" in ".text 1" resulting
in them being added to subsegment 0, with no increase to subsegment 1
size.  This patch also fixes that problem.

Note that the testcase fails on ft32-elf, mn10200-elf, score-elf,
tic5x-elf, and xtensa-elf.  The first two are relocation errors, the
last three appear to be the .nop directive failing to emit the right
number of nops.  I didn't XFAIL any of them.

* config/tc-ia64.c (md): Add last_text_subseg.
(ia64_flush_insns, dot_endp): Use last_text_subseg.
(ia64_frob_label, md_assemble): Set last_text_subseg.
* testsuite/gas/elf/dwarf2-21.d,
* testsuite/gas/elf/dwarf2-21.s: New test.
* testsuite/gas/elf/elf.exp: Run it.

Fix x86 "FAIL: TLS -fno-pic -shared"

Fix a typo in commit 5d0869d9872a

* testsuite/ld-i386/tlsnopic.rd: Typo fix.

Automatic date update in version.in

Change the linker's heuristic for computing the entry point for binaries so that shared libraries default to an entry point of 0.

* ldlang.c (lang_end): When computing the entry point, only
try the start address of the entry section when creating an
executable.
* ld.texi (Entry point): Update description of heuristic used to
choose the entry point.
testsuite/ld-alpha/tlspic.rd: Update expected entry point address.
testsuite/ld-arm/tls-gdesc-got.d: Likewise.
testsuite/ld-i386/tlsnopic.rd: Likewise.
testsuite/ld-ia64/tlspic.rd: Likewise.
testsuite/ld-sparc/gotop32.rd: Likewise.
testsuite/ld-sparc/gotop64.rd: Likewise.
testsuite/ld-sparc/tlssunnopic32.rd: Likewise.
testsuite/ld-sparc/tlssunnopic64.rd: Likewise.
testsuite/ld-sparc/tlssunpic32.rd: Likewise.
testsuite/ld-sparc/tlssunpic64.rd: Likewise.
testsuite/ld-tic6x/shlib-1.rd: Likewise.
testsuite/ld-tic6x/shlib-1b.rd: Likewise.
testsuite/ld-tic6x/shlib-1r.rd: Likewise.
testsuite/ld-tic6x/shlib-1rb.rd: Likewise.
testsuite/ld-tic6x/shlib-noindex.rd: Likewise.
testsuite/ld-x86-64/pr14207.d: Likewise.
testsuite/ld-x86-64/tlsdesc.rd: Likewise.
testsuite/ld-x86-64/tlspic.rd: Likewise.
testsuite/ld-x86-64/tlspic2.rd: Likewise.