[gdb/tui] Fix tui compact-source

Consider a hello.c, with less than 10 lines:
...
$ wc -l hello.c
8 hello.c
...
and compiled with -g into an a.out.

With compact-source off:
...
$ gdb -q a.out \
    -ex "set tui border-kind ascii" \
    -ex "maint set tui-left-margin-verbose on" \
    -ex "set tui compact-source off" \
    -ex "tui enable"
...
we get:
...
+-./data/hello.c-----------------------+
|___000005_{                           |
|___000006_  printf ("hello\n");       |
|___000007_  return 0;                 |
|___000008_}                           |
|___000009_                            |
|___000010_                            |
|___000011_                            |
...
but with compact-source on:
...
+-./data/hello.c-----------------------+
|___5{                                 |
|___6  printf ("hello\n");             |
|___7  return 0;                       |
|___8}                                 |
|___9                                  |
|___1                                  |
|___1                                  |
...

There are a couple of problems with compact-source.

First of all the documentation mentions:
...
The default display uses more space for line numbers and starts the
source text at the next tab stop; the compact display uses only as
much space as is needed for the line numbers in the current file, and
only a single space to separate the line numbers from the source.
...

The bit about the default display and the next tab stop looks incorrect.  The
source doesn't start at a tab stop, instead it uses a single space to separate
the line numbers from the source.

Then the documentation mentions that there's single space in the compact
display, but evidently that's missing.

Then there's the fact that the line numbers "10" and "11" are both abbreviated
to "1" in the compact case.

The abbreviation is due to allocating space for <lines in source>, which is
8 for this example, and takes a single digit.  The line numbers though
continue past the end of the file, so fix this by allocating space for
max (<lines in source>, <last line in window>), which in this example takes 2
digits.

The missing space is due to some confusion about what the "1" here in
tui_source_window::set_contents represent:
...
      double l = log10 ((double) offsets->size ());
      m_digits = 1 + (int) l;
...

It could be the trailing space that's mentioned in tui-source.h:
...
  /* How many digits to use when formatting the line number.  This
     includes the trailing space.  */
  int m_digits;
...

Then again, it could be part of the calculation for the number of digits
needed for printing.  With this minimal example:
...
int main () {
  for (int i = 8; i <= 11; ++i) {
    double l = log10 ((double) i);
    printf ("%d %d\n", i, (int)l);
  }
  return 0;
}
...
we get:
...
$ ./a.out
8 0
9 0
10 1
11 1
...
which shows that the number of digits needed for printing i is
"1 + (int)log10 ((double) i)".

Fix this by introducing named variables needed_digits and trailing_space, each
adding 1.

With the fixes, we get for compact-source on:
...
+-./data/hello.c-----------------------+
|___05_{                               |
|___06_  printf ("hello\n");           |
|___07_  return 0;                     |
|___08_}                               |
|___09_                                |
|___10_                                |
|___11_                                |
|...

Also fix the documentation and help text to actually match effect of
compact-source.

Tested on x86_64-linux.

Automatic date update in version.in

Support higher baud rates when they are defined

On Linux at least, baud rate codes are defined up to B4000000. Allow the
user to select them if they are present in the system headers.

Change-Id: I393ff32e4a4b6127bdf97e3306ad5b6ebf7c934e

gdb: fix use-after-free in check_longjmp_breakpoint_for_call_dummy

Commit 7a8de0c33019 ("Remove ALL_BREAKPOINTS_SAFE") introduced a
use-after-free in the breakpoints iterations (see below for full ASan
report).  This makes gdb.base/stale-infcall.exp fail when GDB is build
with ASan.

check_longjmp_breakpoint_for_call_dummy iterates on all breakpoints,
possibly deleting the current breakpoint as well as related breakpoints.
The problem arises when a breakpoint in the B->related_breakpoint chain
is also B->next.  In that case, deleting that related breakpoint frees
the breakpoint that all_breakpoints_safe has saved.

The old code worked around that by manually changing B_TMP, which was
the next breakpoint saved by the "safe iterator":

while (b->related_breakpoint != b)
  {
    if (b_tmp == b->related_breakpoint)
      b_tmp = b->related_breakpoint->next;
    delete_breakpoint (b->related_breakpoint);
  }

(Note that this seemed to assume that b->related_breakpoint->next was
the same as b->next->next, not sure this is guaranteed.)

The new code kept the B_TMP variable, but it's not useful in that
context.  We can't go change the next breakpoint as saved by the safe
iterator, like we did before.  I suggest fixing that by saving the
breakpoints to delete in a map and deleting them all at the end.

Here's the full ASan report:

    (gdb) PASS: gdb.base/stale-infcall.exp: continue to breakpoint: break-run1
    print infcall ()
    =================================================================
    ==47472==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000034980 at pc 0x563f7012c7bc bp 0x7ffdf3804d70 sp 0x7ffdf3804d60
    READ of size 8 at 0x611000034980 thread T0
        #0 0x563f7012c7bb in next_iterator<breakpoint>::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/next-iterator.h:66
        #1 0x563f702ce8c0 in basic_safe_iterator<next_iterator<breakpoint> >::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/safe-iterator.h:84
        #2 0x563f7021522a in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7611
        #3 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
        #4 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
        #5 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
        #6 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
        #7 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
        #8 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
        #9 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
        #10 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
        #11 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
        #12 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
        #13 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
        #14 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
        #15 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
        #16 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
        #17 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
        #18 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
        #19 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
        #20 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
        #21 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
        #22 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
        #23 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
        #24 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
        #25 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
        #26 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
        #27 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
        #28 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
        #29 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
        #30 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
        #31 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
        #32 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
        #33 0x563f7100ca06 in gdb_rl_callback_read_char_wrapper_noexcept /home/smarchi/src/binutils-gdb/gdb/event-top.c:192
        #34 0x563f7100cc5e in gdb_rl_callback_read_char_wrapper /home/smarchi/src/binutils-gdb/gdb/event-top.c:225
        #35 0x563f728c70db in stdin_event_handler /home/smarchi/src/binutils-gdb/gdb/ui.c:155
        #36 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
        #37 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
        #38 0x563f72fcb15c in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264
        #39 0x563f7177ec1c in start_event_loop /home/smarchi/src/binutils-gdb/gdb/main.c:412
        #40 0x563f7177f12e in captured_command_loop /home/smarchi/src/binutils-gdb/gdb/main.c:476
        #41 0x563f717846e4 in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1320
        #42 0x563f71784821 in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1339
        #43 0x563f6fcedfbd in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
        #44 0x7f5a7e43984f  (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
        #45 0x7f5a7e439909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
        #46 0x563f6fcedd84 in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0xafb0d84) (BuildId: 50bd32e6e9d5e84543e9897b8faca34858ca3995)

    0x611000034980 is located 0 bytes inside of 208-byte region [0x611000034980,0x611000034a50)
    freed by thread T0 here:
        #0 0x7f5a7fce312a in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:164
        #1 0x563f702bd1fa in momentary_breakpoint::~momentary_breakpoint() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:304
        #2 0x563f702771c5 in delete_breakpoint(breakpoint*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:12404
        #3 0x563f702150a7 in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7673
        #4 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
        #5 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
        #6 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
        #7 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
        #8 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
        #9 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
        #10 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
        #11 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
        #12 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
        #13 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
        #14 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
        #15 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
        #16 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
        #17 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
        #18 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
        #19 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
        #20 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
        #21 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
        #22 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
        #23 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
        #24 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
        #25 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
        #26 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
        #27 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
        #28 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
        #29 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543

    previously allocated by thread T0 here:
        #0 0x7f5a7fce2012 in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:95
        #1 0x563f7029a9a3 in new_momentary_breakpoint<program_space*&, frame_id&, int&> /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8129
        #2 0x563f702212f6 in momentary_breakpoint_from_master /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8169
        #3 0x563f70212db1 in set_longjmp_breakpoint_for_call_dummy() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7582
        #4 0x563f713804db in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1260
        #5 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
        #6 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
        #7 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
        #8 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
        #9 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
        #10 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
        #11 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
        #12 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
        #13 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
        #14 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
        #15 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
        #16 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
        #17 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
        #18 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
        #19 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
        #20 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
        #21 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
        #22 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)

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

