Do not put linkage names into .gdb_index

This changes the .gdb_index writer to skip linkage names.  This was
always done historically (though somewhat implicitly).

Emit a note warning the user that creating an executable stack because of a missing .note.GNU-stack section is deprecated.

PR 29072
bfd * elflink.c (bfd_elf_size_dynamic_sections): Display a note to the
user that the current ehaviour of creating an executable stack
because of a missing .note.GNU-stack section is deprecated and
will be changed in a future release.

binutils* testsuite/lib/binutils-common.exp (prune_warnings_extra): Filter
out notes about the executable stacjk behaviour beign deprecated.

ld * testsuite/ld-elf/pr29072.b.warn: Update to include the note
about the linker's behaviour being depreccated.

gdb/fortran: Support for assumed rank zero

If a variable is passed to function in FORTRAN as an argument the
variable is treated as an array with rank zero.  GDB currently does
not support the case for assumed rank 0.  This patch provides support
for assumed rank 0 and updates the testcase as well.

Without patch:
Breakpoint 1, arank::sub1 (a=<error reading variable:
  failed to resolve dynamic array rank>) at assumedrank.f90:11
11       PRINT *, RANK(a)
(gdb) p a
failed to resolve dynamic array rank
(gdb) p rank(a)
failed to resolve dynamic array rank

With patch:
Breakpoint 1, arank::sub1 (a=0) at assumedrank.f90:11
11       PRINT *, RANK(a)
(gdb) p a
$1 = 0
(gdb) p rank(a)
$2 = 0

gdb/infrun: assert !step_over_info_valid_p in restart_threads

While working in gdb/infrun.c:restart_threads, I was wondering what are
the preconditions to call the function.  It seems to me that
!step_over_info_valid_p should be a precondition (i.e. if we are doing
an inline step over breakpoint, we do not want to resume non stepping
threads as one of them might miss the breakpoint which is temporally
disabled).

To convince myself that this is true, I have added an assertion to
enforce this, and got one regression in the testsuite:

    FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (GDB internal error)

This call to restart_threads originates from handle_vfork_done which
does not check if a step over is active when restarting other threads:

    if (target_is_non_stop_p ())
      {
        scoped_restore_current_thread restore_thread;

        insert_breakpoints ();
        restart_threads (event_thread, event_thread->inf);
        start_step_over ();
      }

In this patch, I propose to:
- Call start_step_over before restart_threads.  If a step over is already
  in progress (as it is the case in the failing testcase),
  start_step_over return immediately, and there is no point in restarting
  all threads just to stop them right away for a step over breakpoint.
- Only call restart_threads if no step over is in progress at this
  point.

In this patch, I also propose to keep the assertion in restart_threads
to help enforce this precondition, and state it explicitly.

I have also checked all other places which call restart_threads, and
they all seem to check that there is no step over currently active
before doing the call.

As for infrun-related things, I am never completely sure I did not miss
something.  So as usual, all feedback and thoughts are very welcome.

Tested on x86_64-linux-gnu.

Change-Id: If5f5f98ec4cf9aaeaabb5e3aa88ae6ffd70d4f37

Automatic date update in version.in

gdb: move setbuf calls out of gdb_readline_no_editing_callback

After this commit:

  commit d08cbc5d3203118da5583296e49273cf82378042
  Date:   Wed Dec 22 12:57:44 2021 +0000

      gdb: unbuffer all input streams when not using readline

Issues were reported with some MS-Windows hosts, see the thread
starting here:

  https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html

Filed in bugzilla as: PR mi/29002

The problem seems to be that calling setbuf on terminal file handles
is not always acceptable, see this mail for more details:

  https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html

This commit does two things, first moving the setbuf calls out of
gdb_readline_no_editing_callback so that we don't end up calling
setbuf so often.

Then, for MS-Windows hosts, we don't call setbuf for terminals, this
appears to resolve the issues that have been reported.

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

Automatic date update in version.in

Automatic date update in version.in

gdb: handle_no_resumed: only update thread list of event target

When running:

    $ make check TESTS="gdb.multi/multi-re-run.exp" RUNTESTFLAGS="--target_board=native-gdbserver"

