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.

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.

Change-Id: I7bfbb9d349a1f474256800c45e28fe3b1de08771

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.

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.

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.

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 5f410aa5, "testsuite/ld-elf/pr26936.d:
Pass -W."

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

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

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.

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

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

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

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

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.

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.

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.

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>

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

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.

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.

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.

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.

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.

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.

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.)

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.

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.

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.

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.

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.

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.

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

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>

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.

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>

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