Correct a spelling mistake in the binutils README file.

stack overflow in debug_write_type

Another fuzzer attack.  This one was a "set" with elements using an
indirect type pointing back at the set.  The existing recursion check
only prevented simple recursion.

* debug.c (struct debug_type_s): Add mark.
(debug_write_type): Set mark and check before recursing into
indirect types.

alpha-vms reloc sanity check

Stops fuzzed files triggering reads past the end of the reloc buffer.

* vms-alpha.c (alpha_vms_slurp_relocs): Sanity check reloc records.

regen ld/Makefile.in

Automatic date update in version.in

gdbserver: Clear upper ZMM registers in the right location.

This was previously clearing the upper 32 bytes of ZMM0-15 rather than
ZMM16-31.

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

x86-fbsd-nat: Add missing public label.

These two methods are both overrides of public methods in base
classes.

gdb: Avoid warning for the jump command inside an inline function.

When stopped inside an inline function, trying to jump to a different line
of the same function currently results in a warning about jumping to another
function.  Fix this by taking inline functions into account.

Before:
  Breakpoint 1, function_inline (x=510) at jump-inline.cpp:22
  22        a = a + x;             /* inline-funct */
  (gdb) j 21
  Line 21 is not in `function_inline(int)'.  Jump anyway? (y or n)

After:
  Breakpoint 2, function_inline (x=510) at jump-inline.cpp:22
  22        a = a + x;            /* inline-funct */
  (gdb) j 21
  Continuing at 0x400679.

  Breakpoint 1, function_inline (x=510) at jump-inline.cpp:21
  21        a += 1020 + a;                /* increment-funct */

This was regression-tested on X86-64 Linux.

Co-Authored-by: Cristian Sandu <cristian.sandu@intel.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

pe.em and pep.em make_import_fixup

This is a little cleanup that I made when looking at pr30343 that
makes it more obvious that make_import_fixup in both files are
identical (and in fact the new pep.em read_addend could be used in
both files).

* emultempl/pep.em (read_addend): Extract from..
(make_import_fixup): ..here.
* emultempl/pe.em (read_addend): Similarly.
(make_import_fixup): Similarly.  Add debug code from pep.em.

PR30343, LTO ignores linker reference to _pei386_runtime_relocator

Make a reference to _pei386_runtime_relocator before LTO recompilation.
This is done regardless of whether such a reference will be used,
because it can't be known whether it is needed before LTO.

I also found it necessary to enable long section names for the bfd
created in make_runtime_pseudo_reloc, because otherwise when writing
it out to the bfd-in-memory we get the section written as .rdata_r
which when read back in leads to a linker warning ".rdata_r: section
below image base" and likely runtime misbehaviour.

PR 30343
* emultempl/pe.em (make_runtime_ref): New function.
(gld${EMULATION_NAME}_before_plugin_all_symbols_read): New function.
(LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): Define.
* emultempl/pep.em: Similarly to pe.em.
* pe-dll.c (make_runtime_pseudo_reloc): Set long section names.

Automatic date update in version.in

Remove parameter from select_source_symtab

I noticed that select_source_symtab is only ever called with nullptr
as an argument, so this patch removes the parameter and associated
logic.

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

Remove ALL_BREAKPOINTS_SAFE

There's just a single remaining use of the ALL_BREAKPOINTS_SAFE macro;
this patch replaces it with a for-each and an explicit temporary
variable.

Remove ALL_DICT_SYMBOLS

This replaces ALL_DICT_SYMBOLS with an iterator so that for-each can
be used.

Remove ALL_OBJFILE_OSECTIONS

This replaces ALL_OBJFILE_OSECTIONS with an iterator so that for-each
can be used.

Rename objfile::sections

I think objfile::sections makes sense as the name of the method to
iterate over an objfile's sections, so this patch renames the existing
field to objfile::sections_start in preparation for that.

Automatic date update in version.in

Allow pretty-print of static members

Python pretty-printers haven't applied to static members for quite
some time.  I tracked this down to the call to cp_print_value_fields
in cp_print_static_field -- it doesn't let pretty-printers have a
chance to print the value.  This patch fixes the problem.

The way that static members are handled is very weird to me.  I tend
to think this should be done more globally, like in value_print.
However, I haven't made any big change.

Reviewed-by: Keith Seitz <keiths@redhat.com>
Tested-by: Keith Seitz <keiths@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30057

gas: documents .gnu_attribute Tag_GNU_MIPS_ABI_MSA

It is added since 2016 by
  Add support for .MIPS.abiflags and .gnu.attributes sections
  b52717c0e104eb603e8189c3c0d3658ef5d903f5
But never documented.

Automatic date update in version.in

Filter out types from DAP scopes request

The DAP scopes request examines the symbols in a block tree, but
neglects to omit types.  This patch fixes the problem.

Use discrete_position in ada-valprint.c

I found a couple of spots in ada-valprint.c that use an explicit loop,
but where discrete_position could be used instead.

Reviewed-by: Keith Seitz <keiths@redhat.com>

gdb/python: add mechanism to manage Python initialization functions

Currently, when we add a new python sub-system to GDB,
e.g. py-inferior.c, we end up having to create a new function like
gdbpy_initialize_inferior, which then has to be called from the
function do_start_initialization in python.c.

In some cases (py-micmd.c and py-tui.c), we have two functions
gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called
from finalize_python which is also in python.c.

This commit proposes a mechanism to manage these initialization and
finalization calls, this means that adding a new Python subsystem will
no longer require changes to python.c or python-internal.h, instead,
the initialization and finalization functions will be registered
directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c.

The initialization and finalization functions are managed through a
new class gdbpy_initialize_file in python-internal.h.  This class
contains a single global vector of all the initialization and
finalization functions.

In each Python sub-system we create a new gdbpy_initialize_file
object, the object constructor takes care of registering the two
callback functions.

Now from python.c we can call static functions on the
gdbpy_initialize_file class which take care of walking the callback
list and invoking each callback in turn.

To slightly simplify the Python sub-system files I added a new macro
GDBPY_INITIALIZE_FILE, which hides the need to create an object.  We
can now just do this:

  GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers);

One possible problem with this change is that there is now no
guaranteed ordering of how the various sub-systems are initialized (or
finalized).  To try and avoid dependencies creeping in I have added a
use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is
the same environment variable used in the generated init.c file.

Just like with init.c, when this environment variable is set we
reverse the list of Python initialization (and finalization)
functions.  As there is already a test that starts GDB with the
environment variable set then this should offer some level of
protection against dependencies creeping in - though for full
protection I guess we'd need to run all gdb.python/*.exp tests with
the variable set.

I have tested this patch with the environment variable set, and saw no
regressions, so I think we are fine right now.

One other change of note was for gdbpy_initialize_gdb_readline, this
function previously returned void.  In order to make this function
have the correct signature I've updated its return type to int, and we
now return 0 to indicate success.

All of the other initialize (and finalize) functions have been made
static within their respective sub-system files.

There should be no user visible changes after this commit.

gdb/testsuite: more newline pattern cleanup

After this commit:

  commit e2f620135d92f7cd670af4e524fffec7ac307666
  Date:   Thu Mar 30 13:26:25 2023 +0100

      gdb/testsuite: change newline patterns used in gdb_test

It was pointed out in PR gdb/30403 that the same patterns can be found
in other lib/gdb.exp procs and that it would probably be a good idea
if these procs remained in sync with gdb_test.  Actually, the bug
specifically calls out gdb_test_multiple when using with '-wrap', but
I found a couple of other locations in gdb_continue_to_breakpoint,
gdb_test_multiline, get_valueof, and get_local_valueof.

In all these locations one or both of the following issues are
addressed:

  1. A leading pattern of '[\r\n]*' is pointless.  If there is a
  newline it will be matched, but if there is not then the testsuite
  doesn't care.  Also, as expect is happy to skip non-matched output
  at the start of a pattern, if there is a newline expect is happy to
  skip over it before matching the rest.  As such, this leading
  pattern is removed.

  2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow
  unexpected blank lines at the end of a command's output, but also,
  if the pattern from the test script ends with a '\r', '\n', or '.'
  then these will partially match the trailing newline, with the
  remainder of the newline matched by the pattern from gdb.exp.  This
  split matching doesn't add any value, it's just something that has
  appeared as a consequence of how gdb.exp was originally written.  In
  this case the '\[\r\n\]*' is replaced with '\r\n'.

I've rerun the testsuite and fixed the regressions that I saw, these
were places where GDB emits a blank line at the end of the command
output, which we now need to explicitly match in the test script, this
was for:

  gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
  gdb.guile/guile.exp
  gdb.python/python.exp

Or a location where the test script was matching part of the newline
sequence, while gdb.exp was previously matching the remainder of the
newline sequence.  Now we rely on gdb.exp to match the complete
newline sequence, this was for:

  gdb.base/commands.exp

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

[gdb/testsuite] Generate long string in gdb.base/page.exp

I noticed in gdb.base/page.exp:
...
set fours [string repeat 4 40]
...
but then shortly afterwards:
...
    [list 1\r\n 2\r\n 3\r\n 444444444444444444444444444444]
...

Summarize the long string in the same way using string repeat:
...
    [list 1\r\n 2\r\n 3\r\n [string repeat 4 30]]
...

Tested on x86_64-linux.

gdb/testsuite: tighten patterns in build-id-no-debug-warning.exp

Tighten the expected output pattern in the test script:

  gdb.debuginfod/build-id-no-debug-warning.exp

While working on some other patch I broke GDB such that this warning:

  warning: "FILENAME": separate debug info file has no debug info

(which is generated in build-id.c) didn't actually include the
FILENAME any more -- yet this test script continued to pass.  It turns
out that this script doesn't actually check for FILENAME.

This commit extends the test pattern to check for the full warning
string, including FILENAME, and also removes some uses of '.*' to make
the test stricter.

Simplify decode_locdesc

While looking into another bug, I noticed that the DWARF cooked
indexer picks up an address for this symbol:

 <1><82>: Abbrev Number: 2 (DW_TAG_variable)
    <83>   DW_AT_specification: <0x9f>
    <87>   DW_AT_location    : 10 byte block: e 0 0 0 0 0 0 0 0 e0  (DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)
    <92>   DW_AT_linkage_name: (indirect string, offset: 0x156): _ZN9container8tlsvar_0E

This happens because decode_locdesc allows the use of
DW_OP_GNU_push_tls_address.

This didn't make sense to me.  I looked into it a bit more, and I
think decode_locdesc is used in three ways:

1. Find a constant address of a symbol that happens to be encoded as a
   location expression.

2. Find the offset of a function in a virtual table.  (This one should
   probably be replaced by code to just evaluate the expression in
   gnu-v3-abi.c -- but there's no point yet because no compiler
   actually seems to emit correct DWARF here, see the bug linked in
   the patch.)

3. Find the offset of a field, if the offset is a constant.

None of these require TLS.

This patch simplifies decode_locdesc by removing any opcodes that
don't fit into the above.  It also changes the API a little, to make
it less difficult to use.

Regression tested on x86-64 Fedora 36.

Simplify auto_load_expand_dir_vars and remove substitute_path_component

This simplifies auto_load_expand_dir_vars to first split the string,
then do any needed substitutions.  This was suggested by Simon, and is
much simpler than the current approach.

Then this patch also removes substitute_path_component, as it is no
longer called.  This is nice because it helps with the long term goal
of removing utils.h.

Regression tested on x86-64 Fedora 36.

[gdb/testsuite] Add gdb.base/wrap-line.exp

Add a test-case that tests prompt edit wrapping in CLI, both
for TERM=xterm and TERM=ansi, both with auto-detected and hard-coded width.

In the TERM=ansi case with auto-detected width we run into PR cli/30346, so
add a KFAIL for that failure mode.

Tested on x86_64-linux.

[gdb/testsuite] Add gdb.tui/wrap-line.exp

Add a test-case that tests prompt edit wrapping behaviour in the tuiterm, both
for CLI and TUI, both with auto-detected and hard-coded width.

In the CLI case with auto-detected width we run into PR cli/30411, so add a
KFAIL for that failure mode.

Tested on x86_64-linux.

Debug info is lost for functions only called from functions marked with cmse_nonsecure_entr

  PR 30354
  * elf32-arm.c (elf32_arm_gc_mark_extra_sections): If any debug sections are marked then rerun the extra marking in order to pick up any dependencies.

Automatic date update in version.in

Revert "gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp"

This reverts commit 476410b3bca1389ee69e9c8fa18aaee16793a56d.

One of Simon's recent commits (2a740b3ba4c9f39c86dd75e0914ee00942cab471)
changed the way recording a remote target works and fixed the underlying
issue of the bug, so the KFails can be removed from the test.

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

Don't treat references to compound values as "simple".

SUMMARY

The '--simple-values' argument to '-stack-list-arguments' and similar
GDB/MI commands does not take reference types into account, so that
references to arbitrarily large structures are considered "simple" and
printed. This means that the '--simple-values' argument cannot be used
by IDEs when tracing the stack due to the time taken to print large
structures passed by reference.

DETAILS

Various GDB/MI commands ('-stack-list-arguments', '-stack-list-locals',
'-stack-list-variables' and so on) take a PRINT-VALUES argument which
may be '--no-values' (0), '--all-values' (1) or '--simple-values' (2).
In the '--simple-values' case, the command is supposed to print the
name, type, and value of variables with simple types, and print only the
name and type of variables with compound types.

The '--simple-values' argument ought to be suitable for IDEs that need
to update their user interface with the program's call stack every time
the program stops. However, it does not take C++ reference types into
account, and this makes the argument unsuitable for this purpose.

For example, consider the following C++ program:

    struct s {
        int v[10];
    };

    int
    sum(const struct s &s)
    {
        int total = 0;
        for (int i = 0; i < 10; ++i) total += s.v[i];
        return total;
    }

    int
    main(void)
    {
        struct s s = { { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } };
        return sum(s);
    }

If we start GDB in MI mode and continue to 'sum', the behaviour of
'-stack-list-arguments' is as follows:

    (gdb)
    -stack-list-arguments --simple-values
    ^done,stack-args=[frame={level="0",args=[{name="s",type="const s &",value="@0x7fffffffe310: {v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}}"}]},frame={level="1",args=[]}]

Note that the value of the argument 's' was printed, even though 's' is
a reference to a structure, which is not a simple value.

See https://github.com/microsoft/MIEngine/pull/673 for a case where this
behaviour caused Microsoft to avoid the use of '--simple-values' in
their MIEngine debug adapter, because it caused Visual Studio Code to
take too long to refresh the call stack in the user interface.

SOLUTIONS

There are two ways we could fix this problem, depending on whether we
consider the current behaviour to be a bug.

1. If the current behaviour is a bug, then we can update the behaviour
   of '--simple-values' so that it takes reference types into account:
   that is, a value is simple if it is neither an array, struct, or
   union, nor a reference to an array, struct or union.

   In this case we must add a feature to the '-list-features' command so
   that IDEs can detect that it is safe to use the '--simple-values'
   argument when refreshing the call stack.

2. If the current behaviour is not a bug, then we can add a new option
   for the PRINT-VALUES argument, for example, '--scalar-values' (3),
   that would be suitable for use by IDEs.

   In this case we must add a feature to the '-list-features' command
   so that IDEs can detect that the '--scalar-values' argument is
   available for use when refreshing the call stack.

PATCH

This patch implements solution (1) as I think the current behaviour of
not printing structures, but printing references to structures, is
contrary to reasonable expectation.

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

Stop the linker from loosing the entry point for COFF/PE code when compiling with LTO enabled.

  PR 30300
  * emultempl/pep.em (set_entry_point): Add an undefined reference to the entry point if it has been constructed heuristically.
  * emultempl/pe.em (set_entry_point): Likewise.

ld: pru: Place exception-handling sections correctly

  * scripttempl/pru.sc (OUTPUT_SECTION_ALIGN): New helper variable to place at end of DMEM output sections.
  (.data): Use the helper variable.
  (.eh_frame): New output section.
  (.gnu_extab): Ditto.
  (.gcc_except_table): Ditto.
  (.resource_table): Use the helper variable.

RISC-V: tighten post-relocation-operator separator expectation

As per the spec merely a blank isn't okay as a separator, the operand
to the relocation function ought to be parenthesized. Enforcing this
then also eliminates an inconsistency in that

lui t0, %hi sym
lui t0, %hi 0x1000

were accepted, but

lui t0, %hi +sym
lui t0, %hi -0x1000

were not.

gas: fix building tc-bpf.c on s390x

char is unsigned on s390x, so there are a lot of warnings like:

    gas/config/tc-bpf.c: In function 'get_token':
    gas/config/tc-bpf.c:900:14: error: comparison is always false due to limited range of data type [-Werror=type-limits]
      900 |       if (ch == EOF || len > MAX_TOKEN_SZ)
          |              ^~

Change its type to int, like in the other similar code.

There is also:

    gas/config/tc-bpf.c:735:30: error: 'bpf_endianness' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      735 |    dst, be ? size[endianness - BPF_BE16] : size[endianness - BPF_LE16]);
          |                   ~~~~~~~~~~~^~~~~~~~~~

-Wmaybe-uninitialized doesn't seem to understand the FSM; just
initialize bpf_endianness to silence it.  Add an assertion to
build_bpf_endianness() in order to catch potential bugs.

MIPS: revert "default r6 if vendor is img"

In commit: 9171de358f230b64646bbb525a74e5f8e3dbe0dc,
The default output is set to r6 if the vendor is img,
It is ugly and should not be in upstream.

Let's revert it.

Automatic date update in version.in

[gdb/build] Fix frame_list position in frame.c

In commit 995a34b1772 ("Guard against frame.c destructors running before
frame-info.c's") the following problem was addressed.

The frame_info_ptr destructor:
...
  ~frame_info_ptr ()
  {
    frame_list.erase (frame_list.iterator_to (*this));
  }
...
uses frame_list, which is a static member of class frame_info_ptr,
instantiated in frame-info.c:
...
intrusive_list<frame_info_ptr> frame_info_ptr::frame_list;
...

Then there's a static frame_info_pointer variable named selected_frame in
frame.c:
...
static frame_info_ptr selected_frame;
...

Because the destructor of selected_frame uses frame_list, its destructor needs
to be called before the destructor of frame_list.

But because they're in different compilation units, the initialization order and
consequently destruction order is not guarantueed.

The commit fixed this by handling the case that the destructor of frame_list
is called first, adding a check on is_linked ():
...
   ~frame_info_ptr ()
   {
-    frame_list.erase (frame_list.iterator_to (*this));
+    /* If this node has static storage, it may be deleted after
+       frame_list.  Attempting to erase ourselves would then trigger
+       internal errors, so make sure we are still linked first.  */
+    if (is_linked ())
+      frame_list.erase (frame_list.iterator_to (*this));
   }
...

However, since then frame_list has been moved into frame.c, and
initialization/destruction order is guarantueed inside a compilation unit.

Revert aforementioned commit, and fix the destruction order problem by moving
frame_list before selected_frame.

Reverting the commit is another way of fixing the already fixed
Wdangling-pointer warning reported in PR build/30413, in a different way than
commit 9b0ccb1ebae ("Pass const frame_info_ptr reference for
skip_[language_]trampoline").

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tested on x86_64-linux.
PR build/30413
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413

gdb/show_args_command: print to the ui_file argument

The show_args_command uses gdb_printf without specifying the ui_file.
This means that it prints to gdb_stdout instead of the stream given as
an argument to the function.

This commit fixes this.

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

Make ar faster

 * archive.c (_bfd_write_archive_contents): Use a larger buffer in order to improve efficiency.

Pass const frame_info_ptr reference for skip_[language_]trampoline

g++ 13.1.1 produces a -Werror=dangling-pointer=

In file included from ../../binutils-gdb/gdb/frame.h:75,
                 from ../../binutils-gdb/gdb/symtab.h:40,
                 from ../../binutils-gdb/gdb/language.c:33:
In member function ‘void intrusive_list<T, AsNode>::push_empty(T&) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’,
    inlined from ‘void intrusive_list<T, AsNode>::push_back(reference) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’ at gdbsupport/intrusive_list.h:332:24,
    inlined from ‘frame_info_ptr::frame_info_ptr(const frame_info_ptr&)’ at gdb/frame.h:241:26,
    inlined from ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’ at gdb/language.c:530:49:
gdbsupport/intrusive_list.h:415:12: error: storing the address of local variable ‘<anonymous>’ in ‘frame_info_ptr::frame_list.intrusive_list<frame_info_ptr>::m_back’ [-Werror=dangling-pointer=]
  415 |     m_back = &elem;
      |     ~~~~~~~^~~~~~~
gdb/language.c: In function ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’:
gdb/language.c:530:49: note: ‘<anonymous>’ declared here
  530 |       CORE_ADDR real_pc = lang->skip_trampoline (frame, pc);
      |                           ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
gdb/frame.h:359:41: note: ‘frame_info_ptr::frame_list’ declared here
  359 |   static intrusive_list<frame_info_ptr> frame_list;
      |                                         ^~~~~~~~~~

Each new frame_info_ptr is being pushed on a static frame list and g++
cannot see why that is safe in case the frame_info_ptr is created and
destroyed immediately when passed as value.

It isn't clear why only in this one place g++ sees the issue (probably
because it can inline enough code in this specific case).

Since passing the frame_info_ptr as const reference is cheaper, use
that as workaround for this warning.

PR build/30413
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413

Tested-by: Kevin Buettner <kevinb@redhat.com>
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Reviewed-by: Tom Tromey <tom@tromey.com>

Improve the speed of computing checksums for COFF binaries.

 * coffcode.h (coff_read_word_from_buffer): New function.
 * coffcode.h (COFF_CHECKSUM_BUFFER_SIZE): New constant.
 * coffcode.h (coff_compute_checksum): Improve speed by reducing the number of seeks and reads used.

Remove unused args from bfd_make_debug_symbol

The ptr and size args are unused.  Make the function look the same as
bfd_make_empty_symbol.

Generated docs and include files

bfd/doc/chew.c extracts documentation from source code comments
annotated with keywords, and generates much of bfd.h and libbfd.h from
those same comments.  The docs have suffered from people (me too)
adding things like CODE_FRAGMENT to the source to put code into bfd.h
without realising that CODE_FRAGMENT also puts @example around said
code into the docs.  So we have random senseless things in the docs.
This patch fixes that problem (well, the senseless things from
CODE_FRAGMENT), moves most of the code out of bfd-in.h, and improves a
few chew.c features.  libbfd.h now automatically gets ATTRIBUTE_HIDDEN
prototypes, and indentation in bfd.h and libbfd.h is better.

Move bfd_alloc, bfd_zalloc and bfd_release to libbfd.c

These functions don't belong in opncls.c.

* libbfd-in.h (bfd_release): Delete prototype.
* opncls.c (bfd_alloc, bfd_zalloc, bfd_release): Move to..
* libbfd.c: ..here.  Include objalloc.c and provide bfd_release
with a FUNCTION comment.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.

Move bfd_elf_bfd_from_remote_memory to opncls.c

bfd_elf_bfd_from_remote_memory is just a wrapper, and the function
could be implemented for other formats.  Move it to opncls.c because
it acts a little like some of the other bfd_open* routines.  Also give
it the usual FUNCTION etc. comment so prototypes and docs are handled
automatically.

* elf.c (bfd_elf_bfd_from_remote_memory): Move to..
* opncls.c: ..here, add FUNCTION comment.
* bfd-in.h (bfd_elf_bfd_from_remote_memory): Delete prototype.
* bfd-in2.h: Regenerate.

hash.c: replace some unsigned long with unsigned int

* hash.c (higher_prime_number): Use uint32_t param, return value,
tables and variables.
(bfd_default_hash_table_size): Make it an unsigned int.
(bfd_hash_set_default_size): Use unsigned int param and return.
* bfd-in.h (bfd_hash_set_default_size): Update prototype.
* bfd-in2.h: Regenerate.

libbfc.c: Use stdint types for unsigned char and unsigned long

* libbfd.c (bfd_put_8): Use bfd_byte rather than unsigned char.
(bfd_get_8, bfd_get_signed_8): Likewise.
(_bfd_read_unsigned_leb128, _bfd_safe_read_leb128): Likewise.
(_bfd_read_signed_leb128): Likewise.
(bfd_getb24, bfd_getl24): Replace unsigned long with uint32_t.
(bfd_getb32, bfd_getl32): Likewise.
(bfd_getb_signed_32, bfd_getl_signed_32): Likewise.

Change signature of bfd crc functions

The crc calculated is 32 bits.  Replace uses of unsigned long with
uint32_t.  Also use bfd_byte* for buffers.

bfd/
* opncls.c (bfd_calc_gnu_debuglink_crc32): Use stdint types.
(bfd_get_debug_link_info_1, bfd_get_debug_link_info): Likewise.
(separate_debug_file_exists, bfd_follow_gnu_debuglink): Likewise.
(bfd_fill_in_gnu_debuglink_section): Likewise.
* bfd-in2.h: Regenerate.
gdb/
* auto-load.c (auto_load_objfile_script): Update type of
bfd_get_debug_link_info argument.
* symfile.c (find_separate_debug_file_by_debuglink): Likewise.
* gdb_bfd.c (get_file_crc): Update type of
bfd_calc_gnu_debuglink_crc32 argument.

_bfd_mips_elf_lo16_reloc vallo comment

This explains exactly why the high reloc adjustment is as it is,
replacing the rather nebulous existing comment.  I've also changed the
expression from (lo+0x8000)&0xffff to (lo&0xffff)^0x8000 which better
matches part of the standard 16-bit sign extension (resulting in
exactly the same value), and hoisted the calculation out of the loop.

* elfxx-mips.c (_bfd_mips_elf_lo16_reloc): Expand vallo
comment.  Hoist calculation out of loop.

gdb.base/watchpoint-unaligned.exp: Always initialize wpoffset_to_wpnum

Initialize wpoffset_to_wpnumto avoid TCL error which happens in some aarch64 types.

ERROR: in testcase /root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp
ERROR:  can't read "wpoffset_to_wpnum(1)": no such element in array
ERROR:  tcl error code TCL READ VARNAME
ERROR:  tcl error info:
can't read "wpoffset_to_wpnum(1)": no such element in array
    while executing

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

Reviewed-by: Luis Machado <luis.machado@arm.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

xcoffread.c: Fix -Werror=dangling-pointer= issue with main_subfile.

GCC 13 points out that main_subfile has local function scope, but a
pointer to it is assigned to the global inclTable array subfile
element field:

In function ‘void process_linenos(CORE_ADDR, CORE_ADDR)’,
    inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:727:19,
    inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:720:1:
xcoffread.c:629:37: error: storing the address of local variable ‘main_subfile’ in ‘*inclTable.19_45 + _28._inclTable::subfile’ [-Werror=dangling-pointer=]
  629 |               inclTable[ii].subfile = &main_subfile;
      |               ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
xcoffread.c: In function ‘void aix_process_linenos(objfile*)’:
xcoffread.c:579:18: note: ‘main_subfile’ declared here
  579 |   struct subfile main_subfile;
      |                  ^~~~~~~~~~~~
xcoffread.c:496:19: note: ‘inclTable’ declared here
  496 | static InclTable *inclTable;    /* global include table */
      |                   ^~~~~~~~~

Fix this by making main_subfile file static. And allocate and
deallocated together with inclTable in allocate_include_entry and
xcoff_symfile_finish. Adjust the use of main_subfile in
process_linenos to take a pointer to the subfile.

[gdb/testsuite] Use set in lmap in gdb.dwarf2/dw2-abs-hi-pc.exp

In gdb.dwarf2/dw2-abs-hi-pc.exp we do:
...
set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
...

The use of expr is not idiomatic.  Fix this by using set instead:
...
set sources [lmap i $sources { set tmp $srcdir/$subdir/$i }]
...

Reported-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Andreas Schwab <schwab@suse.de>

Fix Assertion pid != 0 failure in AIX.

In AIX if there is a main and a thread created from it , then once the
program completed execution and goes to pd_disable () inferior_ptid
had pid 0 leading to an assertion failure while finding the thread's data
in aix-thread.c file.

This patch is a fix for the same.

Remove error_stream

error_stream is trivial and only used in a couple of spots in
breakpoint.c.  This patch removes it in favor of just writing it out
at the spots where it was used.

Remove Dimity Diky as MSP430 maintainer.

gdb/testsuite: compile gdb.linespec/cp-completion-aliases.exp as C++

Noticed in passing that the prepare_for_testing call in
gdb.linespec/cp-completion-aliases.exp does not pass the 'c++' flag,
despite this being a C++ test.

I guess, as the source file has the '.cc' extension, all the compilers
are doing the right thing anyway -- the source file uses templates, so
is definitely being compiled as C++.

I noticed this when I tried to set CXX_FOR_TARGET (but not
CC_FOR_TARGET) and spotted that this script was still using the C
compiler.

Fixed in this commit by adding the 'c++' flag for prepare_for_testing.

Automatic date update in version.in

Document DAP 'launch' parameter

The Debugger Adapter Protocol defines a "launch" request but leaves
the parameters up to the implementation:

    Since launching is debugger/runtime specific, the arguments for
    this request are not part of this specification.

This patch adds some documentation for the parameter GDB currently
defines.  Note that I plan to add more parameters here, and perhaps
there will be other extensions in time as well.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

gdb: remove ui_interp_info

I don't think that having struct ui_interp_info separated from struct ui
is very useful.  As of today, it looks like an unnecessary indirection
layer.  Move the contents of ui_interp_info directly into struct ui, and
update all users.

Change-Id: I817ba6e047dbcc4ba15b666af184b40bfed7e521

gdb: store interps in an intrusive_list

Use intrusive_list, instead of hand-made linked list.

Change-Id: Idc857b40dfa3e3c35671045898331cca2c928097

gdb: move struct ui and related things to ui.{c,h}

I'd like to move some things so they become methods on struct ui.  But
first, I think that struct ui and the related things are big enough to
deserve their own file, instead of being scattered through top.{c,h} and
event-top.c.

Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc

Turn set_inferior_args_vector into method of inferior

This patch turns set_inferior_args_vector into an overload of
inferior::set_args.

Regression tested on x86-64 Fedora 36.

Remove evaluate_type

Like evaluate_expression, evaluate_type is also just a simple wrapper.
Removing it makes the code a little nicer.

Remove evaluate_expression

evaluate_expression is just a little wrapper for a method on
expression.  Removing it also removes a lot of ugly (IMO) calls to
get().

Remove op_name

op_name is only needed in a single place, so remove it and inline it
there.

Fix crash in Rust expression parser

A user found that an array expression with just a single value (like
"[23]") caused the Rust expression parser to crash.

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

Replace field_is_static with a method

This changes field_is_static to be a method on struct field, and
updates all the callers.  Most of this patch was written by script.

Regression tested on x86-64 Fedora 36.

Automatic date update in version.in

[gdb/tui] Fix TUI resizing for TERM=ansi

With TERM=ansi, when resizing a TUI window from LINES/COLUMNS 31/118
(maximized) to 20/78 (de-maximized), I get a garbled screen (that ^L doesn't
fix) and a message:
...
@@ resize done 0, size = 77x20
...
with the resulting width being 77 instead of the expected 78.

[ The discrepancy also manifests in CLI, filed as PR30346. ]

The discrepancy comes from tui_resize_all, where we ask readline for the
screen size:
...
   rl_get_screen_size (&screenheight, &screenwidth);
...

As it happens, when TERM is set to ansi, readline decides that the terminal
cannot auto-wrap lines, and reserves one column to deal with that, and as a
result reports back one less than the actual screen width:
...
$ echo $COLUMNS
78
$ TERM=xterm gdb -ex "show width" -ex q
Number of characters gdb thinks are in a line is 78.
$ TERM=ansi  gdb -ex "show width" -ex q
Number of characters gdb thinks are in a line is 77.
...

In tui_resize_all, we need the actual screen width, and using a screenwidth of
one less than the actual value garbles the screen.

This is currently not causing trouble in testing because we have a workaround
in place in proc Term::resize.  If we disable the workaround:
...
-       stty columns [expr {$_cols + 1}] < $::gdb_tty_name
+       stty columns $_cols < $::gdb_tty_name
...
and dump the screen we get the same type of screen garbling:
...
    0 +---------------------------------------+|
    1                                         ||
    2                                         ||
    3                                         ||
...

Another way to reproduce the problem is using command "maint info screen".
After starting gdb with TERM=ansi, entering TUI, and issuing the command, we
get:
...
Number of characters curses thinks are in a line is 78.
...
and after maximizing and demaximizing the window we get:
...
Number of characters curses thinks are in a line is 77.
...
If we use TERM=xterm, we do get the expected 78.

Fix this by:
- detecting when readline will report back less than the actual screen width,
- accordingly setting a new variable readline_hidden_cols,
- using readline_hidden_cols in tui_resize_all to fix the resize problem, and
- removing the workaround in Term::resize.

The test-case gdb.tui/empty.exp serves as regression test.

I've applied the same fix in tui_async_resize_screen, the new test-case
gdb.tui/resize-2.exp serves as a regression test for that change.  Without
that fix, we have:
...
FAIL: gdb.tui/resize-2.exp: again: gdb width 80
...

Tested on x86_64-linux.

PR tui/30337
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30337

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/readline.exp with stub-termcap

When doing a build which uses stub-termcap, we run into:
...
(gdb) set width 7
<b) FAIL: gdb.base/readline.exp: set width 7 (timeout)
...

Since readline can't detect very basic terminal support, it falls back on
horizontal scrolling.

Fix this by detecting the horizontal scrolling case, and skipping the
subsequent test.

Tested on x86_64-linux.

PR testsuite/30400
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30400

gdb: Fix building with latest libc++

Latest libc++[1] causes transitive include to <locale> when
<mutex> or <thread> header is included. This causes
gdb to not build[2] since <locale> defines isupper/islower etc.
functions that are explicitly macroed-out in safe-ctype.h to
prevent their use.
Use the suggestion from libc++ to include <locale> internally when
building in C++ mode to avoid build errors.
Use safe-gdb-ctype.h as the include instead of "safe-ctype.h"
to keep this isolated to gdb since rest of binutils
does not seem to use much C++.

[1]: https://reviews.llvm.org/D144331
[2]: https://issuetracker.google.com/issues/277967395

[gdb/testsuite] Fix gdb.ada/excep_handle.exp for updated gdb_test

Test-case gdb.ada/excep_handle.exp fails since commit e2f620135d9
("gdb/testsuite: change newline patterns used in gdb_test"):
...
(gdb) continue^M
Continuing.^M
^M
Catchpoint 2, exception at 0x00000000004020b6 in foo () at foo.adb:26^M
26            when Constraint_Error =>^M
(gdb) FAIL: gdb.ada/excep_handle.exp: continuing to first Constraint_Error \
  exception handlers
...

The output is supposed to be matched by:
...
gdb_test "continue" \
         "Continuing\.$eol$catchpoint_constraint_error_msg$eol.*" \
         "continuing to first Constraint_Error exception handlers"
...
but the $eol bit no longer matches due to the stricter matching introduced
in aforementioned commit.

Fix this by dropping the "$eol.*" bit.

Tested on x86_64-linux.

PR testsuite/30399
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30399

[gdb/build] Fix build without ncurses in maintenance_info_screen

With a build without ncurses we run into:
...
src/gdb/utils.c: In function ‘void maintenance_info_screen(const char*, int)’:
src/gdb/utils.c:1310:7: error: ‘COLS’ was not declared in this scope
       COLS);
       ^~~~
src/gdb/utils.c:1331:8: error: ‘LINES’ was not declared in this scope
        LINES);
        ^~~~~
...

Fix this by using HAVE_LIBCURSES.

Tested on x86_64-linux.

PR build/30391
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30391

[gdb/testsuite] Fix gdb.tui/main.exp without TUI

With a build with --disable-tui, we get:
...
(gdb) PASS: gdb.tui/main.exp: set interactive-mode off
maint set tui-left-margin-verbose on^M
Undefined maintenance set command: "tui-left-margin-verbose on".  \
  Try "help maintenance set".^M
(gdb) FAIL: gdb.tui/main.exp: maint set tui-left-margin-verbose on
...

Fix this by adding the missing "require allow_tui_tests".

Tested on x86_64-linux.

Automatic date update in version.in

gdb/mi: check thread exists when creating thread-specific b/p

I noticed the following behaviour:

  $ gdb -q -i=mi /tmp/hello.x
  =thread-group-added,id="i1"
  =cmd-param-changed,param="print pretty",value="on"
  ~"Reading symbols from /tmp/hello.x...\n"
  (gdb)
  -break-insert -p 99 main
  ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401198",func="main",file="/tmp/hello.c",fullname="/tmp/hello.c",line="18",thread-groups=["i1"],thread="99",times="0",original-location="main"}
  (gdb)
  info breakpoints
  &"info breakpoints\n"
  ~"Num     Type           Disp Enb Address            What\n"
  ~"1       breakpoint     keep y   0x0000000000401198 in main at /tmp/hello.c:18\n"
  &"../../src/gdb/thread.c:1434: internal-error: print_thread_id: Assertion `thr != nullptr' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."
  &"\n"
  &"----- Backtrace -----\n"
  &"Backtrace unavailable\n"
  &"---------------------\n"
  &"\nThis is a bug, please report it."
  &"  For instructions, see:\n"
  &"<https://www.gnu.org/software/gdb/bugs/>.\n\n"
  Aborted (core dumped)