I get:

    target remote localhost:2347^M
    Remote debugging using localhost:2347^M
    Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
    Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.31.so...^M
    0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2^M
    (gdb) continue^M
    Continuing.^M
    Cannot execute this command while the target is running.^M
    Use the "interrupt" command to stop the target^M
    and then try again.^M
    (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: runto: run to all_started

The test does:

 - Connect to a remote target with inferior 2, continue and stop on the
   all_started function
 - Connect to a separate remote target / GDBserver instance with inferior 1,
   continue and (expect to) stop on the all_started function

The failure seen above happens when trying to continue inferior 1.

What happens is:

 - GDB tells inferior 1's remote target to continue
 - We go into fetch_inferior_event, try to get an event at random from
   the targets
 - do_target_wait happens to pick inferior 2's target
 - That target return TARGET_WAITKIND_NO_RESUMED, which makes sense:
   inferior 2 is stopped, that target has no resumed thread
 - handle_no_resumed tries to update the thread list of all targets:

   for (auto *target : all_non_exited_process_targets ())
     {
       switch_to_target_no_thread (target);
       update_thread_list ();
     }

 - When trying to update the thread list of inferior 1's target, it hits
   the "Cannot execute this command while the target is running" error.
   This target is working in "remote all-stop" mode, and it is currently
   waiting for a stop reply, so it can't send packets to update the
   thread list at this time.

To handle the problem described in the comment in handle_no_resumed, I
don't think it is necessary to update the thread list of all targets,
but only the event target.  That comment describes a kind of race
condition where some target reports a breakpoint hit for a thread and
then its last remaining resumed thread exits, so sends a "no resumed"
event.  If we ended up resuming the thread that hit a breakpoint, we
want to ignore the "no resumed" and carry on.

But I don't really see why we need to update the thread list on the
other targets.  I can't really articulate this, it's more a gut feeling,
maybe I just fail to imagine the situation where this is needed.  But
here is the patch anyway, so we can discuss it.  The patch changes
handle_no_resumed to only update the thread list of the event target.
This fixes the test run shown above.

The way I originally tried to fix this was to make
remote_target::update_thread_list return early if the target is
currently awaiting a stop reply, since there's no way it can update the
thread list at that time.  But that felt more like papering over the
problem.  I then thought that we probably shouldn't be asking the target
to update the thread list unnecessarily.

Change-Id: Ide3df22b4f556478e155ad1c67ad4b4fe7c26a58

gdbserver/linux: free process_info_private and arch_process_info when failing to attach

Running

  $ ../gdbserver/gdbserver --once --attach :1234 539436

with ASan while /proc/sys/kernel/yama/ptrace_scope is set to 1 (prevents
attaching) shows that we fail to free some platform-specific objects
tied to the process_info (process_info_private and arch_process_info):

    Direct leak of 32 byte(s) in 1 object(s) allocated from:
        #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
        #2 0x562eaf251548 in xcnew<process_info_private> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
        #3 0x562eaf22810c in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:426
        #4 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
        #5 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
        #6 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
        #7 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
        #8 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

    Indirect leak of 56 byte(s) in 1 object(s) allocated from:
        #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
        #2 0x562eaf2a0d79 in xcnew<arch_process_info> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
        #3 0x562eaf295e2c in x86_target::low_new_process() /home/simark/src/binutils-gdb/gdbserver/linux-x86-low.cc:723
        #4 0x562eaf22819b in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:428
        #5 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
        #6 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
        #7 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
        #8 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
        #9 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Those objects are deleted by linux_process_target::mourn, but that is
not called if we fail to attach, we only call remove_process.  I
initially fixed this by making linux_process_target::attach call
linux_process_target::mourn on failure (before calling error).  But this
isn't done anywhere else (including in GDB) so it would just be
confusing to do things differently here.

Instead, add a linux_process_target::remove_linux_process helper method
(which calls remove_process), and call that instead of remove_process in
the Linux target.  Move the free-ing of the extra data from the mourn
method to that new method.

Change-Id: I277059a69d5f08087a7f3ef0b8f1792a1fcf7a85

gdb: handle bracketed-paste-mode and EOF correctly

This commit replaces an earlier commit that worked around the issues
reported in bug PR gdb/28833.

The previous commit just implemented a work around in order to avoid
the worst results of the bug, but was not a complete solution.  The
full solution was considered too risky to merge close to branching GDB
12.  This improved fix has been applied after GDB 12 branched.  See
this thread for more details:

  https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html

This commit replaces this earlier commit:

  commit 74a159a420d4b466cc81061c16d444568e36740c
  Date:   Fri Mar 11 14:44:03 2022 +0000

      gdb: work around prompt corruption caused by bracketed-paste-mode

Please read that commit for a full description of the bug, and why is
occurs.

In this commit I extend GDB to use readline's rl_deprep_term_function
hook to call a new function gdb_rl_deprep_term_function.  From this
new function we can now print the 'quit' message, this replaces the
old printing of 'quit' in command_line_handler.  Of course, we only
print 'quit' in gdb_rl_deprep_term_function when we are handling EOF,
but thanks to the previous commit (to readline) we now know when this
is.

There are two aspects of this commit that are worth further
discussion, the first is in the new gdb_rl_deprep_term_function
function.  In here I have used a scoped_restore_tmpl to disable the
readline global variable rl_eof_found.

The reason for this is that, in rl_deprep_terminal, readline will
print an extra '\n' character before printing the escape sequence to
leave bracketed paste mode.  You might then think that in the
gdb_rl_deprep_term_function function, we could simply print "quit" and
rely on rl_deprep_terminal to print the trailing '\n'.  However,
rl_deprep_terminal only prints the '\n' when bracketed paste mode is
on.  If the user has turned this feature off, no '\n' is printed.
This means that in gdb_rl_deprep_term_function we need to print
"quit" when bracketed paste mode is on, and "quit\n" when bracketed
paste mode is off.

We could absolutely do that, no problem, but given we know how
rl_deprep_terminal is implemented, it's easier (I think) to just
temporarily clear rl_eof_found, this prevents the '\n' being printed
from rl_deprep_terminal, and so in gdb_rl_deprep_term_function, we can
now always print "quit\n" and this works for all cases.

The second issue that should be discussed is backwards compatibility
with older versions of readline.  GDB can be built against the system
readline, which might be older than the version contained within GDB's
tree.  If this is the case then the system readline might not contain
the fixes needed to support correctly printing the 'quit' string.

To handle this situation I have retained the existing code in
command_line_handler for printing 'quit', however, this code is only
used now if the version of readline we are using doesn't not include
the required fixes.  And so, if a user is using an older version of
readline, and they have bracketed paste mode on, then they will see
the 'quit' sting printed on the line below the prompt, like this:

  (gdb)
  quit

I think this is the best we can do when someone builds GDB against an
older version of readline.

Using a newer version of readline, or the patched version of readline
that is in-tree, will now give a result like this in all cases:

  (gdb) quit

Which is what we want.

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

readline: back-port changes needed to properly detect EOF

This commit is a partial back-port of this upstream readline commit:

  commit 002d31aa5f5929eb32d0e0e2e8b8d35d99e59961
  Author: Chet Ramey <chet.ramey@case.edu>
  Date:   Thu Mar 3 11:11:47 2022 -0500

      add rl_eof_found to public API; fix pointer aliasing problems  \
            with history-search-backward; fix a display problem with \
            runs of invisible characters at the end of a physical    \
            screen line

I have only pulled in the parts of this commit that relate to the new
rl_eof_found global, and the RL_STATE_EOF state flag.  These changes
are needed in order to fix PR cli/28833, and are discussed in this
thread to the bug-readline mailing list:

  https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html

The above commit is not yet in any official readline release, but my
hope is that now it has been merged into the readline tree it should
be safe enough to back port this fix to GDB's tree.

At some point in the future we will inevitably want to roll forward
the version of readline that we maintain in the binutils-gdb
repository.  When that day comes the changes in this commit can be
replaced with the latest upstream readline code, as I have not changed
the meaning of this code at all from what is in upstream readline.

This commit alone does not fix the PR cli/28833 issue, for that see
the next commit, which changes GDB itself.

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

gdb: improved EOF handling when using readline 7

In this commit:

  commit a6b413d24ccc5d76179bab866834e11fd6fec294
  Date:   Fri Mar 11 14:44:03 2022 +0000

      gdb: work around prompt corruption caused by bracketed-paste-mode

a change was made to GDB to work around bug PR gdb/28833.  The
consequence of this work around is that, when bracketed paste mode is
enabled in readline, and GDB is quit by sending EOF, then the output
will look like this:

  (gdb)
  quit

The ideal output, which is what we get when bracketed paste mode is
off, is this:

  (gdb) quit

The reason we need to make this change is explained in the original
commit referenced above.  What isn't mentioned in the above commit, is
that the change that motivated this work around was only added in
readline 8, older versions of readline don't require the change.

In later commits in this series I will add a fix to GDB's in-tree copy
of readline (this fix is back-ported from upstream readline), and then
I will change GDB so that, when using the (patched) in-tree readline,
we can have the ideal output in all cases.

However, GDB can be built against the system readline.  When this is
done, and the system readline is version 8, then we will still have to
use the work around (two line) style output.

But, if GDB is built against the system readline, and the system
readline is an older version 7 readline, then there's no reason why we
can't have the ideal output, after all, readline 7 doesn't include the
change that we need to work around.

This commit changes GDB so that, when using readline 7 we get the
ideal output in all cases.  This change is trivial (a simple check
against the readline version number) so I think this should be fine to
include.

For testing this commit, you need to configure GDB including the
'--with-system-readline' flag, and build GDB on a system that uses
readline 7, for example 'Ubuntu 18.04'.  Then run the test
'gdb.base/eof-exit.exp', you should expect everything to PASS.

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

gdb: prune inferiors at end of fetch_inferior_event, fix intermittent failure of gdb.threads/fork-plus-threads.exp

This test sometimes fail like this:

    info threads^M
      Id   Target Id         Frame ^M
      11.12 process 2270719   Couldn't get registers: No such process.^M
    (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: no threads left
    [Inferior 11 (process 2270719) exited normally]^M
    info inferiors^M
      Num  Description       Connection           Executable        ^M
    * 1    <null>                                 /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
      11   <null>                                 /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
    (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left (the program exited)

I can get it to fail quite reliably by pinning it to a core:

  $ taskset -c 5 make check TESTS="gdb.threads/fork-plus-threads.exp"

The previous attempt at fixing this was:

  https://sourceware.org/pipermail/gdb-patches/2021-October/182846.html

What we see is part due to a possible unfortunate ordering of events
given by the kernel, and what could be considered a bug in GDB.

The test program makes a number of forks, waits them all, then exits.
Most of the time, GDB will get and process the exit event for inferior 1
after the exit events of all the children.  But this is not guaranteed.
After the last child exits and is waited by the parent, the parent can
exit quickly, such that GDB collects from the kernel the exit events for
the parent and that child at the same time.  It then chooses one event
at random, which can be the event for the parent.  This will result in
the parent appearing to exit before its child.  There's not much we can
do about it, so I think we have to adjust the test to cope.

After expect has seen the "exited normally" notification for inferior 1,
it immediately does an "info thread" that it expects to come back empty.
But at this point, GDB might not have processed inferior 11's (the last
child) exit event, so it will look like there is still a thread.  Of
course that thread is dead, we just don't know it yet.  But that makes
the "no thread" test fail.  If the test waited just a bit more for the
"exited normally" notification for inferior 11, then the list of threads
would be empty.

So, first change, make the test collect all the "exited normally"
notifications for all inferiors before proceeding, that should ensure we
see an empty thread list.  That would fix the first FAIL above.

However, we would still have the second FAIL, as we expect inferior 11
to not be there, it should have been deleted automatically.  Inferior 11
is normally deleted when prune_inferiors is called.  That is called by
normal_stop, which is only called by fetch_inferior_event only if the
event thread completed an execution command FSM (thread_fsm).  But the
FSM for the continue command completed when inferior 1 exited.  At that
point inferior 11 was not prunable, as it still had a thread.  When
inferior 11 exits, prune_inferiors is not called.

I think that can be considered a GDB bug.  From the user point of view,
there's no reason why in one case inferior 11 would be deleted and not
in the other case.

This patch makes the somewhat naive change to call prune_inferiors in
fetch_inferior_event, so that it is called in this case.  It is placed
at this particular point in the function so that it is called after the
user inferior / thread selection is restored.  If it was called before
that, inferior 11 wouldn't be pruned, because it would still be the
current inferior.

Change-Id: I48a15d118f30b1c72c528a9f805ed4974170484a
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26272

Un-break the coff-pe-read.c build

This fixes a build breakage in my recent coff-pe-read.c change.

I'm sorry about this.  I don't understand how it happened, because I
definitely built and tested the series on Windows, and I didn't change
it before pushing.  Something must have gone wrong on the Windows
build, but I don't know what.  I'll investigate and and re-test to be
sure.

More const use and alloca avoidance in coff-pe-read.c

This changes another function in coff-pe-read.c to use 'const' more,
and to avoid the use of alloca by instead using std::string.

Use std::string in coff-pe-read.c

coff-pe-read.c uses xsnprintf and alloca, but using std::string is
better, and just as easy.  In general I think alloca is something to
be avoided, and unbounded uses especially so.

Remove a const-removing cast from coff-pe-read.c

coff-pe-read.c casts away const at one spot, but this is easily
replaced by calling bfd_get_filename directly in a couple of debugging
prints.

Simplify BFD section iteration in coff-pe-read.c

coff-pe-read.c iterates over BFD sections using bfd_map_over_sections,
but it's much simpler to use a for-each loop.  This allows for the
removal of helper functions and types.

Fix method naming bug in new DWARF indexer

Pedro pointed out that gdb-add-index is much slower with the new DWARF
indexer.  He also noticed that, in some cases, the generated
.gdb_index would have the wrong fully-qualified name for a method.

I tracked this down to a bug in the indexer.  If a type could have
methods but was marked as a declaration, the indexer was ignoring it.
However, this meant that the internal map to find the qualified name
was not updated for this container.

RISC-V: Add missing DECLARE_INSNs for Zicbo{m,p,z}

The recently added support for the Zicbo{m,p,z} extensions did not
include DECLARE_INSN() declarations for the instructions.
These declarations are needed by GDB's instruction detection code.
This patch adds them.

Signed-off-by: Christoph Muellner <cmuellner@gcc.gnu.org>

Automatic date update in version.in

Fix for gdb.base/solib-search.exp test.

The variable right_lib_flags is not being set correctly to define RIGHT.
The value RIGHT is needed to force the address of the library functions
lib1_func3 and lib2_func4 to occur at different address in the wrong and
right libraries.

With RIGHT defined correctly, functions lib1_func3 and lib2_func4 occur
at different addresses the test runs correctly on Powerpc.

The test needs the lib2 addresses to be different in the right and
wrong cases.  That is the point of introducing function lib2_spacer
with the ifdef RIGHT compiler directive.

On Intel, the ARRAY_SIZE of 1 versus 8192 is sufficient to get the
dynamic linker to move the addresses of the library.  You can also get
the same effect on PowerPC but you must use a value much larger than
8192.

The key thing is that the test was not properly setting RIGHT to
defined to get the lib2_spacer function on Intel and Powerpc.

Without the patch, we have the Intel backtrace for the bad libraries:

backtrace
#0  break_here () at /home/ ... /gdb/testsuite/gdb.base/solib-search.c:30
#1  0x00007ffff7fae156 in ?? ()
#2  0x00007fffffffc150 in ?? ()
#3  0x00007ffff7fbb156 in ?? ()
#4  0x00007fffffffc160 in ?? ()
#5  0x00007ffff7fae146 in ?? ()
#6  0x00007fffffffc170 in ?? ()
#7  0x00007ffff7fbb146 in ?? ()
#8  0x00007fffffffc180 in ?? ()
#9  0x0000555555555156 in main () at /home/ ... /binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:23
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) PASS: gdb.base/solib-search.exp: backtrace (with wrong libs) (data collection)

The backtrace on Intel with the good libraries is:

backtrace
#0  break_here () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:30
#1  0x00007ffff7fae156 in lib2_func4 () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib2.c:49
#2  0x00007ffff7fbb156 in lib1_func3 () at /.../gdb.base/solib-search-lib1.c:49
#3  0x00007ffff7fae146 in lib2_func2 () at /.../testsuite/gdb.base/solib-search-lib2.c:30
#4  0x00007ffff7fbb146 in lib1_func1 () at /.../gdb.base/solib-search-lib1.c:30
#5  0x0000555555555156 in main () at /...solib-search.c:23
(gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
PASS: gdb.base/solib-search.exp: backtrace (with right libs)

In one case the backtrace is correct and the other it
is wrong on Intel.  This is due to the fact that the ARRAY_SIZE caused
the dynamic linker to move the library function addresses around.  I
believe it has to do with the default size of the data and code
sections used by the dynamic linker.

So without the patch the backtrace on PowerPC looks like:

 backtrace
#0  break_here () at /.../solib-search.c:30
#1  0x00007ffff7f007f4 in lib2_func4 () at /.../solib-search-lib2.c:49
#2  0x00007ffff7f307f4 in lib1_func3 () at /.../solib-search-lib1.c:49
#3  0x00007ffff7f007ac in lib2_func2 () at /.../solib-search-lib2.c:30
#4  0x00007ffff7f307ac in lib1_func1 () at /.../solib-search-lib1.c:30
#5  0x000000001000074c in main () at /.../solib-search.c:23

for both the good and bad libraries.

The patch fixes defining RIGHT in solib-search-lib1.c and solib-search-
lib2.c.  Note, without the patch the lib1_spacer and lib2_spacer
functions do not show up in the object dump of the Intel or Powerpc
libraries as it should.  The patch fixes that by making sure RIGHT gets
defined.

Now with the patch the backtrace for the bad library on PowerPC looks
like:

backtrace
#0  break_here () at /.../solib-search.c:30
#1  0x00007ffff7f0083c in __glink_PLTresolve () from /.../solib-search-lib2.so
Backtrace stopped: frame did not save the PC

And the backtrace for the good libraries on PowerPC looks like:

backtrace
#0  break_here () at /.../solib-search.c:30
#1  0x00007ffff7f0083c in lib2_func4 () at /.../solib-search-lib2.c:49
#2  0x00007ffff7f3083c in lib1_func3 () at /.../solib-search-lib1.c:49
#3  0x00007ffff7f007cc in lib2_func2 () at /.../solib-search-lib2.c:30
#4  0x00007ffff7f307cc in lib1_func1 () at /.../solib-search-lib1.c:30
#5  0x000000001000074c in main () at /.../solib-search.c:23
(gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
PASS: gdb.base/solib-search.exp: backtrace (with right libs)

The issue then is on Power where the ARRAY_SIZE of 1 versus 8192 is not
sufficient to cause the dymanic linker to allocate the libraries at
different addresses.  I don't claim to understand the specifics of how
the dynamic linker works and what the default size is for the data and
code sections are.  My guess is by default PowerPC allocates a larger
data size by default, which is large enough to hold array[8192].  The
default size of the data section allocated by the dynamic linker on
Intel is not large enough to hold array[8192] thus causing the code
section on Intel to have to move when the large array is defined.

Note on PowerPC, if you make ARRAY_SIZE big enough, then you will cause
the library addresses to occur at different addresses as the larger
data section forces the code section to a different address.  That was
actually my original fix for the program until I spoke with Doug Evans
who originally wrote the test.  Doug noticed that RIGHT was not getting
defined as he originally intended in the test.

With the patch to fix the definition of RIGHT, PowerPC has a bad and a
good backtrace because the address of lib1_func3 and lib2_func4 both
move because lib1_spacer and lib2_spacer are now defined
before lib1_func3 and lib2_func4.

Without the patch, the lib1_spacer and lib2_spacer function doesn't show
up in the binary for the correct or incorrect library on Intel or PowerPC.
With the patch, RIGHT gets defined as originally intended for the test on
both architectures and lib1_spacer and lib2_spacer function show up in the
binaries on both architectures changing the other function addresses as
intended thus causing the test work as intended on PowerPC.

gdb/dwarf: remove line_header::header_length field

This can be a local in dwarf_decode_line_header.

Change-Id: I2ecf4616d1a3197bd1e81ded9f999a2da9a685af

gdb/dwarf: remove line_header::total_length field

This doesn' have to be a field, it can simply be a local variable in
dwarf_decode_line_header.  Name the local variable "unit_length", since
that's what the field in called in DWARF 4 and 5.  It's always easier to
follow the code with the standard on the side when we use the same
terminology.

Change-Id: I3ad1022afd9410b193ea11b9b5437686c1e4e633

gdb/testsuite: fix "set temporary breakpoint" DUPLICATEs

Commit c67f4e538 ("gdb/testsuite: make gdb.ada/mi_prot.exp stop at
expected location") introduced some DUPLICATEs in MI tests using
mi_continue_to_line, for example:

    DUPLICATE: gdb.ada/mi_ref_changeable.exp: mi_continue_to_line: set temporary breakpoint

These test names were previously differentiated by the location passed
to mi_continue_to_line.  Since the location can contain a path, that
commit removed the location from the test name, in favor of a hardcoded
string "set temporary breakpoint", hence removing the differentiator.

mi_continue_to_line receives a "test" parameter, containing a test
name.  Add a "with_test_prefix" with that name, so that all tests
recorded during mi_continue_to_line have this in their name.

mi_continue_to_line passes that "test" string to mi_get_stop_line, that
is a bit superfluous.  mi_get_stop_line only uses that string in case of
failures (it doesn't record a pass if everything goes fine).  Since it's
not crucial, just remove it, and adjust all callers.

Adjust three gdb.mi/mi-var-*.exp tests to use prefixes to differentiate
the multiple calls to mi_run_inline_test (which calls
mi_continue_to_line).

Change-Id: I511c6caa70499f8657b1cde37d71068d74d56a74

Always use dwarf2_initialize_objfile

Internally we noticed that some tests would fail like so on Windows:

warning: Section .debug_aranges in [...] has duplicate debug_info_offset 0x0, ignoring .debug_aranges.

Debugging showed that, in fact, a second CU was being created at this
offset.  We tracked this down to the fact that, while the ELF reader
is careful to re-use the per-BFD data, other readers are not, and
could re-read the DWARF data multiple times.

However, since the change to allow an objfile to have multiple "quick
symbol" implementations, there's no reason for this approach -- it's
safe and easy for all symbol readers to reuse the per-BFD data when
reading DWARF.

This patch implements this idea, simplifying dwarf2_build_psymtabs and
making it private, and then switching to dwarf2_initialize_objfile as
the sole way to start the DWARF reader.

Note that, while I think the call to dwarf2_build_frame_info in
machoread.c is also obsolete, I haven't attempted to remove it here.

gdb: fix 'remote show FOO-packet' aliases

The following behaviour was observed in GDB:

  (gdb) show remote X-packet
  Support for the `p' packet is auto-detected, currently unknown.

Note the message mentions the 'p' packet.  This is a regression since
this commit:

  commit 8579fd136a614985bd27f20539c7bb7c5a51287d
  Date:   Mon Nov 8 14:58:46 2021 +0000

      gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr

Before this commit the behaviour was:

  (gdb) show remote X-packet
  Support for the `X' packet is auto-detected, currently unknown.

The problem was caused by a failed attempt to ensure that some
allocated strings were deleted when GDB exits.  The code in the above
commit attempted to make use of 'static' to solve this problem,
however, the solution was just wrong.

In this new commit I instead allocate a static vector into which all
the allocated strings are stored, this ensures the strings are
released when GDB exits (which makes output from tools like valgrind
cleaner), but each string within the vector can be unique, which fixes
the regression.

gdbsupport: add path_join function

In this review [1], Eli pointed out that we should be careful when
concatenating file names to avoid duplicated slashes.  On Windows, a
double slash at the beginning of a file path has a special meaning.  So
naively concatenating "/"  and "foo/bar" would give "//foo/bar", which
would not give the desired results.  We already have a few spots doing:

  if (first_path ends with a slash)
    path = first_path + second_path
  else
    path = first_path + slash + second_path

In general, I think it's nice to avoid superfluous slashes in file
paths, since they might end up visible to the user and look a bit
unprofessional.

Introduce the path_join function that can be used to join multiple path
components together (along with unit tests).

I initially wanted to make it possible to join two absolute paths, to
support the use case of prepending a sysroot path to a target file path,
or the prepending the debug-file-directory to a target file path.  But
the code in solib_find_1 shows that it is more complex than this anyway
(for example, when the right hand side is a Windows path with a drive
letter).  So I don't think we need to support that case in path_join.
That also keeps the implementation simpler.

Change a few spots to use path_join to show how it can be used.  I
believe that all the spots I changed are guarded by some checks that
ensure the right hand side operand is not an absolute path.

Regression-tested on Ubuntu 18.04.  Built-tested on Windows, and I also
ran the new unit-test there.

[1] https://sourceware.org/pipermail/gdb-patches/2022-April/187559.html

Change-Id: I0df889f7e3f644e045f42ff429277b732eb6c752

gdb_spawn_attach_cmdline: use unsupported instead of untested

In a previous commit (b750766ac96: gdb/testsuite: Introduce and use
gdb_spawn_attach_cmdline), if gdb_spawn_attach_cmdline cannot have GDB
attach to the process because of ptrace restrictions (operation not
permitted), the proc issues UNTESTED.  This should really be
UNSUPPORTED, as it is done in gdb_attach.

This patch fixes this oversight.

Change-Id: Ib87e33b9230f3fa7a85e06220ef4c63814b71f7d

gdb/testsuite: add binary testcases to py-format-string.exp

We currently only test decimal and hexadecimal for the
gdb.Value.format_string() interface, this patch adds testcases for
binary format.

Tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").

gdb.debuginfod/fetch_src_and_symbols.exp: Fix "notice empty URL" test

The gdb_test_multiple pattern for the "notice empty URL" test in
gdb.debuginfod/fetch_src_and_symbols.exp misses expecting the prompt.
Fix it by using -re -wrap.

Also, by using "confirm off", the message GDB prints if Debuginfod
downloading is available doesn't contain "Enable debuginfod" any
longer.  E.g.:

~~~
  (gdb) file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols
  Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols...

  This GDB supports auto-downloading debuginfo from the following URLs:
    <http://localhost:123>
  Enable debuginfod for this session? (y or [n])
~~~

~~~
  (gdb) with confirm off -- file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols
  Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols...

  This GDB supports auto-downloading debuginfo from the following URLs:
    <http://127.0.0.1:8000>
    <127.0.0.1:8000>
  Debuginfod has been disabled.
  To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
  (No debugging symbols found in testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols)
  (gdb)
~~~

I handled that correctly in the other tests that use test_urls, but
had forgotten to update the "notice empty URL" one.

Change-Id: I00040c83466e1494b3875574eb009c571a1504bf

prune .note.GNU-stack warning from testsuite

binutils/
* testsuite/lib/binutils-common.exp (prune_warnings_extra): Remove
.note.GNU-stack warning.
(run_dump_test): Call prune_warnings for ld and objcopy output.
ld/
* testsuite/ld-elf/elf.exp: Disable prune_warnings_extra temporarily
around test for absent .note.GNU-stack
* testsuite/ld-cris/globsymw2.s,
* testsuite/ld-cris/warn3.d: Modify "is not implemented" message
to avoid dejagnu prune_warnings.

ld testsuite xcoff XPASS

* testsuite/ld-scripts/defined5.d: Don't xfail xcoff targets.

Delete unused COFF gas macro

* config/obj-coff.h (sy_obj): Don't define.
(OBJ_SYMFIELD_TYPE): Revise comments.

Automatic date update in version.in

gdb/debuginfod: Prevent out_of_range exception

Trailing whitespace in the string of debuginfod URLs causes an
out_of_range exception during the printing of URLs for the first
use notice.

To fix this, stop printing URLs when the substring to be printed
consists only of whitespace.

Also add first use notice testcases.

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

gdb/testsuite: Introduce and use gdb_spawn_attach_cmdline

Following a7e6a19e87f3d719ea23c65b580a6d9bca4ccab3 "gdb: testsuite: add
new gdb_attach to check "attach" command", this commit proposes to
introduce the gdb_spawn_attach_cmdline helper and use it in
gdb.base/attach.exp.

This helper starts GDB and adds the "--pid=$PID" argument.

Also note that both the original and new implementation use
gdb_spawn_with_cmdline_opts, which in the end uses default_gdb_spawn.
This makes sure that we use $INTERNAL_GDBFLAGS, which by default already
contain "-iex \"set height 0\" -iex \"set width 0\"".  To avoid
repetition of those arguments, gdb_spawn_attach_cmdline does not repeat
those arguments.

To maintain a behavior similat to what gdb.base/attach.exp used to do,
gdb_spawn_attach_cmdline keeps the -quiet flag.

Tested on x86_64-gnu-linux

Change-Id: I1fdcdb71c86d9c5d34bb28fc86fac68bcec37358

Replace symbol_symtab with symbol::symtab

This turns symbol_symtab into a method on symbol.  It also replaces
symbol_set_symtab with a method.

Replace symbol_arch with symbol::arch

This turns symbol_arch into a method on symbol.

Replace symbol_objfile with symbol::objfile

This turns symbol_objfile into a method on symbol.

Remove symbol::aclass_index

Symbols have an aclass_index method, but this isn't needed, because
the aclass index isn't useful outside of the symbol implementation.

Use array_view for symbol_impls

It seemed to me that using array_view for symbol_impls would give a
bit more error checking, at least when gdb is built in libstdc++ debug
mode.

Add accessors for symbol's artificial field

For a series I'm experimenting with, it was handy to hide a symbol's
"artificial" field behind accessors.  This patch is the result.

Unify the DWARF index holders

The dwarf2_per_bfd object has a separate field for each possible kind
of index.  Until an earlier patch in this series, two of these were
even derived from a common base class, but still had separate slots.
This patch unifies all the index fields using the common base class
that was introduced earlier in this series.  This makes it more
obvious that only a single index can be active at a time, and also
removes some code from dwarf2_initialize_objfile.

Add an ad hoc version check to dwarf_scanner_base

Some generic code in the DWARF reader has a special case for older
versions of .gdb_index.  This patch adds an ad hoc version check
method so that these spots can work without specific knowledge of
which index is in use.

Simplify version check in dw2_symtab_iter_next

This simplifies the index versio check in dw2_symtab_iter_next, by
passing a reference to the index object to this function.  This avoids
an indirection via the per_bfd object.

Introduce and use dwarf_scanner_base

This introduces dwarf_scanner_base, a base class for all the index
readers in the DWARF code.  Then, it changes both mapped_index_base
and cooked_index_vector to derive from this new base class.

Introduce readnow_functions

This introduces readnow_functions, a new subclass of
dwarf2_base_index_functions, and changes the DWARF reader to use it.
This lets us drop the "index is NULL" hack from the gdb index code.

Remove some "OBJF_READNOW" code from dwarf2_debug_names_index

The dwarf2_debug_names_index code treats a NULL debug_names_table as
if it were from OBJF_READNOW.  However, this trick is only done for
gdb_index, never for debug_names -- see dwarf2_initialize_objfile.

Let mapped index classes create the quick_symbol_functions object

This changes the mapped index classes to create the
quick_symbol_functions objects.  This is a step toward having a more
abstract interface to mapped indices.

Give mapped_index_base a virtual destructor

This changes mapped_index_base to have a virtual destructor, so it can
be destroyed via its base class.

Move mapped_index_base to new header file

This moves mapped_index_base and the helper struct name_component to a
new header file in gdb/dwarf2/.

x86: reject all invalid SAE variants

So far an SAE-only specifier was accepted for static-rounding insns,
while SAE-only insns didn't accept static rounding specifiers. If
anything it would make sense the other way around, allowing SAE-only
insns to have the (ignored) rounding mode specified individually rather
than globally via -mevexrcig=. But for now make things match the SDM.

Re: xcoff: implement linker relaxation

* xcofflink.c (xcoff_stub_csect_name): Increase buffer size.
(xcoff_stub_get_csect_in_range, xcoff_build_one_stub): Whitespace.
(bfd_xcoff_size_stubs): Cast PRIx64 arg to required type.
Don't use freed stub_name.

Revert "as: Reject unknown -gXXX option" testsuite

This reverts the test committed as part of 6ea673e2d6.

xcoff: implement linker relaxation

bfd/ChangeLog:

* coff-rs6000.c (xcoff_reloc_type_noop): Add info argument.
(xcoff_reloc_type_fail): Likewise.
(xcoff_reloc_type_pos): Likewise.
(xcoff_reloc_type_neg): Likewise.
(xcoff_reloc_type_rel): Likewise.
(xcoff_reloc_type_toc): Likewise.
(xcoff_reloc_type_ba): Likewise.
(xcoff_reloc_type_crel): Likewise.
(xcoff_reloc_type_tls): Likewise.
(xcoff_reloc_type_br): Add stub handler.
(xcoff_ppc_relocate_section): Add info to
xcoff_calculate_relocation.
(xcoff_stub_indirect_call_code): New constant.
(xcoff_stub_shared_call_code): Likewise.
(bfd_xcoff_backend_data): Add stub code fields.
(bfd_pmac_xcoff_backend_data): Likewise.
* coff64-rs6000.c (xcoff64_reloc_type_br): Add stub handler.
(xcoff64_ppc_relocate_section): Add info to
xcoff64_calculate_relocation.
(xcoff64_stub_indirect_call_code): New constant.
(xcoff64_stub_shared_call_code): Likewise.
(bfd_xcoff_backend_data): Add stub code fields.
(bfd_xcoff_aix5_backend_data): Likewise.
* libxcoff.h (struct xcoff_backend_data_rec): Add stub fields.
(bfd_xcoff_stub_indirect_call_code): New define.
(bfd_xcoff_stub_indirect_call_size): New define.
(bfd_xcoff_stub_shared_call_code): New define.
(bfd_xcoff_stub_shared_call_size): New define.
(xcoff_reloc_function): Add info argument.
(enum xcoff_stub_type): New enum.
(struct xcoff_stub_hash_entry): New structure.
* xcofflink.c (struct xcoff_link_hash_table): Add stub hash
table and params fields.
(xcoff_stub_hash_entry): New define.
(xcoff_stub_hash_lookup): New define.
(stub_hash_newfunc): New function.
(_bfd_xcoff_bfd_link_hash_table_free): Free the new stub hash
table.
(_bfd_xcoff_bfd_link_hash_table_create): Create the new stub
hash table.
(xcoff_link_add_symbols): Save rawsize for XTY_SD.
(bfd_xcoff_link_init): New function.
(xcoff_stub_csect_name): New function.
(xcoff_stub_get_csect_in_range): New function.
(xcoff_stub_name): New function.
(bfd_xcoff_get_stub_entry): New function.
(bfd_xcoff_type_of_stub): New function.
(xcoff_add_stub): New function.
(xcoff_build_one_stub): New function.
(bfd_xcoff_size_stubs): New function.
(bfd_xcoff_build_stubs): New function.
(xcoff_stub_create_relocations): New function.
(xcoff_link_input_bfd): Adapt relocations to stub.
(xcoff_write_global_symbol): Adapt to new TOC entries generated
for stubs.
(_bfd_xcoff_bfd_final_link): Handle stub file.
* xcofflink.h (struct bfd_xcoff_link_params): New structure.

ld/ChangeLog:

* emultempl/aix.em (params): New variable.
(stub_file): New variable.
(xcoff_add_stub_section): New function.
(xcoff_layout_sections_again): New function
(hook_in_stub): New function.
(_after_allocation): Add stub creation.
(_create_output_section_statements): Allocate stub file and
pass params to backend.

Stubs (added in a later patch) will generate new .loader symbols, once the allocations have been done. Thus, the .loader section cannot be layout before that.

bfd/ChangeLog:

* coff-rs6000.c (_bfd_xcoff_put_ldsymbol_name): Write len in
  ldinfo->strings instead of directly in the output_bfd.
* coff64-rs6000.c (_bfd_xcoff64_put_ldsymbol_name): Likewise.
* xcofflink.c (struct xcoff_link_hash_table): Remove ldrel_count
  field. Add ldinfo field.
(xcoff_mark_symbol): Adjust to new ldinfo field.
(xcoff_mark): Likewise.
(bfd_xcoff_link_count_reloc): Likewise.
(xcoff_build_loader_section): Split into two functions: one that
build the loader section (this function) and one that only size
it...
(xcoff_size_loader_section): ... (this function).
(bfd_xcoff_size_dynamic_sections): Adapt to new ldinfo field.
Move the part where the dynamic sections are build to ...
(bfd_xcoff_build_dynamic_sections): ... this function.
* xcofflink.h: Add bfd_xcoff_build_dynamic_sections prototype.

include/ChangeLog:

* coff/xcoff.h (struct xcoff_loader_info): Add ldrel_count and
libpath fields.

ld/ChangeLog:

* emultempl/aix.em (_after_allocation): New function.

Use symbol_symtab accessor in compile-object-load.c

I noticed that compile-object-load.c directly references owner.symtab
of a symbol.  However, I think it's better for all users to call
symbol_symtab.  This patch makes this change.

Add linker warning for when it creates an executable stack.

   PR 29072

Micro-optimize cooked_index_entry::full_name

I noticed that cooked_index_entry::full_name can return the canonical
string when there is no parent entry.

Regression tested on x86-64 Fedora 34.

gdb: LoongArch: Implement loongarch_scan_prologue()

If can't determine prologue from the symbol table, need to examine
instructions. Implement loongarch_scan_prologue() to analyze the
function prologue from START_PC to LIMIT_PC, return the address of
the first instruction past the prologue.

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

Automatic date update in version.in

as: Reject unknown -gXXX option

* as.c (parse_args): Reject unknown -gXXX option.
* testsuite/gas/all/empty.s: New file.
* testsuite/gas/all/pr29067.d: Likewise.
* testsuite/gas/all/pr29067.err: Likewise.
* testsuite/gas/all/gas.exp: Run pr29067.

gdb/selftest-arch: Make register_test_foreach_arch generate arch tests lazily

The register_test_foreach_arch is used to instantiate a given selftest
for all architectures supported by GDB.  It is used in many _initialize_*
functions (under initialize_all_files, called by gdb_init).

Because the call is done during GDB's initialization, and because there
is no guaranty about the order in which all the _initialize_* functions
are executed, when register_test_foreach_arch is called, GDB is not
fully initialized.  Specifically, when a particular initialize function
is executed, only the architectures registered at that point are listed
by gdbarch_printable_names.

As a consequence, the list of selftest effectively executed depends on
the order the _initialize_* functions are called.  This can be observed
with the following:

    $ ./gdb/gdb \
        -data-directory ./gdb/data-directory \
        -quiet -batch -ex "maint selftest" 2>&1 \
        | grep -E "Ran [0-9]+ unit tests"
    Ran 145 unit tests, 0 failed
    $ GDB_REVERSE_INIT_FUNCTIONS=1 ./gdb/gdb \
        -data-directory ./gdb/data-directory \
        -quiet -batch -ex "maint selftest" 2>&1 \
        | grep -E "Ran [0-9]+ unit tests"
    Ran 82 unit tests, 0 failed

To fix this, make register_test_foreach_arch register a lazy selftest
generator.  This way when the test generator is eventually executed, all
architectures are registered and we do not have a dependency on the
order the initialize functions are executed in.

Tested on x86_64-linux

Change-Id: I88eefebf7d372ad672f42d3a103e89354bc8a925

gdbsupport/selftest: Allow lazy registration

This patch adds a way to delay the registration of tests until the
latest possible moment.  This is intended for situations where GDB needs
to be fully initialized in order to decide if a particular selftest can
be executed or not.

This mechanism will be used in the next patch.

Change-Id: I7f6b061f4c0a6832226c7080ab4e3a2523e1b0b0

gdbsupport/selftest: Replace for_each_selftest with an iterator_range

Remove the callback-based selftests::for_each_selftest function and use
an iterator_range instead.

Also use this iterator range in run_tests so all iterations over the
selftests are done in a consistent way.  This will become useful in a
later commit.

Change-Id: I0b3a5349a7987fbcb0071f11c394e353df986583

x86: don't mistake ordinary immediates for SAE / rounding control

The way SAE templates are constructed was always puzzling me (including
the need for separate templates in the first place), and expressing the
extzra attribute via Imm8 actually has a bad effect: Ordinary immediates
would also be accepted, leading to an extra byte being added after the
instruction (i.e. generating bad code). Before re-working this (in
particular to accept proper Intel syntax there), fix the immediate issue
by adding the so far missing check.

x86: VCMPSH is Evex.LLIG

These were mistakenly flagged as Evex.128. Getting the LLIG status right
for insns allowing for SAE is a prereq for planned further work.

x86: drop stray CheckRegSize from VFPCLASSPH

Like VFPCLASSP{S,D} it has only a single operand allowing multiple
sizes, hence there are no pairs of operands to check for consistent
size.

x86/Intel: test non-legacy VCVT{,U}SI2SH insn forms

For an unclear reason corresponding AVX512F tests were apparently not
cloned or used as reference here, and instead the bogus legacy forms of
the insns (with the embedded rounding specifier not last) were used.

x86: correct and simplify NOP disassembly

It's not just REX.W which is ignored with opcode 0x90. The same goes for
REX.R and REX.X as well as empty REX. None of these are forms of
"xchg %eax,%eax" (which would mean zero-extending %eax to %rax), so they
also shouldn't be disassembled this way.

While there simplify things: A single hook function suffices, thus
making it unnecessary to keep two expressions in sync. And checking
ins->address_mode for mode_64bit also is unnecessary, as "rex" can be
non-zero only in that case anyway.

Automatic date update in version.in

gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5

To support DWARF 5 in the DWARF assembler line tables, we currently copy
the first user-provided directory and the first user-provided files and
make them elements at indices 0 in the directory and file name tables.
That was a sufficient behavior at the time (see commit 44fda089397a
("[gdb/testsuite] Support .debug_line v5 in dwarf assembler")), but in
the following patches, I would need to have finer grained control on
what is generated exactly.  For example, I'd like to generate a DWARF 5 line
table with just a single file and a single directory.

Get rid of this behavior, and implement what is suggested in
44fda089397a: make include_dir return the directory index that can be
used to refer to that directory entry (based on the DWARF version), and
use it afterwards.

Adjust dw2-lines.exp and dw2-prologue-end.exp accordingly.  Their produced
DWARF5 binaries will change a bit, in that they will now have a single
directory and file, where they had two before.  But it doesn't change
the expected GDB behavior.

Change-Id: I5459b16ac9b7f28c34c9693c35c9afd2ebb3aa3b

gdb: use gdb_tilde_expand instead of gdb_tilde_expand_up in source_script_with_search

Since this is the latest use of gdb_tilde_expand_up, remove it.

Change-Id: I964c812ce55fe087876abf91e7a3577ad79c0425

gdbsupport: make gdb_realpath_keepfile return an std::string

I'm trying to switch these functions to use std::string instead of char
arrays, as much as possible.  Some callers benefit from it (can avoid
doing a copy of the result), while others suffer (have to make one more
copy).

Change-Id: I793aab17baaef8345488f4c40b9094e2695425bc

gdbsupport: make gdb_abspath return an std::string

I'm trying to switch these functions to use std::string instead of char
arrays, as much as possible.  Some callers benefit from it (can avoid
doing a copy of the result), while others suffer (have to make one more
copy).

Change-Id: Iced49b8ee2f189744c5072a3b217aab5af17a993

gdb: call gdb_tilde_expand instead of gdb_tilde_expand_up in source_script_with_search

This removes a use of gdb_tilde_expand_up, which is removed later in
this series.

Change-Id: I5887d526cea987103e4ca24514a982b0a28e992a

Update gnulib

This updates gnulib to a relatively recent commit.  Most of this was
done by the gnulib import script; the only change I made was to
update-gnulib.sh.

Tested on x86-64 Fedora 34.  I also did a mingw cross build.

Fix C++ cast of derived class to base class

PR c++/28907 points out that casting from a derived class to a base
class fails in some situations.  The problem turned out to be a
missing use of value_embedded_offset.  One peculiarity here is that,
if you managed to construct a pointer-to-derived with an embedded
offset of 0, the cast would work -- for example, one of the two new
tests here passes without the patch.

This embedded offset stuff is an endless source of bugs.  I wonder if
it's possible to get rid of it somehow.

Regression tested on x86-64 Fedora 34.

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

gdb/testsuite: make gdb.ada/mi_prot.exp stop at expected location

This test attempts to run until the line marked "STOP", which is at
prot.adb:34.  It first runs until the "main" symbol, then tries to place
a breakpoint by line at line 34, without specifying the source file.  When looking at the logs:

    -break-insert -t 34^M
    ^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x0000555555558a6c",func="adafinal",file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_pro    t/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",thread-groups=["i1"],times="0",original-location="/home/simark/b    uild/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb:34"}^M
    ... continues ...
     *stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={addr="0x0000555555558a6c",func="adafinal",args=[],file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/    mi_prot/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",arch="i386:x86-64"},thread-id="1",stopped-threads="all",co    re="8"^M

... we see that the breakpoint is placed in some generated file, not in
the test source file as we expect.  The problem is that "b main" in Ada
does not place a breakpoint on the "Ada main", but on some symbol in a
generated source file.  So when stopped at the "main" symbol, we are not
stopped in the file that contains the STOP marker at line 34.

The test passes anyway today, so it doesn't seem to matter that we are
stopped at an unexpected location.  But it starts failing with this
patch [1], because b~prot.adb:34 happens to be between two functions, so
the breakpoint doesn't resolve.

Fix this by placing the breakpoint at "$srcfile:$line", which works
regardless of what is the current source file.

However, this ends up introducing a path in the test name.  Modify
mi_tbreak and mi_continue_to_line to avoid that.

[1] https://sourceware.org/pipermail/gdb-patches/2022-April/187686.html

Change-Id: I742e2a9993046dcb5e30c64fe2ad920a363baf75

gdb/testsuite: add text_segment option to gdb_compile

LLVM's lld linker doesn't have the "-Ttext-segment" option, but
"--image-base" can be used instead.

To centralize the logic of checking which option is supported, add the
text_segment option to gdb_compile.  Change tests that are currently
using -Ttext-segment to use that new option instead.

This patch fixes only compilation error, for example:

Before:

    $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
    gdb compile failed, clang-13: warning: -Xlinker -Ttext-segment=0x7000000: 'linker' input unused [-Wunused-command-line-argument]

After:

    $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
    FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 1
    FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 2
    FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 1
    FAIL: gdb.base/jit-elf.exp: one_jit_test-2: info function ^jit_function
    FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 2
    FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: continue to breakpoint: break here 1
    FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
    FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 1
    FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2

                    === gdb Summary ===

    # of expected passes            26
    # of unexpected failures        9

Change-Id: I3678c5c9bbfc2f80671698e28a038e6b3d14e635

gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)

The clear command shouldn't delete momentary and internal breakpoints,
nor internal breakpoints created via Python's gdb.Breakpoint.

This patch fixes this issue and adds a testcase.

Regression tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").

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

Automatic date update in version.in

Automatic date update in version.in

Add comments to dwarf2/abbrev-cache.h

This patch started when I noticed that the unordered_set include
wasn't needed in abbrev-cache.h.  (That was probably leftover from
some earlier implementation of the class.)  Then, I noticed that the
class itself was under-commented.  This patch fixes both issues.

Automatic date update in version.in

Return void from gdb_putc

I don't think it's very useful to return the character from gdb_putc,
so this patch changes it to return void.

Handle "set height 1"

PR cli/17151 points out that "set height 1" has pathological behavior
in gdb.  What I see is that gdb will endlessly print the pagination
prompt.  This patch takes a simple and expedient approach to a fix:
pretend that the height is really 2.

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

Allow word wrapping even when paging is disabled

PR cli/20741 points out that when pagination is disabled, this also
disabled word wrapping.  However, the manual documents that these
settings are separate -- if you intend to disable the wrapping, you
must use "set width unlimited".

This patch fixes the bug by letting the pagination-disabled case fall
through to the code that also handles word-wrapping.

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

Implement value_print for Rust

This adds an implementation of the value_print method to Rust.  As
described in PR rust/22254, this removes a bit of weird-looking output
from some "print"s -- because c_value_print is bypassed.  I don't have
a test for the bug that inspired this patch, because I only know how
to reproduce it when using a relatively old Rust compiler.  However,
the new "cast-printing" code in value_print is required, because
omitting this causes some existing tests to fail.

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

Reimplement Rust slice printing

The current nightly Rust compiler (aka 1.61) added better DWARF
representation for unsized types.  Fixing this is PR rust/21466; but
the code is actually the same as what is required to make slice
printing more useful, which is PR rust/23871.  This patch implements
this.  I tested this against various Rust compilers: 1.48, current
stable, current beta, and current nightly.

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

Remove some dead code from the Rust value printer

This removes a bit of dead code from the Rust value printer.  This
code wasn't always dead -- it fixed a real bug, and a test case was
added for it.  However, once val_print was removed, it became
unnecessary.

Match rustc beta versions

The rust_compiler_version proc extracts the Rust compiler version from
the "rustc --version" output.  For a beta compiler, the output looks
like:

    rustc 1.60.0-beta.6 (7bccde197 2022-03-22)

This patch slightly relaxes the regexp -- removing a space -- so that
this can be understood by this proc.

[gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32

With test-case gdb.ada/float-bits.exp and native we get:
...
(gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
$9 = 5.0e+25^M
(gdb) PASS: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
...
but with target board unix/-m32 we have instead:
...
(gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
Cannot export value 2596145952482202326224873165792712 as 96-bits \
  unsigned integer (must be between 0 and 79228162514264337593543950335)^M
(gdb) FAIL: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
...

Fix this by testing whether 16llf is supported by doing ptype long_long_float
which gets us either:
...
type = <16-byte float>^M
...
or:
...
type = <12-byte float>^M
...

Tested on x86_64-linux with native and unix/-m32.

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

Remove WITH_SIM define

Since score-tdep.c was removed, the WITH_SIM define is not used in
gdb.  This patch removes it.

Note that re-running autoheader shows a separate change that was
missed.  I've kept it in this patch to avoid extra work.

[gdb/testsuite] Fix gdb.go/methods.exp with check-readmore

When running test-case gdb.go/methods.exp with make check we have:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) XFAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...
but with make check-readmore the XFAIL fails to trigger:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...

This happens because this gdb_test_multiple "maintenance print symbols"
regexp:
...
    -re "\r\n$gdb_prompt $" {
...
matches the entire command output.

Fix this by adding the missing ^ at the regexp start.

Tested on x86_64-linux.

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

Automatic date update in version.in

gdbserver: Eliminate prepare_to_access_memory

Given:

 - The prepare_to_access_memory machinery was added for non-stop mode.

 - Only Linux supports non-stop.

 - Linux no longer needs the prepare_to_access_memory machinery.  In
   fact, after the previous patch,
   linux_process_target::prepare_to_access_memory became a nop.

Thus, prepare_to_access_memory can go away, simplifying core GDBserver
code.

Change-Id: I93ac8bfe66bd61c3d1c4a0e7d419335163120ecf

gdbserver/linux: Access memory even if threads are running

Similarly to how the native Linux target was changed
and subsequently reworked in these commits:

 05c06f318fd9 Linux: Access memory even if threads are running
 8a89ddbda2ec Avoid /proc/pid/mem races (PR 28065)

... teach GDBserver to access memory even when the current thread is
running, by always accessing memory via /proc/PID/mem.

The existing comment:

  /* Neither ptrace nor /proc/PID/mem allow accessing memory through a
     running LWP.  */

... is incorrect for /proc/PID/mem does allow that.

Actually, from GDB's perspective, GDBserver could already access
memory while threads were running, but at the expense of pausing all
threads for the duration of the memory access, via
prepare_to_access_memory.  This new implementation does not require
pausing any thread, thus
linux_process_target::prepare_to_access_memory /
linux_process_target::done_accessing_memory become nops.  A subsequent
patch will remove the whole prepare_to_access_memory infrastructure
completely.

The GDBserver linux-low.cc implementation is simpler than GDB's
linux-nat.c's, because GDBserver always adds the unfollowed vfork/fork
children to the process list immediately when the fork/vfork event is
seen out of ptrace.  I.e., there's no need to keep the file descriptor
stored on a side map, we can store it directly in the process
structure.

Change-Id: I0abfd782ceaa4ddce8d3e5f3e2dfc5928862ef61