Use clean_restart in gdb.perf

Change gdb.perf to use clean_restart more consistently.

Use clean_restart in gdb.go

Change gdb.go to use clean_restart more consistently.

Use clean_restart in gdb.stabs

Change gdb.stabs to use clean_restart more consistently.

Use clean_restart in gdb.fortran

Change gdb.fortran to use clean_restart more consistently.

Use clean_restart in gdb.ada

Change gdb.ada to use clean_restart more consistently.

Use clean_restart in gdb.dwarf2

Change gdb.dwarf2 to use clean_restart more consistently.

Use clean_restart in gdb.reverse

Change gdb.reverse to use clean_restart more consistently.

Use clean_restart in gdb.arch

Change gdb.arch to use clean_restart more consistently.

Use clean_restart in gdb.guile

Change gdb.guile to use clean_restart more consistently.

Use clean_restart in gdb.threads

Change gdb.threads to use clean_restart more consistently.

Use clean_restart in gdb.objc

Change gdb.objc to use clean_restart more consistently.

Use clean_restart in gdb.trace

Change gdb.trace to use clean_restart more consistently.

Use clean_restart in gdb.opencl

Change gdb.opencl to use clean_restart more consistently.

Use clean_restart in gdb.linespec

Change gdb.linespec to use clean_restart more consistently.

Use clean_restart in gdb.pascal

Change gdb.pascal to use clean_restart more consistently.

Use mi_clean_restart more

This changes a number of MI tests to use mi_clean_restart rather than
separate calls.  This reduces the number of lines, which is nice, and
also provides a nicer model to copy for future tests.

Start gdb after building executable in mi-basics.exp

A lot of the MI tests start gdb and only then build the executable.
This just seemed weird to me, so I've fixed this up.  In this patch,
no other cleanups are done, the startup is just moved to a more
logical (to me) spot.

Remove unnecessary call to standard_testfile

This test does not build a program and does not need to call
standard_testfile.

Minor "require" fixups

I found a couple of spots that could use "require", and one spot where
hoisting the "require" closer to the top of the file made it more
clear.

Remove some dead code in gdb.fortran/info-types.exp

An early "return" in this test case prevents a test from running.
This seems to have been intentional and has been in place since:

commit d57cbee932f86df06251498daa93154046dc77c0
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date:   Tue Dec 3 13:18:43 2019 +0000

    gdb/testsuite/fortran: Fix info-modules/info-types for gfortran 8+

This patch removes the dead code.

Eliminate spurious returns from the test suite

A number of tests end with "return".  However, this is unnecessary.
This patch removes all of these.

Use clean_restart in gdb.dlang

Change gdb.dlang to use clean_restart more consistently.

Use ordinary calling convention for clean_restart

clean_restart accepts a single optional argument.  Rather than using
{args} and handling the argument by hand, change it to use Tcl's own
argument-checking.

Automatic date update in version.in

Free gas/dwarf2dbg.c dirs

Entries are allocated with xmemdup0.

* dwarf2dbg.c (dwarf2_cleanup): Free dirs entries.

Sanity check dwarf5 form of .file

There's a comment a few lines earlier saying that demand_copy_C_string
has already reported an error if it returns NULL.  Given the proximity
I decided not to duplicate the comment.

* dwarf2dbg.c (dwarf2_directive_filename): Check return of
demand_copy_C_string for file.

resolve gas shift expressions with large exponents to zero

* expr.c (resolve_expression <O_left_shift, O_right_shift>): Resolve
shifts exceeding bits in a valueT to zero.

segv in coff_aarch64_addr32nb_reloc

* coff-aarch64.c (coff_aarch64_addr32nb_reloc): When output_bfd
is NULL (which it is for objdump -W) get the output bfd via the
input section.

gdb/testsuite: initialize "correct" variable in gdb.cp/cpexprs.exp.tcl

Due to a GDB bug (visible when building with -D_GLIBCXX_DEBUG), GDB
crashes somewhere in the middle of gdb.cp/cpexprs.exp, and thus fails to
read the string, at gdb.cp/cpexprs.exp.tcl:725.  The "correct" variable
doesn't get set, and I then see this TCL error:

  ERROR: can't read "correct": no such variable

Avoid the TCL error by initializing the "correct" variable to a dummy
value.

Change-Id: I828968d9b2d105ef47f8da2ef598aa16a518c059

gdb/testsuite/dap: fix gdb.dap/basic-dap.exp disassembly test for PIE

Prior to this patch, I get:

    >>> {"seq": 17, "type": "request", "command": "disassemble", "arguments": {"memoryReference": "0x115d", "instructionCount": 1}}
    Content-Length: 147

    {"request_seq": 17, "type": "response", "command": "disassemble", "success": false, "message": "Cannot access memory at address 0x115d", "seq": 41}FAIL: gdb.dap/basic-dap.exp: disassemble one instruction success
    FAIL: gdb.dap/basic-dap.exp: instructions in disassemble output

The problem is that the PC to disassemble is taken from the breakpoint
insertion response, which happens before running.  With a PIE
executable, that PC is unrelocated, but the disassembly request happens
after relocation.

I chose to fix this by watching for a breakpoint changed event giving
the new breakpoint address, and recording the address from there.  I
think this is an interesting way to fix it, because it adds a bit of
test coverage, I don't think these events are checked right now.

Other ways to fix it would be:

 - Get the address by doing a breakpoint insertion after the program is
   started, or some other way.
 - Do the disassembly by symbol instead of by address.
 - Do the disassembly before running the program.

Change-Id: I3c396f796ac4c8b22e7dfd2fa1c5467f7a47e84e

gdb/testsuite/dap: make dap_wait_for_event_and_check return preceding messages