What we see here is that when using the MI a user can create
thread-specific breakpoints for non-existent threads.  Then if we try
to use the CLI 'info breakpoints' command GDB throws an assertion.
The assert is a result of the print_thread_id call when trying to
build the 'stop only in thread xx.yy' line; print_thread_id requires a
valid thread_info pointer, which we can't have for a non-existent
thread.

In contrast, when using the CLI we see this behaviour:

  $ gdb -q /tmp/hello.x
  Reading symbols from /tmp/hello.x...
  (gdb) break main thread 99
  Unknown thread 99.
  (gdb)

The CLI doesn't allow a breakpoint to be created for a non-existent
thread.  So the 'info breakpoints' command is always fine.

Interestingly, the MI -break-info command doesn't crash, this is
because the MI uses global thread-ids, and so never calls
print_thread_id.  However, GDB does support using CLI and MI in
parallel, so we need to solve this problem.

One option would be to change the CLI behaviour to allow printing
breakpoints for non-existent threads.  This would preserve the current
MI behaviour.

The other option is to pull the MI into line with the CLI and prevent
breakpoints being created for non-existent threads.  This is good for
consistency, but is a breaking change for the MI.

In the end I figured that it was probably better to retain the
consistent CLI behaviour, and just made the MI reject requests to
place a breakpoint on a non-existent thread.  The only test we had
that depended on the old behaviour was
gdb.mi/mi-thread-specific-bp.exp, which was added by me in commit:

  commit 2fd9a436c8d24eb0af85ccb3a2fbdf9a9c679a6c
  Date:   Fri Feb 17 10:48:06 2023 +0000

      gdb: don't duplicate 'thread' field in MI breakpoint output

I certainly didn't intend for this test to rely on this feature of the
MI, so I propose to update this test to only create breakpoints for
threads that exist.

Actually, I've added a new test that checks the MI rejects creating a
breakpoint for a non-existent thread, and I've also extended the test
to run with the separate MI/CLI UIs, and then tested 'info
breakpoints' to ensure this command doesn't crash.

I've extended the documentation of the `-p` flag to explain the
constraints better.

I have also added a NEWS entry just in case someone runs into this
issue, at least then they'll know this change in behaviour was
intentional.

One thing that I did wonder about while writing this patch, is whether
we should treat requests like this, on both the MI and CLI, as another
form of pending breakpoint, something like:

  (gdb) break foo thread 9
  Thread 9 does not exist.
  Make breakpoint pending on future thread creation? (y or [n]) y
  Breakpoint 1 (foo thread 9) pending.
  (gdb) info breakpoints
  Num     Type           Disp Enb Address    What
  1       breakpoint     keep y   <PENDING>  foo thread 9

Don't know if folk think that would be a useful idea or not?  Either
way, I think that would be a separate patch from this one.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

gdb: make deprecated_show_value_hack static

The deprecated_show_value_hack function is now only used inside
cli-setshow.c, so lets make the function static to discourage its use
anywhere else.

There should be no user visible changes after this commit

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