In the following patch, I change gdb.dap/basic-dap.exp such that after
waiting for some event, it checks if it received another event
meanwhile.  To help with this, make dap_wait_for_event_and_check and
_dap_dap_wait_for_event return a list with everything received before
the event of interest.  This is similar to what
dap_check_request_and_response returns.

Change-Id: I85c8980203a2dec833937e7552c2196bc137935d

gdb/testsuite/dap: rename dap_read_event to dap_wait_for_event_and_check

I think that name describes a bit better what the proc does, it is
similar to "wait_for" in tuiterm.exp.

Change-Id: Ie55aa011e6595dd1b5a874db13881ba572ace419

gdb/testsuite/dap: pass around dicts instead of TON objects

The DAP helper functions generally return TON objects.  However, callers
almost all immediately use ton::2dict to convert them to dicts, to
access their contents.  This commits makes things a bit simpler for them
by having function return dicts directly instead.

The downside is that the TON objects contain type information.  For
instance, a "2" in a TCL dict could have been the integer 2 or the
string "2" in JSON.  By converting to TCL dicts, we lose that
information.  If some tests specifically want to check the types of some
fields, I think we can add intermediary functions that return TON
objects, without having to complicate other callers who don't care.

Change-Id: I2ca47bea355bf459090bae8680c6a917350b5c3f

gdb/testsuite/dap: remove catch from dap_read_event

This catch didn't cause me any trouble, but for the same reason as the
preceding patch, I think it's a bit better to just let any exception
propagate, to make for easier debugging.

Change-Id: I1779e62c788b77fef2d50434edf4c3d2ec5e1c4c

gdb/testsuite/dap: make dap_request_and_response not catch / issue test result

Following some of my changes, dap_request_and_response was failing and I
didn't know why.  I think it's better to make it not catch any
exception, and just make it do a simple "send request, read response".
If an exception is thrown while sending a request or reading a response,
things are going really badly, it's not like we'll want to recover from
that and continue the test.

Change-Id: I27568d3547f753c3a74e3e5a730d38a8caef9356

gdb/testsuite/dap: write requests to gdb.log

This helps following what happens when reading gdb.log.  The downside is
that it becomes harder to tell what text is from GDB and what text is
going to GDB, but I think that seeing responses without seeing requests
is even more confusing.  At least, the lines are prefix with >>>, so
when you see this, you know that until the end of the line, it's
something that was sent to GDB, and not GDB output.

Change-Id: I1ba1acd8b16f4e64686c5ad268cc41082951c874

gdb/testsuite/dap: prefix some procs with _

Prefix some procs that are only used internally with an underscore, to
make it clear they are internal.  If they need to be used by some test
later, we can always un-prefix them.

Change-Id: Iacb8e77363b5d1f8b98d9ba5a6d115aee5c8925d

gdb/testsuite/dap: use gdb_assert in gdb.dap/basic-dap.exp

Use gdb_assert instead of manual pass/fail.

Change-Id: I71fbc4e37a0a1ef4783056c7424e932651fa397f

gprofng: PR30043 libgprofng.so.* are installed to a wrong location

gprofng/ChangeLog
2023-01-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30043
PR gprofng/28972
* src/Makefile.am: Use lib_LTLIBRARIES instead of pkglib_LTLIBRARIES.
* src/Makefile.in: Rebuild.

[gdb/testsuite] Add gdb.base/unwind-on-each-insn-{amd64,i386}.exp

The gcc 4.4.x (and earlier) compilers had the problem that the unwind info in
the epilogue was inaccurate.

In order to work around this in gdb, epilogue unwinders were added with a
higher priority than the dwarf unwinders in the amd64 and i386 targets:
- amd64_epilogue_frame_unwind, and
- i386_epilogue_frame_unwind.

Subsequently, the epilogue unwind info problem got fixed in gcc 4.5.0.

However, the epilogue unwinders prevented gdb from taking advantage of the
fixed epilogue unwind info, so the scope of the epilogue unwinders was
limited, bailing out for gcc >= 4.5.0.

There was no regression test added for this preference scheme, so if we now
declare epilogue unwind info from all gcc versions as trusted, no test will
start failing.

Fix this by adding an amd64 and i386 regression test for this.

I have no gcc 4.4.x lying around, so I fabricated the assembly files by:
- commenting out some .cfi directives to break the epilogue unwind info, and
- hand-editing the producer info to 4.4.7 to activate the fix.

Tested on x86_64-linux, target boards unix/{-m64,-m32}.

[gdb/testsuite] Add and use is_x86_64_m64_target

Add new proc is_x86_64_m64_target and use it where appropriate.

Tested on x86_64-linux.

Automatic date update in version.in

ld/testsuite: Add missing targets to PDB tests

ld: Add pdb support to aarch64-w64-mingw32

This extends PDB support to the aarch64 PE targets.

The changes to the test files are just to make it so they can be assembled as
either x86, x86_64, or aarch64, mainly by changing the comment style.
The only actual code change here is in adding the architecture constants
to pdb.c.

gdb/arm: Use new dwarf2 function cache

This patch resolves the performance issue reported in pr/29738 by
caching the values for the stack pointers for the inner frame.  By
doing so, the impact can be reduced to checking the state and
returning the appropriate value.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb: dwarf2 generic implementation for caching function data

When there is no dwarf2 data for a register, a function can be called
to provide the value of this register.  In some situations, it might
not be trivial to determine the value to return and it would cause a
performance bottleneck to do the computation each time.

This patch allows the called function to have a "cache" object that it
can use to store some metadata between calls to reduce the performance
impact of the complex logic.

The cache object is unique for each function and frame, so if there are
more than one function pointer stored in the dwarf2_frame_cache->reg
array, then the appropriate pointer will be supplied (the type is not
known by the dwarf2 implementation).