gdb: make set/show inferior-tty work with $_gdb_setting_str

Like the previous two commits, this commit fixes set/show inferior-tty
to work with $_gdb_setting_str.

Instead of using a scratch variable which is then pushed into the
current inferior from a set callback, move to the API that allows for
getters and setters, and store the value directly within the current
inferior.

Update an existing test to check the inferior-tty setting.

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

gdb: make set/show cwd work with $_gdb_setting_str

The previous commit fixed set/show args when used with
$_gdb_setting_str, this commit fixes set/show cwd.

Instead of using a scratch variable which is then pushed into the
current inferior from a set callback, move to the API that allows for
getters and setters, and store the value directly within the current
inferior.

Update the existing test to check the cwd setting.

gdb: make set/show args work with $_gdb_setting_str

I noticed that $_gdb_setting_str was not working with 'args', e.g.:

  $ gdb -q --args /tmp/hello.x arg1 arg2 arg3
  Reading symbols from /tmp/hello.x...
  (gdb) show args
  Argument list to give program being debugged when it is started is "arg1 arg2 arg3".
  (gdb) print $_gdb_setting_str("args")
  $1 = ""

This is because the 'args' setting is implemented using a scratch
variable ('inferior_args_scratch') which is updated when the user does
'set args ...'.  There is then a function 'set_args_command' which is
responsible for copying the scratch area into the current inferior.

However, when the user sets the arguments via the command line the
scratch variable is not updated, instead the arguments are pushed
straight into the current inferior.

There is a second problem, when the current inferior changes the
scratch area is not updated, which means that the value returned will
only ever reflect the last call to 'set args ...' regardless of which
inferior is currently selected.

Luckily, the fix is pretty easy, set/show variables have an
alternative API which requires we provide some getter and setter
functions.  With this done the scratch variable can be removed and the
value returned will now always reflect the current inferior.

While working on set/show args I also rewrote show_args_command to
remove the use of deprecated_show_value_hack.

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

gdb: cleanup command creation in infcmd.c

In infcmd.c, in order to add command completion to some of the 'set'
commands, we are currently creating the command, then looking up the
command by calling lookup_cmd.

This is no longer necessary, we already return the relevant
cmd_list_element object when the set/show command is created, and we
can use that to set the command completion callback.

I don't know if there's actually any tests for completion of these
commands, but I manually checked, and each command still appears to
offer the expected filename completion.

There should be no user visible changes after this commit.

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

gdb/record-full: disable range stepping when resuming threads

I see these failures, when running with the native-gdbserver of
native-extended-gdbserver boards:

    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ...
    FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body
    FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body
    FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 GEP call from function body
    FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 50 from function body

Let's use this simpler program to illustrate the problem:

    int main()
    {
      int a = 362;
      a = a * 17;
      return a;
    }