dwarf2_frame_get_fn_data can be used to retrieve the function unique
cache object.
dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the
function unique cache object.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

Clean up unusual code in mi-cmd-stack.c

I noticed some unusual code in mi-cmd-stack.c.  This code is a switch,
where one of the cases appears in the middle of another block.  It
seemed cleaner to me to have the earlier case just conditionally fall
through.

i386: Pass -Wl,--no-as-needed to compiler as needed

Pass -Wl,--no-as-needed to linker tests to fix

FAIL: Run pr19031
FAIL: Run got1
FAIL: Undefined weak symbol (-fPIE -no-pie)
FAIL: Undefined weak symbol (-fPIE -pie)

when --as-needed is passed to linker by compiler.

PR ld/30050
* testsuite/ld-i386/i386.exp: Pass -Wl,--no-as-needed to compiler
as needed.

Move target check into allow_altivec_tests

Pedro pointed out that only PPC can possibly have altivec, so we can
move the target check into allow_altivec_tests.

Use require with is_remote

This changes some tests to use require with 'is_remote', rather than
an explicit test.  This adds uniformity helps clean up more spots
where a test might exit early without any notification.

Add unsupported calls where needed

A number of tests will exit early without saying why.  This patch adds
"unsupported" at spots like this that I could readily find.

There are definitely more of these; for example dw2-ranges.exp fails
silently because a compilation fails.  I didn't attempt to address
these as that is a much larger task.

Introduce and use is_any_target

A few tests work on two different targets that can't be detected with
a single call to istarget -- that proc only accepts globs, not regular
expressions.

This patch introduces a new is_any_target proc and then converts these
tests to use it in a 'require'.

Use require with istarget

This changes many tests to use require when checking 'istarget'.  A
few of these conversions were already done in earlier patches.

No change was needed to 'require' to make this work, due to the way it
is written.  I think the result looks pretty clear, and it has the
bonus of helping to ensure that the reason that a test is skipped is
always logged.

Rename skip_vsx_tests to allow form

This renames skip_vsx_tests to allow_vsx_tests and updates it users to
use require.

Rename skip_power_isa_3_1_tests to allow form

This renames skip_power_isa_3_1_tests to allow_power_isa_3_1_tests and
updates its users to use require.

Rename skip_float_test to allow form

This renames skip_float_test to allow_float_test and updates its users
to use require.

Convert skip_altivec_tests to allow form

This renames skip_altivec_tests to allow_altivec_tests and updates its
users to use require.

[gdb/testsuite] Fix gdb.base/unwind-on-each-insn.exp for -m32

With test-case gdb.base/unwind-on-each-insn.exp and target board unix/-m32, I
now get:
...
 # of expected passes            25
...
instead of:
...
 # of expected passes            133