It compiles down to:

    int a = 362;
    401689:       c7 45 fc 6a 01 00 00    movl   $0x16a,-0x4(%rbp)
    a = a * 17;
    401690:       8b 55 fc                mov    -0x4(%rbp),%edx
    401693:       89 d0                   mov    %edx,%eax
    401695:       c1 e0 04                shl    $0x4,%eax
    401698:       01 d0                   add    %edx,%eax
    40169a:       89 45 fc                mov    %eax,-0x4(%rbp)
    return a;
    40169d:       8b 45 fc                mov    -0x4(%rbp),%eax

When single stepping these lines, debugging locally, while recording,
these are the recorded instructions (basically one for each instruction
shown above):

    (gdb) maintenance print record-instruction 0
    4 bytes of memory at address 0x00007fffffffdc5c changed from: 6a 01 00 00
    Register rip changed: (void (*)()) 0x40169a <main+21>
    (gdb) maintenance print record-instruction -1
    Register rax changed: 5792
    Register eflags changed: [ PF AF IF ]
    Register rip changed: (void (*)()) 0x401698 <main+19>
    (gdb) maintenance print record-instruction -2
    Register rax changed: 362
    Register eflags changed: [ PF ZF IF ]
    Register rip changed: (void (*)()) 0x401695 <main+16>
    (gdb) maintenance print record-instruction -3
    Register rax changed: 4200069
    Register rip changed: (void (*)()) 0x401693 <main+14>
    (gdb) maintenance print record-instruction -4
    Register rdx changed: 140737488346696
    Register rip changed: (void (*)()) 0x401690 <main+11>
    (gdb) maintenance print record-instruction -5
    4 bytes of memory at address 0x00007fffffffdc5c changed from: 00 00 00 00
    Register rip changed: (void (*)()) 0x401689 <main+4>
    (gdb) maintenance print record-instruction -6
    Not enough recorded history