...
as I used to get before commit d25a8dbc7c3 ("[gdb/testsuite] Allow debug
srcfile2 in gdb.base/unwind-on-each-insn.exp"), due to the test-case trying to match
"rip = " and info frame printing "eip = " instead.

Fix this by dropping "rip" from the regexp.

Tested on x86_64-linux, target boards unix/{-m64,-m32}.

[gdb/testsuite] Allow debug srcfile2 in gdb.base/unwind-on-each-insn.exp

Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and
$srcfile2 without.

Occasionally, I try both files with debug info:
...
-             $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+             $srcfile $debug_flags $srcfile2 $debug_flags]]} {
...

This shortcuts the test due to no longer recognizing that stepi still lands
in foo.

Fix this by determining whether still in foo by checking the info frame output.

Tested on x86_64-linux.

[gdb/testsuite] Allow nodebug srcfile in gdb.base/unwind-on-each-insn.exp

Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and
$srcfile2 without.

Occasionally, I try both files with debug info:
...
-             $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+             $srcfile $debug_flags $srcfile2 $debug_flags]]} {
...
and both files without:
...
-             $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+             $srcfile $nodebug_flags $srcfile2 $nodebug_flags]]} {
...

In the latter case, I run into:
...
FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: bt 2
FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: up
...
due to a mismatch between the regexp and the different output due to using
nodebug.

Fix this by making the regexp less strict.

Tested on x86_64-linux.

gdb, i386: Update stale comment in i386-tdep.h.

The comment seems no longer valid, the functions technically check for
non-pseudo registers, like zmmh.  Which is a valid use case.

[gdb/testsuite] Analyze non-leaf fn in gdb.base/unwind-on-each-insn.exp

In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo
to check various invariants at each insn, in particular hoping to excercise
insns that modify stack and frame pointers.

Function foo is a leaf function, so add a non-leaf function bar, and step
through it as well (using nexti instead of stepi).

With the updated test-case, on powerpc64le-linux, I run into PR tdep/30049:
...
FAIL: bar: instruction 5: bt 2
FAIL: bar: instruction 5: up
FAIL: bar: instruction 5: [string equal $fid $::main_fid]
FAIL: bar: instruction 6: bt 2
FAIL: bar: instruction 6: up
FAIL: bar: instruction 6: [string equal $fid $::main_fid]
...

Tested on:
- x86_64-linux (-m64 and -m32)
- s390x-linux (-m64 and -m31)
- aarch64-linux
- powerpc64le-linux

[gdb/testsuite] Improve leaf fn in gdb.base/unwind-on-each-insn.exp

In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo
to check various invariants at each insn, in particular hoping to excercise
insns that modify stack and frame pointers.

For x86_64-linux, we have a reasonably complex foo (and similar for -m32):
...
  4004bc:       55                      push   %rbp
  4004bd:       48 89 e5                mov    %rsp,%rbp
  4004c0:       90                      nop
  4004c1:       5d                      pop    %rbp
  4004c2:       c3                      ret
...
Both stack pointer (%rsp) and frame pointer (%rbp) are modified.

Also for s390x-linux (and similar for -m31):
...
0000000001000668 <foo>:
 1000668:       e3 b0 f0 58 00 24       stg     %r11,88(%r15)
 100066e:       b9 04 00 bf             lgr     %r11,%r15
 1000672:       e3 b0 b0 58 00 04       lg      %r11,88(%r11)
 1000678:       07 fe                   br      %r14
...
Frame pointer (%r11) is modified.

Likewise for powerpc64le-linux:
...
00000000100006c8 <foo>:
    100006c8:   f8 ff e1 fb     std     r31,-8(r1)
    100006cc:   d1 ff 21 f8     stdu    r1,-48(r1)
    100006d0:   78 0b 3f 7c     mr      r31,r1
    100006d4:   00 00 00 60     nop
    100006d8:   30 00 3f 38     addi    r1,r31,48
    100006dc:   f8 ff e1 eb     ld      r31,-8(r1)
    100006e0:   20 00 80 4e     blr
...
Both stack pointer (r1) and frame pointer (r31) are modified.

But for aarch64-linux, we have:
...
00000000004005fc <foo>:
  4005fc:       d503201f        nop
  400600:       d65f03c0        ret
...
There's no insn that modifies stack or frame pointer.

Fix this by making foo more complex, adding an (unused) argument:
...
0000000000400604 <foo>:
  400604:       d10043ff        sub     sp, sp, #0x10
  400608:       f90007e0        str     x0, [sp, #8]
  40060c:       d503201f        nop
  400610:       910043ff        add     sp, sp, #0x10
  400614:       d65f03c0        ret
...
such that the stack pointer (sp) is modified.

[ Note btw that we're seeing the effects of -momit-leaf-frame-pointer, with
-mno-omit-leaf-frame-pointer we have instead:
...
0000000000400604 <foo>:
  400604:       a9be7bfd        stp     x29, x30, [sp, #-32]!
  400608:       910003fd        mov     x29, sp
  40060c:       f9000fa0        str     x0, [x29, #24]
  400610:       d503201f        nop
  400614:       a8c27bfd        ldp     x29, x30, [sp], #32
  400618:       d65f03c0        ret
...
such that also the frame pointer (x29) is modified. ]

Having made foo more complex, we now run into the following fail on
x86_64/-m32:
...
FAIL: gdb.base/unwind-on-each-insn.exp: instruction 1: $sp_value == $main_sp
....

The problem is that the stack pointer has changed inbetween the sampling of
main_sp and *foo, in particular by the push insn:
...
 804841a:       68 c0 84 04 08          push   $0x80484c0
 804841f:       e8 10 00 00 00          call   8048434 <foo>
...

Fix this by updating main_sp.

On powerpc64le-linux, with gcc 7.5.0 I now run into PR tdep/30021:
...
FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: $fba_value == $main_fba
FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: [string equal $fid $main_fid]
...
but I saw the same failure before this commit with gcc 4.8.5.

Tested on:
- x86_64-linux (-m64 and -m32)
- s390x-linux (-m64 and -m31)
- powerpc64le-linux
- aarch64-linux

Also I've checked that the test-case still functions as regression test for PR
record/16678 on x86_64.

gdb/tui: make use of a scoped_restore

Make use of a scoped_restore object in tui_mld_read_key instead of
doing a manual save/restore.

I don't think the existing code can throw an exception, so this is
just a cleanup rather than a bug fix.

There should be no user visible changes after this commit.

gdb/tui: better filtering of tab completion results for focus command

While working on the previous couple of commits, I noticed that the
'focus' command would happily suggest 'status' as a possible focus
completion, even though the 'status' window is non-focusable, and,
after the previous couple of commits, trying to focus the status
window will result in an error.

This commit improves the tab-completion results for the focus command
so that the status window is not included.

gdb/tui: convert if/error to an assert

While working on the previous commit, I realised that there was an
error in tui_set_focus_command that could never be triggered.

Since the big tui rewrite (adding dynamic layouts) it is no longer
true that there is a tui_win_info object for every window at all
times.  We now only create a tui_win_info object for a particular
window, when the window is part of the current layout.  As a result,
if we have a tui_win_info pointer, then the window must be visible
inside tui_set_focus_command (this function calls tui_enable as its
first action, which makes the current layout visible).

The gdb.tui/tui-focus.exp test script exercises this area of code, and
doesn't trigger the assert, nor do any of our other existing tui
tests.

gdb/testsuite/tui: more testing of the 'focus' command

I noticed that we didn't have many tests of the tui 'focus' command,
so I started adding some.  This exposed a bug in GDB; we are able to
focus windows that should not be focusable, e.g. the 'status' window.

This is harmless until we then do 'focus next' or 'focus prev', along
this code path we assert that the currently focused window is
focusable, which obviously, is not always true, so GDB fails with an
assertion error.

The fix is simple; add a check to the tui_set_focus_command function
to ensure that the selected window is focusable.  If it is not then an
error is thrown.  The new tests I've added cover this case.

gdb/testsuite: update gdb.tui/tui-nl-filtered-output.exp

Following on from the previous commit, in this commit I am updating
the test script gdb.tui/tui-nl-filtered-output.exp to take account of
the changes in commit:

  commit 9162a27c5f5828240b53379d735679e2a69a9f41
  Date:   Tue Nov 13 11:59:03 2018 -0700

      Change gdb test suite's TERM setting

In the above commit the TERM environment variable was changed to be
'dumb' by default, which means that tests, that previously activated
tui mode, no longer do unless TERM is set to 'ansi'.

As the gdb.tui/tui-nl-filtered-output.exp script didn't do this, the
test stopped working.  As the expect patterns in this script were
pretty generic no tests actually started failing, and we never
noticed.

In this commit I update the test script to correctly activate our
terminal emulator, the test continues to pass after this update, but
now we are testing in tui mode.

gdb/testsuite: update gdb.tui/tui-disasm-long-lines.exp

Following on from the previous commit, in this commit I am updating
the test script gdb.tui/tui-disasm-long-lines.exp to take account of
the changes in commit:

  commit 9162a27c5f5828240b53379d735679e2a69a9f41
  Date:   Tue Nov 13 11:59:03 2018 -0700

      Change gdb test suite's TERM setting

In the above commit the TERM environment variable was changed to be
'dumb' by default, which means that tests, that previously activated
tui mode, no longer do unless TERM is set to 'ansi'.

As the gdb.tui/tui-disasm-long-lines.exp script didn't do this, the
test stopped working.  As the expect patterns in this script were
pretty generic no tests actually started failing, and we never
noticed.

In this commit I update the script to use Term::clean_restart, which
correctly sets TERM to 'ansi'.  I've also added a check that the asm
box does appear on the screen, which should indicate that tui mode has
correctly activated.

However, I also notice that GDB doesn't appear to fully work
correctly.  The test should display the disassembly for the test
program, but it doesn't.

The test is trying to disassemble some code that (deliberately) uses a
very long symbol name, this eventually results in GDB entering
tui_source_window_base::show_source_content and trying to allocate an
ncurses pad in order to hold the current page of disassembler output.

Unfortunately, due to the very long line, the call to newpad fails,
meaning that tui_source_window_base::m_pad is nullptr.  Luckily non of
the following calls appear to crash when passed a nullptr, however,
all the output that is written to the pad is lost, which is why we
don't see any assembly code written to the screen.

As the test history indicates that the script was originally checking
for a crash in GDB when the long identifier was encountered, I think
there is value in just leaving the test as it is for now, I have a fix
for the issue of the newpad call failing, which I'll post in a follow
up commit later.

gdb/testsuite: extend gdb.tui/tui-layout.exp test script

In passing I noticed that the gdb.tui/tui-layout.exp test script was a
little strange, it tests the layout command multiple times, but never
sets up our ANSI terminal emulator, so every layout command fails with
a message about the terminal lacking the required abilities.

It turns out that this was caused by this commit:

  commit 9162a27c5f5828240b53379d735679e2a69a9f41
  Date:   Tue Nov 13 11:59:03 2018 -0700

      Change gdb test suite's TERM setting

This was when we changed the testsuite to set the TERM environment
variable to "dumb" by default.

After this, any tui test that didn't set the terminal mode back to
'ansi' would fail to activate tui mode.

For the tui-layout.exp test it just so happens that the test patterns
are generic enough that the test continued to pass, even after this
change.

In this commit I have updated the test so we now check the layout
command both with a 'dumb' terminal and with the 'ansi' terminal.
When testing with the 'ansi' terminal, I have some limited validation
that GDB correctly entered tui mode.

I figured that it is probably worth having at least one test in the
test suite that deliberately tries to enter tui mode in a dumb
terminal, it would be sad if we one day managed to break GDB such that
this caused a crash, and never noticed.

gdb/testsuite: rename test source file to match test script

The previous commit touched the source file for the test script
gdb.cp/cpcompletion.exp.  This source file is called pr9594.cc.  The
source file is only used by the one test script.

This commit renames the source file to cpcompletion.cc to match the
test script, this is more inline with how we name source files these
days.

gdb/testsuite: use test_gdb_complete_unique more in C++ tests

Spotted in gdb.cp/cpcompletion.exp that we could replace some uses of
gdb_test with test_gdb_complete_unique, this will extend the
completion testing to check tab-completion as well as completion using
the 'complete' command in some additional cases.

Automatic date update in version.in

gprofng: PR29521 [docs] man pages are not in the release tarball

gprofng/ChangeLog
2023-01-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29521
* configure.ac: Check if $MAKEINFO and $HELP2MAN are missing.
* Makefile.am: Build doc if $MAKEINFO exists.
* doc/gprofng.texi: Update documentation for gprofng.
* doc/Makefile.am: Build gprofng.1.
* src/Makefile.am: Move the build of gprofng.1 to doc/Makefile.am.
* configure: Rebuild.
* Makefile.in: Rebuild.
* doc/Makefile.in: Rebuild.
* src/Makefile.in: Rebuild.

libsframe/doc: fix some warnings

'make pdf' in libsframe shows some warnings, some of which (especially
the Overfull warnings) are causing undesirable effects on the rendered
output.  Few examples of the warnings:

  Underfull \hbox (badness 10000) in paragraph at lines 406--407
   @texttt pauth_

  Underfull \hbox (badness 10000) in paragraph at lines 407--410
   @textrm Specify which key is used for signing the return

  ...

  Overfull \hbox (2.0987pt too wide) in paragraph at lines 412--413
   @texttt fdetype[]|

  ...

  Overfull \hbox (28.87212pt too wide) in paragraph at lines 446--447
   @textrm SFRAME[]FDE[]TYPE[]PCMASK|

  ...

This patch adjusts column widths of the affected cells to fix a subset
of these warnings.  For the rest of the warnings, use explicit newline
command to fix them.

libsframe/
* doc/sframe-spec.texi: Fix various underfull and overfull
warnings.

Fix seg-fault when generating an empty DLL with LTO enabled.

ld   PR 29998
     * pe-dll.c (generate_reloc): Handle sections
     with no assigned output section.
     Terminate early of there are no relocs to put
     in the .reloc section.
     (pe_exe_fill_sections): Do not emit an empty
     .reloc section.

bfd  * cofflink.c (_bfd_coff_generic_relocate_section):
     Add an assertion that the output section is set
     for defined, global symbols.

gdb: some int to bool conversion

When building GDB with clang 16, I got this,

  CXX    maint.o
maint.c:1045:23: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
      m_space_enabled = 1;
                      ^ ~
maint.c:1057:22: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
      m_time_enabled = 1;
                     ^ ~
maint.c:1073:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
      m_symtab_enabled = 1;
                       ^ ~
3 errors generated.

Work around this by using bool bitfields instead.

Tested by rebuilding on x86_64-linux with clang 16 and gcc 12.

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

ld: Avoid magic numbers for subsystems in pe.em and pep.em

Automatic date update in version.in

ld: Set default subsystem for arm-pe to IMAGE_SUBSYSTEM_WINDOWS_GUI

This fixes the test failures introduced by 87a5cf5c, by changing the
default subsystem for arm-pe from 9 (IMAGE_SUBSYSTEM_WINDOWS_CE_GUI) to
2 (IMAGE_SUBSYSTEM_WINDOWS_GUI), which matches what happens with other
PE targets.

As far as I can tell there's no working modern Windows CE toolchain
knocking about anyway, so this change shouldn't inconvenience anyone.

Add support for secidx relocations to aarch64-w64-mingw32

This patch adds support for the .secidx directive and its corresponding
relocation to aarch64-w64-mingw32. As with x86, this is a two-byte LE
integer which gets filled in with the 1-based index of the output
section that a symbol ends up in.

This is needed for PDBs, which represent addresses as a .secrel32,
.secidx pair.

The test is substantially the same as for amd64, but with changes made
for padding and alignment.

[gdb/tdep, aarch64] Fix frame address of last insn

Consider the test-case test.c, compiled without debug info:
...
void
foo (const char *s)
{
}

int
main (void)
{
  foo ("foo");
  return 0;
}
...

Disassembly of foo:
...
0000000000400564 <foo>:
  400564:       d10043ff        sub     sp, sp, #0x10
  400568:       f90007e0        str     x0, [sp, #8]
  40056c:       d503201f        nop
  400570:       910043ff        add     sp, sp, #0x10
  400574:       d65f03c0        ret
...

Now, let's do "info frame" at each insn in foo, as well as printing $sp
and $x29 (and strip the output of info frame to the first line, for brevity):
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb) b *foo
Breakpoint 1 at 0x400564
(gdb) r
Starting program: a.out

Breakpoint 1, 0x0000000000400564 in foo ()
(gdb) display /x $sp
1: /x $sp = 0xfffffffff3a0
(gdb) display /x $x29
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400568 in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x000000000040056c in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400570 in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400574 in foo ()
1: /x $sp = 0xfffffffff3a0
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3b0:
 pc = 0x400574 in foo; saved pc = 0x40058c
(gdb) si
0x000000000040058c in main ()
1: /x $sp = 0xfffffffff3a0
2: /x $x29 = 0xfffffffff3a0
...

The "frame at" bit lists 0xfffffffff3a0 except at the last insn, where it
lists 0xfffffffff3b0.

The frame address is calculated here in aarch64_make_prologue_cache_1:
...
  unwound_fp = get_frame_register_unsigned (this_frame, cache->framereg);
  if (unwound_fp == 0)
    return;

  cache->prev_sp = unwound_fp + cache->framesize;
...

For insns after the prologue, we have cache->framereg == sp and
cache->framesize == 16, so unwound_fp + cache->framesize gives the wrong
answer once sp has been restored to entry value by the before-last insn.

Fix this by detecting the situation that the sp has been restored.

This fixes PRs tdep/30010 and tdep/30011.

This also fixes the aarch64 FAILs in gdb.reverse/solib-precsave.exp and
gdb.reverse/solib-reverse.exp I reported in PR gdb/PR29721.

Tested on aarch64-linux.
PR tdep/30010
PR tdep/30011
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30010
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30011

[gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp

One purpose of the gdb.base/unwind-on-each-insn.exp test-case is to test the
architecture-specific unwinders on foo, so unwind-on-each-insn-foo.c is
compiled with nodebug, to prevent the dwarf unwinders from taking effect.

For for instance gcc x86_64 though, -fasynchronous-unwind-tables is enabled by
default, generating an .eh_frame section contribution which might enable the
dwarf unwinders and bypass the architecture-specific unwinders.

Currently, that happens to be not the case due to the current implementation
of epilogue_unwind_valid, which assumes that in absence of debug info proving
that the compiler is gcc >= 4.5.0, the .eh_frame contribution is invalid.

That may change though, see PR30028, in which case
gdb.base/unwind-on-each-insn.exp stops being a regression test for commit
49d7cd733a7 ("Change calculation of frame_id by amd64 epilogue unwinder").

Fix this by making sure that we don't use .eh_frame info regardless of
epilogue_unwind_valid, simply by not generating it using
-fno-asynchronous-unwind-tables.

Tested on x86_64-linux, target boards unix/{-m64,-m32}, using compilers
gcc 7.5.0 and clang 13.0.1.

Updated Swedish translation for the binutils sub-directory

[gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp

In test-case gdb.base/unwind-on-each-insn.exp, we try to determine the last
disassembled insn in function foo.

This in it self is fragile, as demonstrated by commit 91836f41e20 ("Powerpc
fix for gdb.base/unwind-on-each-insn.exp").

The use of the last disassembled insn in the test-case is to stop stepping in
foo once reaching it.

However, the intent is to stop stepping just before returning to main.

There is no guarantee that the last disassembled insn:
- is actually executed
- is executed just before returning to main
- is executed only once.

Fix this by simplying the test-case to continue stepping till stepping out of
foo.

Tested on x86_64-linux.

[gdb/testsuite] Fix untested in gdb.base/frame-view.exp

When running test-case gdb.base/frame-view.exp, I see:
...
gdb compile failed, ld: frame-view0.o: in function `main':
frame-view.c:73: undefined reference to `pthread_create'
ld: frame-view.c:76: undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
UNTESTED: gdb.base/frame-view.exp: failed to prepare
...

Fix this by adding pthreads to the compilation flags.

Tested on x86_64-linux.

Fix objdump --reloc for specific symbol

If objdump is used with both --disassemble=symbol and --reloc options
skip relocations that have addresses before the symbol, so that they
are not displayed.

Automatic date update in version.in

Remove path name from test

The test suite reports several path names in tests.  I couldn't find
most of these, and I suspect they are false reports, but I did manage
to locate one.  This one is probably harmless, as I think the path
does not vary; but it's also easy to fix and suppress one warning.

Minor cleanup in gdb.btrace/enable.exp

I noticed a weird-looking bit of code in gdb.btrace/enable.exp that is
left over from an earlier change.  This patch moves the "!" inside the
braces, where it belongs.

Minor fixup in allow_aarch64_sve_tests

An earlier patch failed to update a string in allow_aarch64_sve_tests.

Automatic date update in version.in

Automatic date update in version.in

gdb: make frame_info_ptr auto-reinflatable

This is the second step of making frame_info_ptr automatic, reinflate on
demand whenever trying to obtain the wrapper frame_info pointer, either
through the get method or operator->.  Make the reinflate method
private, it is used as a convenience method in those two.

Add an "is_null" method, because it is often needed to know whether the
frame_info_ptr wraps an frame_info or is empty.

Make m_ptr mutable, so that it's possible to reinflate const
frame_info_ptr objects.  Whether m_ptr is nullptr or not does not change
the logical state of the object, because we re-create it on demand.  I
believe this is the right use case for mutable.

Change-Id: Icb0552d0035e227f81eb3c121d8a9bb2f9d25794
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb: make frame_info_ptr grab frame level and id on construction

This is the first step of making frame_info_ptr automatic.  Remove the
frame_info_ptr::prepare_reinflate method, move that code to the
constructor.

Change-Id: I85cdae3ab1c043c70e2702e7fb38e9a4a8a675d8
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb: make user-created frames reinflatable

This patch teaches frame_info_ptr to reinflate user-created frames
(frames created through create_new_frame, with the "select-frame view"
command).

Before this patch, frame_info_ptr doesn't support reinflating
user-created frames, because it currently reinflates by getting the
current target frame (for frame 0) or frame_find_by_id (for other
frames).  To reinflate a user-created frame, we need to call
create_new_frame, to make it lookup an existing user-created frame, or
otherwise create one.

So, in prepare_reinflate, get the frame id even if the frame has level
0, if it is user-created.  In reinflate, if the saved frame id is user
create it, call create_new_frame.

In order to test this, I initially enhanced the gdb.base/frame-view.exp
test added by the previous patch by setting a pretty-printer for the
type of the function parameters, in which we do an inferior call.  This
causes print_frame_args to not reinflate its frame (which is a
user-created one) properly.  On one machine (my Arch Linux one), it
properly catches the bug, as the frame is not correctly restored after
printing the first parameter, so it messes up the second parameter:

    frame
    #0  baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
    40        return z1.m + z2.n;
    (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame
    frame
    #0  baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
    40        return z1.m + z2.n;
    (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame again

However, on another machine (my Ubuntu 22.04 one), it just passes fine,
without the appropriate fix.  I then thought about writing a selftest
for that, it's more reliable.  I left the gdb.base/frame-view.exp pretty
printer test there, it's already written, and we never know, it might
catch some unrelated issue some day.

Change-Id: I5849baf77991fc67a15bfce4b5e865a97265b386
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb: make it possible to restore selected user-created frames

I would like to improve frame_info_ptr to automatically grab the
information needed to reinflate a frame, and automatically reinflate it
as needed.  One thing that is in the way is the fact that some frames
can be created out of thin air by the create_new_frame function.  These
frames are not the fruit of unwinding from the target's current frame.
These frames are created by the "select-frame view" command.

These frames are not correctly handled by the frame save/restore
functions, save_selected_frame, restore_selected_frame and
lookup_selected_frame.  This can be observed here, using the test
included in this patch:

    $ ./gdb --data-directory=data-directory -nx -q testsuite/outputs/gdb.base/frame-view/frame-view
    Reading symbols from testsuite/outputs/gdb.base/frame-view/frame-view...
    (gdb) break thread_func
    Breakpoint 1 at 0x11a2: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c, line 42.
    (gdb) run
    Starting program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/frame-view/frame-view

    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
    [New Thread 0x7ffff7cc46c0 (LWP 4171134)]
    [Switching to Thread 0x7ffff7cc46c0 (LWP 4171134)]

    Thread 2 "frame-view" hit Breakpoint 1, thread_func (p=0x0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
    42        foo (11);
    (gdb) info frame
    Stack level 0, frame at 0x7ffff7cc3ee0:
     rip = 0x5555555551a2 in thread_func (/home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42); saved rip = 0x7ffff7d4e8fd
     called by frame at 0x7ffff7cc3f80
     source language c.
     Arglist at 0x7ffff7cc3ed0, args: p=0x0
     Locals at 0x7ffff7cc3ed0, Previous frame's sp is 0x7ffff7cc3ee0
     Saved registers:
      rbp at 0x7ffff7cc3ed0, rip at 0x7ffff7cc3ed8
    (gdb) thread 1
    [Switching to thread 1 (Thread 0x7ffff7cc5740 (LWP 4171122))]
    #0  0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6

Here, we create a custom frame for thread 1 (using the stack from thread
2, for convenience):

    (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2

The first calls to "frame" looks good:

    (gdb) frame
    #0  thread_func (p=0x7ffff7d4e630) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
    42        foo (11);

But not the second one:

    (gdb) frame
    #0  0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6

This second "frame" command shows the current target frame instead of
the user-created frame.

It's not totally clear how the "select-frame view" feature is expected
to behave, especially since it's not tested.  I heard accounts that it
used to be possible to select a frame like this and do "up" and "down"
to navigate the backtrace starting from that frame.  The fact that
create_new_frame calls frame_unwind_find_by_frame to install the right
unwinder suggest that it used to be possible.  But that doesn't work
today:

    (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2
    (gdb) up
    Initial frame selected; you cannot go up.
    (gdb) down
    Bottom (innermost) frame selected; you cannot go down.

and "backtrace" always shows the actual thread's backtrace, it ignores
the user-created frame:

    (gdb) bt
    #0  0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6
    #1  0x00007ffff7d50403 in ?? () from /usr/lib/libc.so.6
    #2  0x000055555555521a in main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:56

I don't want to address all the `select-frame view` issues , but I think
we can agree that the "frame" command changing the selected frame, as
shown above, is a bug.  I would expect that command to show the
currently selected frame and not change it.

This happens because of the scoped_restore_selected_frame object in
print_frame_args.  The frame information is saved in the constructor
(the backtrace below), and restored in the destructor.

    #0  save_selected_frame (frame_id=0x7ffdc0020ad0, frame_level=0x7ffdc0020af0) at /home/simark/src/binutils-gdb/gdb/frame.c:1682
    #1  0x00005631390242f0 in scoped_restore_selected_frame::scoped_restore_selected_frame (this=0x7ffdc0020ad0) at /home/simark/src/binutils-gdb/gdb/frame.c:324
    #2  0x000056313993581e in print_frame_args (fp_opts=..., func=0x62100023bde0, frame=..., num=-1, stream=0x60b000000300) at /home/simark/src/binutils-gdb/gdb/stack.c:755
    #3  0x000056313993ad49 in print_frame (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1401
    #4  0x000056313993835d in print_frame_info (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1126
    #5  0x0000563139932e0b in print_stack_frame (frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:368
    #6  0x0000563139932bbe in print_stack_frame_to_uiout (uiout=0x611000016840, frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:346
    #7  0x0000563139b0641e in print_selected_thread_frame (uiout=0x611000016840, selection=...) at /home/simark/src/binutils-gdb/gdb/thread.c:1993
    #8  0x0000563139940b7f in frame_command_core (fi=..., ignored=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1871
    #9  0x000056313994db9e in frame_command_helper<frame_command_core>::base_command (arg=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1976

Since the user-created frame has level 0 (identified by the saved level
-1), lookup_selected_frame just reselects the target's current frame,
and the user-created frame is lost.

My goal here is to fix this particular problem.

Currently, select_frame does not set selected_frame_id and
selected_frame_level for frames with level 0.  It leaves them at
null_frame_id / -1, indicating to restore_selected_frame to use the
target's current frame.  User-created frames also have level 0, so add a
special case them such that select_frame saves their selected id and
level.

save_selected_frame does not need any change.

Change the assertion in restore_selected_frame that checks `frame_level
!= 0` to account for the fact that we can restore user-created frames,
which have level 0.

Finally, change lookup_selected_frame to make it able to re-create
user-created frame_info objects from selected_frame_level and
selected_frame_id.

Add a minimal test case for the case described above, that is the
"select-frame view" command followed by the "frame" command twice.  In
order to have a known stack frame to switch to, the test spawns a second
thread, and tells the first thread to use the other thread's top frame.

Change-Id: Ifc77848dc465fbd21324b9d44670833e09fe98c7
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb: add create_new_frame(frame_id) overload

The subsequent patches will need to call create_new_frame with an
existing frame_id representing a user created frame.  They could call
the existing create_new_frame, passing both addresses, but it seems
nicer to have a version of the function that takes a frame_id directly.

Change-Id: If31025314fec0c3e644703e4391a5ef8079e1a32
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb: add user-created frames to stash

A subsequent patch makes it possible for frame_info_ptr to reinflate
user-created frames.  If two frame_info_ptr objects wrapping the same
user-created frame_info need to do reinflation, we want them to end up
pointing to the same frame_info instance, and not create two separate
frame_infos.  Otherwise, GDB gets confused down the line, as the state
kept in one frame_info object starts differing from the other
frame_info.

Achieve this by making create_new_frame place the user-created frames in
the frame stash.  This way, when the second frame_info_ptr does
reinflation, it will find the existing frame_info object, created by the
other frame_info_ptr, in the frame stash.

To make the frame stash differentiate between regular and user-created
frame infos which would otherwise be equal, change frame_addr_hash and
frame_id::operator== to account for frame_id::user_created_p.

I made create_new_frame look up existing frames in the stash, and only
create one if it doesn't find one.  The goal is to avoid the
"select-frame view"/"info frame view"/"frame view" commands from
overriding existing entries into the stash, should the user specify the
same frame more than once.  This will also help in the subsequent patch
that makes frame_info_ptr capable of reinflating user-created frames.
It will be able to just call create_new_frame and it will do the right
thing.

Change-Id: I14ba5799012056c007b4992ecb5c7adafd0c2404
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb: add frame_id::user_created_p

Later in this series, we'll need to differentiate frame ids for regular
frames (obtained from the target state and unwinding from it) vs frame
ids for user-created frames (created with create_new_frame).  Add the
frame_id::user_created_p field to indicate a frame is user-created, and
set it in create_new_frame.

The field is otherwise not used yet, so not changes in behavior are
expected.

Change-Id: I60de3ce581ed01bf0fddb30dff9bd932840120c3
Reviewed-By: Bruno Larsen <blarsen@redhat.com>