But when debugging remotely:

    (gdb) maintenance print record-instruction 0
    Register rdx changed: 140737488346728
    Register rip changed: (void (*)()) 0x401690 <main+11>
    (gdb) maintenance print record-instruction -1
    4 bytes of memory at address 0x00007fffffffdc7c changed from: 00 00 00 00
    Register rip changed: (void (*)()) 0x401689 <main+4>
    (gdb) maintenance print record-instruction -2
    Not enough recorded history

In this list, we only have entries for the beginning of each line.  This
is because of the remote target's support for range stepping.  The
record-full layer can only record instructions when the underlying
process target reports a stop.  With range stepping, the remote target
single-steps multiple instructions at a time, so the record-full target
doesn't get to see and record them all.

Fix this by making the record-full layer disable range-stepping
before handing the resume request to the beneath layer, forcing the
remote target to report stops for each instruction.

Change-Id: Ia95ea62720bbcd0b6536a904360ffbf839eb823d

Allow strings with printf/eval

PR 13098 explains that if a user attempts to use a string with either
`printf' (or `eval'), gdb returns an error (inferior not running):

(gdb) printf "%s\n", "hello"
evaluation of this expression requires the target program to be active

However, the parser can certainly handle this case:

(gdb) p "hello"
$1 = "hello"

This discrepancy occurs because printf_c_string does not handle
this specific case.  The passed-in value that we are attempting to print
as a string is TYPE_CODE_ARRAY but it's lval type is not_lval.

printf_c_string will only attempt to print a string from the value's
contents when !TYPE_CODE_PTR, lval is lval_internalvar, and the value's
type is considered a string type:

  if (value->type ()->code () != TYPE_CODE_PTR
      && value->lval () == lval_internalvar
      && c_is_string_type_p (value->type ()))
    {
      ...
    }

Otherwise, it attempts to read the value of the string from the target's
memory (which is what actually generates the "evaluation of this ..."
error message).

Move find_minimal_symbol_address to minsyms.c

I found find_minimal_symbol_address in parse.c, but it seems to me
that it belongs in minsyms.c.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>

Do not change type in get_discrete_low_bound

get_discrete_low_bound has this code:

    /* Set unsigned indicator if warranted.  */
    if (low >= 0)
      type->set_is_unsigned (true);

It's bad to modify a type in a getter like this, so this patch removes
this code.  FWIW I looked and this code has been there since at least
1999 (it was in the initial sourceware import).

Types in general would benefit from const-ification, which would
probably reveal more code like this, but I haven't attempted that.

Regression tested on x86-64 Fedora 36.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>

Remove @var from @defun in Python documentation

Eli pointed out that @var isn't needed in @defun in Texinfo.  This
patch removes the cases I found in python.texi.  I also renamed some
variables in one spot, because "-" isn't valid in a Python variable
name.

gdb/testsuite: additional test fixes after gdb_test changes

After this commit:

  commit e2f620135d92f7cd670af4e524fffec7ac307666
  Date:   Thu Mar 30 13:26:25 2023 +0100

      gdb/testsuite: change newline patterns used in gdb_test

There were some regressions in gdb.trace/*.exp tests when run with the
native-gdbserver board.  This commit fixes these regressions.

All the problems are caused by unnecessary trailing newline characters
included in the patterns passed to gdb_test.  After the above commit
the testsuite is stricter when matching trailing newlines, and so the
additional trailing newline characters are now causing the test to
fail.  Fix by removing all the excess trailing newline characters.

In some cases this cleanup means we should use gdb_test_no_output,
I've done that where appropriate.  In a couple of other places I've
made use of multi_line to better build the expected output pattern.

ld: Use run_cc_link_tests for PR ld/26391 tests

Use run_cc_link_tests for PR ld/26391 tests to compile PR ld/26391 tests
in C.

PR ld/30002
* testsuite/ld-elf/elf.exp: Use run_cc_link_tests for PR ld/26391
tests.

Fix a typo in gdb.texinfo.

RISC-V: Enable x0 base relaxation for relax_pc even if --no-relax-gp.

Let --no-relax-gp only disable the gp relaxation for lui and pcrel
relaxations, since x0 base and gp relaxations are different optimizations
in fact, but just use the same function to handle.

bfd/
* elfnn-riscv.c (_bfd_riscv_relax_pc): Like _bfd_riscv_relax_lui,
set gp to zero when --no-relax-gp, then we should still keep the
x0 base relaxation.
(_bfd_riscv_relax_section): Enable _bfd_riscv_relax_pc when
--no-relax-gp, we will disable the gp relaxation in the
_bfd_riscv_relax_pc.

RISC-V: Relax R_RISCV_[PCREL_]LO12_I/S to R_RISCV_GPREL_I/S for undefined weak.

bfd/
*elfnn-riscv.c (_bfd_riscv_relax_lui): For undefined weak symbol,
just relax the R_RISCV_LO12_I/S to R_RISCV_GPREL_I/S, and then don't
update the rs1 to zero until relocate_section.
(_bfd_riscv_relax_pc): Likewise, but for R_RISCV_PCREL_LO12_I/S.