gdb: don't resume vfork parent while child is still running

Like the last few commit, this fixes yet another vfork related issue.
Like the commit titled:

  gdb: don't restart vfork parent while waiting for child to finish

which addressed a case in linux-nat where we would try to resume a
vfork parent, this commit addresses a very similar case, but this time
occurring in infrun.c.  Just like with that previous commit, this bug
results in the assert:

  x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.

In this case the issue occurs when target-non-stop is on, but non-stop
is off, and again, schedule-multiple is on.  As with the previous
commit, GDB is in follow-fork-mode child.  If you have not done so, it
is worth reading the earlier commit as many of the problems leading to
the failure are the same, they just appear in a different part of GDB.

Here are the steps leading to the assertion failure:

  1. The user performs a 'next' over a vfork, GDB stop in the vfork
  child,

  2. As we are planning to follow the child GDB sets the vfork_parent
  and vfork_child member variables in the two inferiors, the
  thread_waiting_for_vfork_done member is left as nullptr, that member
  is only used when GDB is planning to follow the parent inferior,

  3. The user does 'continue', our expectation is that the vfork child
  should resume, and once that process has exited or execd, GDB should
  detach from the vfork parent.  As a result of the 'continue' GDB
  eventually enters the proceed function,

  4. In proceed we selected a ptid_t to resume, because
  schedule-multiple is on we select minus_one_ptid (see
  user_visible_resume_ptid),

  5. As GDB is running in all-stop on top of non-stop mode, in the
  proceed function we iterate over all threads that match the resume
  ptid, which turns out to be all threads, and call
  proceed_resume_thread_checked.  One of the threads we iterate over
  is the vfork parent thread,

  6. As the thread passed to proceed_resume_thread_checked doesn't
  match any of the early return conditions, GDB will set the thread
  resumed,

  7. As we are resuming one thread at a time, this thread is seen by
  the lower layers (e.g. linux-nat) as the "event thread", which means
  we don't apply any of the checks, e.g. is this thread a
  vfork parent, instead we assume that GDB core knows what it's doing,
  and linux-nat will resume the thread, we have now incorrectly set
  running the vfork parent thread when this thread should be waiting
  for the vfork child to complete,

  8. Back in the proceed function GDB continues to iterate over all
  threads, and now (correctly) resumes the vfork child thread,

  8. As the vfork child is still alive the kernel holds the vfork
  parent stopped,

  9. Eventually the child performs its exec and GDB is sent and EXECD
  event.  However, because the parent is resumed, as soon as the child
  performs its exec the vfork parent also sends a VFORK_DONE event to
  GDB,

  10. Depending on timing both of these events might seem to arrive in
  GDB at the same time.  Normally GDB expects to see the EXECD or
  EXITED/SIGNALED event from the vfork child before getting the
  VFORK_DONE in the parent.  We know this because it is as a result of
  the EXECD/EXITED/SIGNALED that GDB detaches from the parent (see
  handle_vfork_child_exec_or_exit for details).  Further the comment
  in target/waitstatus.h on TARGET_WAITKIND_VFORK_DONE indicates that
  when we remain attached to the child (not the parent) we should not
  expect to see a VFORK_DONE,

  11. If both events arrive at the same time then GDB will randomly
  choose one event to handle first, in some cases this will be the
  VFORK_DONE.  As described above, upon seeing a VFORK_DONE GDB
  expects that (a) the vfork child has finished, however, in this case
  this is not completely true, the child has finished, but GDB has not
  processed the event associated with the completion yet, and (b) upon
  seeing a VFORK_DONE GDB assumes we are remaining attached to the
  parent, and so resumes the parent process,

  12. GDB now handles the EXECD event.  In our case we are detaching
  from the parent, so GDB calls target_detach (see
  handle_vfork_child_exec_or_exit),

  13. While this has been going on the vfork parent is executing, and
  might even exit,

  14. In linux_nat_target::detach the first thing we do is stop all
  threads in the process we're detaching from, the result of the stop
  request will be cached on the lwp_info object,

  15. In our case the vfork parent has exited though, so when GDB
  waits for the thread, instead of a stop due to signal, we instead
  get a thread exited status,

  16. Later in the detach process we try to resume the threads just
  prior to making the ptrace call to actually detach (see
  detach_one_lwp), as part of the process to resume a thread we try to
  touch some registers within the thread, and before doing this GDB
  asserts that the thread is stopped,

  17. An exited thread is not classified as stopped, and so the assert
  triggers!

Just like with the earlier commit, the fix is to spot the vfork parent
status of the thread, and not resume such threads.  Where the earlier
commit fixed this in linux-nat, in this case I think the fix should
live in infrun.c, in proceed_resume_thread_checked.  This function
already has a similar check to not resume the vfork parent in the case
where we are planning to follow the vfork parent, I propose adding a
similar case that checks for the vfork parent when we plan to follow
the vfork child.

This new check will mean that at step #6 above GDB doesn't try to
resume the vfork parent thread, which prevents the VFORK_DONE from
ever arriving.  Once GDB sees the EXECD/EXITED/SIGNALLED event from
the vfork child GDB will detach from the parent.

There's no test included in this commit.  In a subsequent commit I
will expand gdb.base/foll-vfork.exp which is when this bug would be
exposed.

If you do want to reproduce this failure then you will for certainly
need to run the gdb.base/foll-vfork.exp test in a loop as the failures
are all very timing sensitive.  I've found that running multiple
copies in parallel makes the failure more likely to appear, I usually
run ~6 copies in parallel and expect to see a failure after within
10mins.

gdb, infrun: refactor part of `proceed` into separate function

Split the thread resuming code from proceed into new function
proceed_resume_thread_checked.

Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

gdb: fix an issue with vfork in non-stop mode

This commit fixes a bug introduced by this commit:

  commit d8bbae6ea080249c05ca90b1f8640fde48a18301
  Date:   Fri Jan 14 15:40:59 2022 -0500

      gdb: fix handling of vfork by multi-threaded program (follow-fork-mode=parent, detach-on-fork=on)

The problem can be seen in this GDB session:

  $ gdb -q
  (gdb) set non-stop on
  (gdb) file ./gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork
  Reading symbols from ./gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork...
  (gdb) tcatch vfork
  Catchpoint 1 (vfork)
  (gdb) run
  Starting program: /tmp/gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork

  Temporary catchpoint 1 (vforked process 1375914), 0x00007ffff7d5043c in vfork () from /lib64/libc.so.6
  (gdb) bt
  #0  0x00007ffff7d5043c in vfork () from /lib64/libc.so.6
  #1  0x00000000004011af in main (argc=1, argv=0x7fffffffad88) at .../gdb/testsuite/gdb.base/foll-vfork.c:32
  (gdb) finish
  Run till exit from #0  0x00007ffff7d5043c in vfork () from /lib64/libc.so.6
  [Detaching after vfork from child process 1375914]
  No unwaited-for children left.
  (gdb)

Notice the "No unwaited-for children left." error.  This is incorrect,
given where we are stopped there's no reason why we shouldn't be able
to use "finish" to return to the main frame.

When the inferior is stopped as a result of the 'tcatch vfork', the
inferior is in the process of performing the vfork, that is, GDB has
seen the VFORKED event, but has not yet attached to the new child
process, nor has the child process been resumed.

However, GDB has seen the VFORKED, and, as we are going to follow the
parent process, the inferior for the vfork parent will have its
thread_waiting_for_vfork_done member variable set, this will point to
the one and only thread that makes up the vfork parent process.

When the "finish" command is used GDB eventually ends up in the
proceed function (in infrun.c), in here we pass through all the
function until we eventually encounter this 'else if' condition:

   else if (!cur_thr->resumed ()
     && !thread_is_in_step_over_chain (cur_thr)
     /* In non-stop, forbid resuming a thread if some other thread of
that inferior is waiting for a vfork-done event (this means
breakpoints are out for this inferior).  */
     && !(non_stop
  && cur_thr->inf->thread_waiting_for_vfork_done != nullptr))
      {

The first two of these conditions will both be true, the thread is not
already resumed, and is not in the step-over chain, however, the third
condition, this one:

     && !(non_stop
  && cur_thr->inf->thread_waiting_for_vfork_done != nullptr))

is false, and this prevents the thread we are trying to finish from
being resumed.  This condition is false because (a) non_stop is true,
and (b) cur_thr->inf->thread_waiting_for_vfork_done is not
nullptr (see above for why).

Now, if we check the comment embedded within the condition it says:

     /* In non-stop, forbid resuming a thread if some other thread of
        that inferior is waiting for a vfork-done event (this means
        breakpoints are out for this inferior).  */

And this makes sense, if we have a vfork parent with two thread, and
one thread has performed a vfork, then we shouldn't try to resume the
second thread.

However, if we are trying to resume the thread that actually performed
a vfork, then this is fine.  If we never resume the vfork parent then
we'll never get a VFORK_DONE event, and so the vfork will never
complete.

Thus, the condition should actually be:

     && !(non_stop
  && cur_thr->inf->thread_waiting_for_vfork_done != nullptr
  && cur_thr->inf->thread_waiting_for_vfork_done != cur_thr))

This extra check will allow the vfork parent thread to resume, but
prevent any other thread in the vfork parent process from resuming.
This is the same condition that already exists in the all-stop on a
non-stop-target block earlier in the proceed function.

My actual fix is slightly different to the above, first, I've chosen
to use a nested 'if' check instead of extending the original 'else if'
check, this makes it easier to write a longer comment explaining
what's going on, and second, instead of checking 'non_stop' I've
switched to checking 'target_is_non_stop_p'.  In this context this is
effectively the same thing, a previous 'else if' block in proceed
already handles '!non_stop && target_is_non_stop_p ()', so by the time
we get here, if 'target_is_non_stop_p ()' then we must be running in
non_stop mode.

Both of these tweaks will make the next patch easier, which is a
refactor to merge two parts of the proceed function, so this nested
'if' block is not going to exist for long.

For testing, there is no test included with this commit.  The test was
exposed when using a modified version of the gdb.base/foll-vfork.exp
test script, however, there are other bugs that are exposed when using
the modified test script.  These bugs will be addressed in subsequent
commits, and then I'll add the updated gdb.base/foll-vfork.exp.

If you wish to reproduce this failure then grab the updates to
gdb.base/foll-vfork.exp from the later commit and run this test, the
failure is always reproducible.

gdb: don't restart vfork parent while waiting for child to finish

While working on a later patch, which changes gdb.base/foll-vfork.exp,
I noticed that sometimes I would hit this assert:

  x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.

I eventually tracked it down to a combination of schedule-multiple
mode being on, target-non-stop being off, follow-fork-mode being set
to child, and some bad timing.  The failing case is pretty simple, a
single threaded application performs a vfork, the child process then
execs some other application while the parent process (once the vfork
child has completed its exec) just exits.  As best I understand
things, here's what happens when things go wrong:

  1. The parent process performs a vfork, GDB sees the VFORKED event
  and creates an inferior and thread for the vfork child,

  2. GDB resumes the vfork child process.  As schedule-multiple is on
  and target-non-stop is off, this is translated into a request to
  start all processes (see user_visible_resume_ptid),

  3. In the linux-nat layer we spot that one of the threads we are
  about to start is a vfork parent, and so don't start that
  thread (see resume_lwp), the vfork child thread is resumed,

  4. GDB waits for the next event, eventually entering
  linux_nat_target::wait, which in turn calls linux_nat_wait_1,

  5. In linux_nat_wait_1 we eventually call
  resume_stopped_resumed_lwps, this should restart threads that have
  stopped but don't actually have anything interesting to report.

  6. Unfortunately, resume_stopped_resumed_lwps doesn't check for
  vfork parents like resume_lwp does, so at this point the vfork
  parent is resumed.  This feels like the start of the bug, and this
  is where I'm proposing to fix things, but, resuming the vfork parent
  isn't the worst thing in the world because....

  7. As the vfork child is still alive the kernel holds the vfork
  parent stopped,

  8. Eventually the child performs its exec and GDB is sent and EXECD
  event.  However, because the parent is resumed, as soon as the child
  performs its exec the vfork parent also sends a VFORK_DONE event to
  GDB,

  9. Depending on timing both of these events might seem to arrive in
  GDB at the same time.  Normally GDB expects to see the EXECD or
  EXITED/SIGNALED event from the vfork child before getting the
  VFORK_DONE in the parent.  We know this because it is as a result of
  the EXECD/EXITED/SIGNALED that GDB detaches from the parent (see
  handle_vfork_child_exec_or_exit for details).  Further the comment
  in target/waitstatus.h on TARGET_WAITKIND_VFORK_DONE indicates that
  when we remain attached to the child (not the parent) we should not
  expect to see a VFORK_DONE,

  10. If both events arrive at the same time then GDB will randomly
  choose one event to handle first, in some cases this will be the
  VFORK_DONE.  As described above, upon seeing a VFORK_DONE GDB
  expects that (a) the vfork child has finished, however, in this case
  this is not completely true, the child has finished, but GDB has not
  processed the event associated with the completion yet, and (b) upon
  seeing a VFORK_DONE GDB assumes we are remaining attached to the
  parent, and so resumes the parent process,

  11. GDB now handles the EXECD event.  In our case we are detaching
  from the parent, so GDB calls target_detach (see
  handle_vfork_child_exec_or_exit),

  12. While this has been going on the vfork parent is executing, and
  might even exit,

  13. In linux_nat_target::detach the first thing we do is stop all
  threads in the process we're detaching from, the result of the stop
  request will be cached on the lwp_info object,

  14. In our case the vfork parent has exited though, so when GDB
  waits for the thread, instead of a stop due to signal, we instead
  get a thread exited status,

  15. Later in the detach process we try to resume the threads just
  prior to making the ptrace call to actually detach (see
  detach_one_lwp), as part of the process to resume a thread we try to
  touch some registers within the thread, and before doing this GDB
  asserts that the thread is stopped,

  16. An exited thread is not classified as stopped, and so the assert
  triggers!

So there's two bugs I see here.  The first, and most critical one here
is in step #6.  I think that resume_stopped_resumed_lwps should not
resume a vfork parent, just like resume_lwp doesn't resume a vfork
parent.

With this change in place the vfork parent will remain stopped in step
instead GDB will only see the EXECD/EXITED/SIGNALLED event.  The
problems in #9 and #10 are therefore skipped and we arrive at #11,
handling the EXECD event.  As the parent is still stopped #12 doesn't
apply, and in #13 when we try to stop the process we will see that it
is already stopped, there's no risk of the vfork parent exiting before
we get to this point.  And finally, in #15 we are safe to poke the
process registers because it will not have exited by this point.

However, I did mention two bugs.

The second bug I've not yet managed to actually trigger, but I'm
convinced it must exist: if we forget vforks for a moment, in step #13
above, when linux_nat_target::detach is called, we first try to stop
all threads in the process GDB is detaching from.  If we imagine a
multi-threaded inferior with many threads, and GDB running in non-stop
mode, then, if the user tries to detach there is a chance that thread
could exit just as linux_nat_target::detach is entered, in which case
we should be able to trigger the same assert.

But, like I said, I've not (yet) managed to trigger this second bug,
and even if I could, the fix would not belong in this commit, so I'm
pointing this out just for completeness.

There's no test included in this commit.  In a couple of commits time
I will expand gdb.base/foll-vfork.exp which is when this bug would be
exposed.  Unfortunately there are at least two other bugs (separate
from the ones discussed above) that need fixing first, these will be
fixed in the next commits before the gdb.base/foll-vfork.exp test is
expanded.

If you do want to reproduce this failure then you will for certainly
need to run the gdb.base/foll-vfork.exp test in a loop as the failures
are all very timing sensitive.  I've found that running multiple
copies in parallel makes the failure more likely to appear, I usually
run ~6 copies in parallel and expect to see a failure after within
10mins.

gdb: catch more errors in gdb.base/foll-vfork.exp

For *reasons* I was looking at gdb.base/foll-vfork.exp.  This test
script has a proc 'setup_gdb' that could (potentially) fail.  The
setup_gdb proc is called from many places and I, initially, didn't
think that we were checking if setup_gdb had failed or not.

My confusion was because I didn't understand what this tcl construct
did:

  return -code return

this will actually act as a return in the context of a proc's caller,
effectively returning two levels of the call stack.  Neat (I guess).

So it turns out my worries were misplaced, everywhere setup_gdb is
called, if setup_gdb fails then we will (magically) return.

However, I did spot one place where we managed to confuse ourselves
with our cleverness.

In check_vfork_catchpoints, this proc is called to check that GDB is
able to catch vforks or not.  This proc is called early in the test
script, and the intention is that, should this proc fail, we'll mark
the whole test script as unsupported and then move onto the next test
script.

However, check_vfork_catchpoints also uses setup_gdb, and so, if that
call to setup_gdb fails we'll end up returning immediately from
check_vfork_catchpoints, and then continue with the test of _this_
test script, which is not correct.

To fix this I see two choices, one is remove the use of 'return -code
return' from setup_gdb, however, this would require every use of
setup_gdb to then be placed inside:

  if { ![setup_gdb] } {
    return
  }

Or, I can wrap the one call to setup_gdb in check_vfork_catchpoints
and check its return code.

I chose the second option as this is the smaller code change.

There should be no change in what is tested after this commit.

Automatic date update in version.in

PR10957, Missing option to really print section+offset

Many of the reloc error messages have already been converted from
using %C to using %H in ld.bfd, to print section+offset as well as
file/line/function.  This catches a few remaining, and changes gold to
do the same.

PR 10957
bfd/
* elf32-sh.c (sh_elf_relocate_section): Use %H in error messages.
gold/
* object.cc (Relocate_info::location): Always report section+offset.
* testsuite/debug_msg.sh: Adjust to suit.
* testsuite/x32_overflow_pc32.sh: Likewise.
* testsuite/x86_64_overflow_pc32.sh: Likewise.
ld/
* emultempl/pe.em (read_addend): Use %H in error message.
* emultempl/pep.em (read_addend): Likewise.
* ldcref.c (check_reloc_refs): Likewise.
* ldmain.c (warning_find_reloc, undefined_symbol): Likewise.
* pe-dll.c (pe_create_import_fixup): Likewise.
* testsuite/ld-cris/undef2.d: Adjust expected output to suit.
* testsuite/ld-cris/undef3.d: Likewise.
* testsuite/ld-elf/shared.exp: Likewise.
* testsuite/ld-i386/compressed1.d: Likewise.
* testsuite/ld-ia64/line.exp: Likewise.
* testsuite/ld-plugin/lto.exp: Likewise.
* testsuite/ld-undefined/undefined.exp: Likewise.
* testsuite/ld-x86-64/compressed1.d: Likewise.
* testsuite/ld-x86-64/line.exp: Likewise.
* testsuite/ld-x86-64/pr27587.err: Likewise.

Support NEXT_SECTION in ALIGNOF and SIZEOF

This patch is aimed at making __bss_start properly aligned with the
first of any bss-style sections following.  Most of the work here
involves keeping track of the last output section seen when processing
the linker script.

You can almost align __bss_start properly by using
${RELOCATING+. = ALIGN(${DATA_SDATA-${NO_SMALL_DATA-ALIGNOF(.${SBSS_NAME}) != 0 ? ALIGNOF(.${SBSS_NAME}) : }}${BSS_PLT+ALIGNOF(.plt) != 0 ? ALIGNOF(.plt) : }ALIGNOF(.${BSS_NAME}));}
and changing every place that defines NO_SMALL_DATA to use " ", but
having two .plt sections (marked SPECIAL) on some backends foils that
idea.  The problem is that you only want to pick up the following
.plt, not the one preceeding __bss_start in the data segment if the
backend decides that is the proper .plt section.

Perhaps that could be fixed too, but I decided instead to extend the
linker script a little.  THIS_SECTION and PREV_SECTION could easily be
added too.

* ld.texi (ALIGNOF, SIZEOF): Update and mention NEXT_SECTION.
* ldexp.c (output_section_find): New function.
(fold_name <ALIGNOF, SIZEOF>): Use output_section_find.
(exp_fold_tree): Add os parameter.  Adjust all calls.
(exp_fold_tree_no_dot, exp_get_vma, exp_get_power): Likewise.
* ldexp.h (struct ldexp_control): Add last_os.
(exp_fold_tree, exp_fold_tree_no_dot): Update prototypes.
(exp_get_vma, exp_get_power): Likewise.
* ldlang.c: Pass last output section to expression folder
calls throughout file.
(open_input_bfds): Add os parameter to track last os seen.
(lang_size_sections_1): Rename output_section_statement param
to current_os.  Track last os.
(lang_do_assignments_1): Track last os.
* scripttempl/arclinux.sc: Align to ALIGNOF NEXT_SECTION
before defining __bss_start.
* scripttempl/elf.sc: Likewise.
* scripttempl/elf64bpf.sc: Likewise.
* scripttempl/elf64hppa.sc: Likewise.
* scripttempl/elf_chaos.sc: Likewise.
* scripttempl/elfarc.sc: Likewise.
* scripttempl/elfd10v.sc: Likewise.
* scripttempl/elfxtensa.sc: Likewise.
* scripttempl/epiphany_4x4.sc: Likewise.
* scripttempl/iq2000.sc: Likewise.
* scripttempl/mep.sc: Likewise.
* scripttempl/nds32elf.sc: Likewise.
* scripttempl/xstormy16.sc: Likewise.
* testsuite/ld-x86-64/pe-x86-64-5.od: Update expected __bss_start.
* testsuite/ld-x86-64/pe-x86-64-5.rd: Likewise.

[gdb/testsuite] Handle has_native_target in gdb.testsuite/gdb-caching-proc-consistency.exp

With test-case gdb.testsuite/gdb-caching-proc-consistency.exp we run into:
...
ERROR: no fileid for xerxes
Couldn't send help target native to GDB.
UNRESOLVED: <exp>: have_native_target: initial: help target native
...

Fix this by handling have_native_target in
gdb.testsuite/gdb-caching-proc-consistency.exp.

Tested on x86_64-linux.

Automatic date update in version.in

gdb/tui: make tui_win_info::title private

This commit builds on this earlier work:

  commit 9fe01a376b2fb096e4836e985ba316ce9dc02399
  Date:   Thu Jun 29 11:26:55 2023 -0600

      Update TUI window title when changed

and makes tui_win_info::title private, renaming to m_title at the same
time.  There's a new tui_win_info::title() member function to provide
read-only access to the title.

There should be no user visible changes after this commit.

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

gdb: style filenames in separate debug file warnings

After the commit:

  commit 6647f05df023b63bbe056e9167e9e234172fa2ca
  Date:   Tue Jan 24 18:13:38 2023 +0100

      gdb: defer warnings when loading separate debug files

It was pointed out[1] that the warnings being deferred and then later
emitted lacked styling.  The warnings lacked styling before the above
commit, but it was suggested that the filenames in these warnings
should be styled, and this commit does this.

There were a couple of previous attempts[2][3][4] to solve this
problem, but these all tried to extend the mechanism introduced in the
above commit, the deferred warnings were placed directly into a
std::vector, but now we tried to, when appropriate, style these
warnings.  The review feedback that this approach looked too complex.

So instead, this revision adds a new helper class 'deferred_warnings'
which can be used to collect a set of deferred warnings, and then emit
these deferred warnings later, if needed.  This helper class hides the
complexity, so at the point the deferred warning is created no extra
logic is required.

The deferred_warnings class will style the deferred warnings only if
gdb_stderr supports styling.  GDB's warnings are sent to gdb_stderr,
so this should ensure we only style when expected.

There was also review feedback[5] that all of the warnings should be
bundled into a single string_file, this has not been done.  I feel
pretty strongly that separate warnings should be emitted using
separate "warning" calls.  If we do end up with multiple warnings in
this case they aren't really related, one will be about looking up
debug via .gnu_debuglink, while the other will be about build-id based
lookup.  So I'd really rather keep the warnings separate.

[1] https://inbox.sourceware.org/gdb-patches/87edr9pcku.fsf@tromey.com/
[2] https://inbox.sourceware.org/gdb-patches/20230216195604.2685177-1-ahajkova@redhat.com/
[3] https://inbox.sourceware.org/gdb-patches/20230217123547.2737612-1-ahajkova@redhat.com/
[4] https://inbox.sourceware.org/gdb-patches/20230320145638.1202335-1-ahajkova@redhat.com/
[5] https://inbox.sourceware.org/gdb-patches/87o7nh1g8h.fsf@tromey.com/

Co-Authored-By: Alexandra Hájková <ahajkova@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

[gdb/testsuite] Fix gdb.dwarf2/forward-spec.exp with read1

When running test-case gdb.dwarf2/forward-spec.exp with check-read1 we run
into:
...
    parent:     ((cooked_index_entry *) 0xFAIL: <exp>: v has a parent
7fdc1c002ed0) [ns]^M
...

The problem is using regexps containing '.' to avoid escaping, which makes
them too generic.

Fix this by eliminating the '.' from the regexps.

Tested on x86_64-linux.

Automatic date update in version.in

Use correct inferior in Inferior.read_memory et al

A user noticed that Inferior.read_memory and a few other Python APIs
will always use the currently selected inferior, not the one passed to
the call.

This patch fixes the bug by arranging to switch to the inferior.  I
found this same issue in several APIs, so this fixes them all.

I also added a few missing calls to INFPY_REQUIRE_VALID to these
methods.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30615
Approved-By: Pedro Alves <pedro@palves.net>

Introduce scoped_restore_current_inferior_for_memory

This introduces a new class,
scoped_restore_current_inferior_for_memory, and arranges to use it in
a few places.  This class is intended to handle setting up and
restoring the various globals that are needed to read or write memory
-- but without invalidating the frame cache.

I wasn't able to test the change to aix-thread.c.

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

Remove obsolete comment from gdbthread.h

A comment in gdbthread.h refers to a global that no longer exists.

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

Rename Python variable in py-inferior.exp

py-inferior.exp creates a Python variable named 'str'.  This clashes
with the built-in type of the same name and can be confusing when
trying to evaluate Python code when debugging the test case.  This
patch renames it.

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

Refactor py-inferior.exp

This changes py-inferior.exp to make it a bit more robust when adding
new inferiors during the course of the test.

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

Minor cleanups in py-inferior.exp

While working on this series, I noticed a some oddities in
py-inferior.exp.  One is an obviously incorrect comment, and the
others are confusing test names.  This patch fixes these.

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

Revert "Simplify auto_load_expand_dir_vars and remove substitute_path_component"

This reverts commit 02601231fdd91a7bd4837ce202906ea2ce661489.

This commit was a refactoring to remove an xrealloc and simplify
utils.[ch].  However, it has a flaw -- it mishandles a substitution
like "$datadir/subdir".

I am backing out the patch in the interests of fixing the regression
before GDB 14.  It can be reinstated (with modifications) later if we
like.

Regression tested on x86-64 Fedora 36.

Test that native targets can read a tdesc without a process attached.

This ensures that 'unset tdesc filename' does not generate any output
on a "bare" native target inferior without an attached process.

Add a have_native_target helper function for use with require.

Move logic from auto-connect-native-target.exp into this helper.

*-linux-nat: Handle null inferior in read_description.

Don't invoke ptrace in the target read_description method if there is
not an active inferior to query via ptrace.  Instead, use the default
register set for the architecture.

Previously the native target could report an error from a failed
ptrace operation when fetching a tdesc without an attached process.
For example on Linux x86-64:

(gdb) target native
Done.  Use the "run" command to start a process.
(gdb) unset tdesc filename
Couldn't get CS register: No such process.

*-fbsd-nat: Handle null inferior in read_description.

Don't invoke ptrace in the target read_description method if there is
not an active inferior to query via ptrace.  Instead, use the default
register set for the architecture.

Previously the native target could report an error from a failed
ptrace operation when fetching a tdesc without an attached process.
For example on FreeBSD/amd64:

(gdb) target native
Done.  Use the "run" command to start a process.
(gdb) unset tdesc filename
Couldn't get registers: Operation not permitted.

Re: Let '^' through the lexer

Fix "make pdf".

gdb/doc: document '+' argument for 'list' command

The command 'list' has accepted the argument '+' for many years already,
but this option wasn't documented either in the texinfo docs or in the
help text for the command.  This commit documents it.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/cli: Improve UX when using list with no args

When using "list" with no arguments, GDB will first print the lines
around where the inferior is stopped, then print the next N lines until
reaching the end of file, at which point it warns the user "Line X out
of range, file Y only has X-1 lines.".  This is usually desirable, but
if the user can no longer see the original line, they may have forgotten
the current line or that a list command was used at all, making GDB's
error message look cryptic. It was reported in bugzilla as PR cli/30497.

This commit improves the user experience by changing the behavior of
"list" slightly when a user passes no arguments.  It now prints that the
end of the file has been reached and recommends that the user use the
command "list ." instead.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30497
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/cli: add '.' as an argument for 'list' command

Currently, after the user has used the list command once, there is no
self-contained way to ask GDB to print the location where the inferior is
stopped.  The current best options require either using a separate
command to scope out where the inferior is stopped, or using "list *$pc"
requiring knowledge of GDB standard registers.  This commit adds a way
to do that using '.' as a new argument for the 'list' command.  If the
inferior isn't running, the command prints around the main function.

Because this necessitated having the inferior running and the test was
(seemingly unnecessarily) using printf in a non-essential way and it
would make the resulting log harder to read for no benefit, it was
replaced by a different statement.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/cli: Factor out code to list lines around a given line

A future patch will add more situations that calculates "lines around a
certain point" to be printed using print_source_lines, and the logic
could be re-used. As a preparation for those commits, this one factors
out that part of the logic of the list command into its own function.
No functional changes are expected

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

gprofng: 30602 [2.41] gprofng test hangs on i686-linux-gnu

There were several problems in the gprofng testing:
 - we did not catch a timeout for each test.
 - we used exit() to stop a failed test. But this stops all other tests.
 - we used a time_t (long) type in smalltest.c instead of a long long type.

PR gprofng/30602
* configure.ac: Launch only native testing.
* configure: Rebuild.
* testsuite/config/default.exp: Set TEST_TIMEOUT.
* testsuite/gprofng.display/setpath_map.exp: Use return instead of exit.
* testsuite/gprofng.display/gp-archive.exp: Likewise.
* testsuite/gprofng.display/gp-collect-app_F.exp: Likewise.
* testsuite/gprofng.display/display.exp: Delete an unnecessary test
for native testing.
* testsuite/lib/display-lib.exp (run_native_host_cmd): Add timeout.
* testsuite/lib/smalltest.c: Use a long long type instead of time_t.

Make the default gas symbol hash table larger

We may as well start with the symbol table a little larger, saving
time resizing.  Even a simple C hello world compiled with -O2 -g will
exceed 16 symbols (by well over 3 times with gcc-11).

* symbols.c (symbol_begin): Create sy_hash with more entries.

Fix loongarch build with gcc-4.5

* loongarch-opc.c (loongarch_alias_opcodes): Don't trigger
gcc-4.5 bug in handling of struct initialisation.

More tidies to objcopy archive handling

This makes sure copy_archive exits with ibfd and obfd closed.  Error
paths didn't do that, leading to memory leaks.  None of this matters
very much.

* objcopy.c (copy_archive): bfd_close ibfd and obfd on error
return paths.  Remove braces around "list" free.
(copy_file): Don't close invalid file descriptor.

AIX_WEAK_SUPPORT

Making target code depend on a host define like _AIX52 is never
correct, so out it goes.  Also, sort some config.bfd entries a little
to make it more obvious there is a config difference between aix5.1
and aix5.2.  These two changes should make no difference to anything
in binutils.  The gas define of AIX_WEAK_SUPPORT on the other hand was
wrong, so fix that.  Finally, fix some testsuite fails on aix < 5.2 by
simply not running the tests.

include/
* coff/internal.h (C_WEAKEXT): Don't depend on _AIX52.
bfd/
* coffcode.h (coff_slurp_symbol_table): Don't depend on _AIX52.
(coff_classify_symbol): Likewise.
* config.bfd: Sort some entries.
gas/
* configure.ac (AIX_WEAK_SUPPORT): Don't set for aix5.[01].
* configure: Regenerate.
* testsuite/gas/ppc/aix.exp (xcoff-visibility-1*) Don't run
for aix < 5.2.

Automatic date update in version.in

Implement 'Enum_Val and 'Enum_Rep

This patch implements the Ada 2022 attributes 'Enum_Val and 'Enum_Rep.

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

Remove ada_attribute_name

ada_attribute_name uses an array that must be kept in sync with an
enum -- but the comment here refers to an enum that no longer exists.
Looking at the sole caller, I see this can only be called for two
opcodes.  So, remove this entirely and inline it.

Let '^' through the lexer

so that the (existing) code in parser and expression evaluator
actually get to see it and handle it as XOR.  Also adjust docu
to match what's there.

elf_object_p load of dynamic symbols

This fixes an uninitialised memory access on a fuzzed file:
0 0xf22e9b in offset_from_vma /src/binutils-gdb/bfd/elf.c:1899:2
1 0xf1e90f in _bfd_elf_get_dynamic_symbols /src/binutils-gdb/bfd/elf.c:2099:13
2 0x10e6a54 in bfd_elf32_object_p /src/binutils-gdb/bfd/elfcode.h:851:9

Hopefully it will also stop any attempt to load dynamic symbols from
eu-strip debug files.

* elfcode.h (elf_object_p): Do not attempt to load dynamic
symbols for a file with no section headers until all the
program headers are swapped in.  Do not fail on eu-strip debug
files.

Automatic date update in version.in

[gdb/tui] Assume HAVE_WBORDER

The tui border-kind setting allows values acs, ascii and space.

The values ascii and space however don't work well with !HAVE_WBORDER.

Fix this by removing the !HAVE_WBORDER case, which was introduced for Ultrix
support, which is now obsolete.

Tested on x86_64-linux.

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

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

[gdb/tui] Make translate return entry->value instead of entry

The only use of "entry = translate (...)" is entry->value.

Simplify using the function by returning entry->value instead.

Tested on x86_64-linux.

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

[gdb/tui] Merge tui border-kind corner translation tables

The tables:
- tui_border_kind_translate_ulcorner
- tui_border_kind_translate_urcorner
- tui_border_kind_translate_llcorner
- tui_border_kind_translate_lrcorner
are identical.

Merge and rename to tui_border_kind_translate_corner.

Tested on x86_64-linux.

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

[gdb/tui] Introduce translate_acs

In function tui_update_variables we have the somewhat inconvenient:
...
  entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
  int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
...

Add a new function translate_acs, that allows us to do the more straighforward:
...
  int val = translate_acs (tui_border_kind, tui_border_kind_translate_lrcorner,
   ACS_LRCORNER);
...

By special-casing "acs" in translate_acs, we can now remove the acs entries
from the translation tables.

Tested on x86_64-linux.

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

[gdb/tui] Remove default entries in TUI translation tables

The TUI translation tables contain default entries at the end:
...
static struct tui_translate tui_border_kind_translate_hline[] = {
  { "space",    ' ' },
  { "ascii",    '-' },
  { "acs",      -1 },
  { 0, 0 },
  { "ascii",    '-' }
};
...

A simpler way of implementing this would be to to declare the first (or last)
entry the default, but in fact these default entries are not used.

Make this explicit by removing the default entries, and asserting in translate
that an entry will always be found.

Tested on x86_64-linux.

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

.noinit and .persistent for msp430

Similar to the previous patch, but also tidy a few more sections.

* scripttempl/elf32msp430.sc (.text, .rodata, .data, .bss, .noinit),
(.persistent): Align the section rather than aligning inside.

.noinit and .persistent alignment

It's more elegant to make the section match up with its "_start"
symbol.  We could align by setting the address of the section (by
using ALIGN before the colon), but this way we also set sh_addralign
to at least $ALIGNMENT.

* scripttempl/elf.sc (.noinit, .persistent): Align the output
section rather than using ". = ALIGN();" at the beginning.
Set address to zero when not a final link.

Re: Align linkerscript symbols according to ABI

Align dot before symbols defined outside of output sections.  Before _end
is already aligned.

* scripttempl/elf.sc (def_symbol): Tidy excess space.
(_edata): Align before emitting symbol when SYMBOL_ABI_ALIGNMENT.

Re: Keeping track of rs6000-coff archive element pointers

bfd/
* coff-rs6000.c (add_range): Revise comment, noting possible fail.
(_bfd_xcoff_openr_next_archived_file): Start with clean ranges.
binutils/
* bfdtest1.c: Enhance to catch errors on second scan.

Automatic date update in version.in

Remove some TODOs from gdb.cp tests

This patch removes many TODOs from the gdb.cp tests.
Going through the patch:

* bs15503.exp - these have been commented out forever and rely on
  libstdc++ debuginfo.  It's better to just remove these.

* classes.exp - the test is wrong, I think, according to the C++ ABI
  that gdb understands; and the test can be fixed and comments removed
  with a simple change to the code.

* ctti.exp - there's no need to bail out any more, as the test works.

* exception.exp - the code relying on the line numbers can't work,
  because gdb never prints that message anyway.

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

x86: simplify table-referencing macros

First of all it is entirely unclear why THREE_BYTE_TABLE_PREFIX() was
introduced by bf890a93a7c4. Nothing uses the .prefix_requirement values
from the two relevant entries.

And then having VEX_Cn_TABLE() and friends take arguments is misleading.
These aren't used (or pointlessly used in the case of VEX_C5_TABLE); the
respective table index is decoded from the insn (or implied in the case
of VEX_C5_TABLE).

x86: convert 0FXOP to just XOP in enumerator names

There's nothing 0f-ish in XOP encodings.

x86: misc further register-only insns don't need to go through mod_table[]

Several already use OP_R(), which rejects the memory forms of insns, and
a few others can easily be converted to do so as well. Note that for it
to be able to use BadOp() without forward declaration, OP_Skip_MODRM() is
moved down.

While there add the previously missing PREFIX_OPCODE to legacy opcode
0FD7.

x86: various operations on mask registers can avoid going through mod_table[]

Now that we have OP_R(), use it here as well, while wiring memory-only
operands to OP_M() at the same time. To keep the number of consumed
opcode bytes similar to before, make BadOp() also account for VEX/XOP/
EVEX prefix bytes. To keep that change simple, convert need_vex to an
actual count of prefix bytes (keeping intact all prior boolean uses of
the field).

Note how this improves disassembly of such bad encodings, by at least
leaving a hint towards what a "nearby" instruction is. (For KSHIFT*
change the immediates test testcases use, such that disassembly remains
sufficiently in sync.)

While there also use Ux for VPMOV{B,W,D,Q}2M, where decoding through
mod_table[] was missing in the earlier scheme.

x86: slightly rework handling of some register-only insns

Fold OP_MS() and OP_XS() into OP_R(), paralleling OP_M(). Use operand
names (largely) matching those in the SDM. For 128-bit-only forms use
Uxmm though, marking 256-bit forms as bad. This then allows no longer
going through vex_len_table[] for two of the insns.

Specifically _do not_ continue to mis-use v_mode.

x86: SIMD shift-by-immediate don't need to go through mod_table[]

OP_MS() and OP_XS() reject memory forms of insns quite fine. This then
also eliminates mis-named enumerators (we use M_1 for register forms).

x86: misc further memory-only insns don't need to go through mod_table[]

Several already use OP_M(), which rejects the register forms of insns,
and a few others can easily be converted to do so as well. (Note that
FXSAVE_Fixup() wires through to OP_M(). Note further that OP_IndirE(),
which wasn't placed very well anyway, is moved down to avoid the need to
forward-declare BadOp().)

Also adjust formatting of and drop PREFIX_OPCODE from a few adjacent
entries.

x86: {,V}MOVNT* don't need to go through mod_table[]

Most of them use Mx already for the memory operand, which rejects the
register form of the insn. Use that operand type also for the two EVEX
forms which so far have used EXEvexXNoBcst (and thus failed to reject
the register forms), compensating by flagging broadcast as bad for all
Mx. This way several other insns which don't permit embedded broadcast
either are also covered at the same time.

x86: fold legacy/VEX {,V}MOV{H,L}* entries

By changing decode order to do ModR/M.mod last (rather than VEX.L), the
VEX entries (which are already reused by EVEX decoding) can be folded
with their legacy counterparts as well. Note how this change of decode
order also allows removing two auxiliary #define-s, which were
introduced during earlier folding (because of that unhelpful order of
steps).

x86: fold certain legacy/VEX table entries

Introduce macro V to expand to 'v' in the VEX/EVEX case, and replace a
couple of abort()s where legacy code can now legitimately make it. While
there for {,V}LDDQU drop hoing through mod_table[] - OP_M() rejects
register operands quite fine.

ld/PDB: fix off-by-1 in add_globals_ref()

Copying one too many bytes can corrupt memory, detected/reported by
glibc on a 32-bit distro.

Automatic date update in version.in

Remove target_close

I noticed that target_close is only called in two places:
solib-svr4.c, and target_ops_ref_policy::decref.

This patch fixes the former by changing target_bfd_reopen to return a
target_ops_up and then fixing the sole caller.  Then it removes
target_close by inlining its body into the decref method.

The advantage of this approach is that targets are now automatically
managed.

Regression tested on x86-64 Fedora 38.

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

Update TUI window title when changed

I wrote a TUI window in Python, and I noticed that setting its title
did not result in a refresh, so the new title did not appear.  This
patch corrects this problem.

Add Ada scope test for DAP

This adds a DAP test for fetching scopes and variables with an Ada
program.  This test is the reason that the FrameVars code does not
check is_constant on the symbols it returns.

Note that this test also shows that string-printing is incorrect in
Ada.  This is a known bug but I'm still considering how to fix it.

Handle typedefs in no-op pretty printers

The no-ops pretty-printers that were introduced for DAP have a classic
gdb bug: they neglect to call check_typedef.  This will cause some
strange behavior; for example not showing the children of a variable
whose type is a typedef of a structure type.  This patch fixes the
oversight.

Reimplement DAP stack traces using frame filters

This reimplements DAP stack traces using frame filters.  This slightly
simplifies the code, because frame filters and DAP were already doing
some similar work.  This also renames RegisterReference and
ScopeReference to make it clear that these are private (and so changes
don't have to worry about other files).

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

Simplify FrameVars

FrameVars implements its own variant of Symbol.is_variable.  This
patch replaces this code.

Fix oversights in frame decorator code

The frame decorator "FrameVars" code misses a couple of cases,
discovered when working on related DAP changes.

First, fetch_frame_locals does not stop when reaching a function
boundary.  This means it would return locals from any enclosing
functions.

Second, fetch_frame_args assumes that all arguments are at the
outermost scope, but this doesn't seem to be required by gdb.

Add new interface to frame filter iteration

This patch adds a new function, frame_iterator, that wraps the
existing code to find and execute the frame filters.  However, unlike
execute_frame_filters, it will always return an iterator -- whereas
execute_frame_filters will return None if no frame filters apply.

Nothing uses this new function yet, but it will used by a subsequent
DAP patch.

Fix execute_frame_filters doc string

When reading the doc string for execute_frame_filters, I wasn't sure
if the ranges were inclusive or exclusive.  This patch updates the doc
string to reflect my findings, and also fixes an existing typo.

Change 'handle_id' to be a local variable

The global variable 'handle_id' in tracectf.c is only used in a single
function, so change it to be a local variable.

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

Move definition of ctf_target type

This moves the definition of the ctf_target type into the
HAVE_LIBBABELTRACE block.  This type is only used in this block, so it
makes sense to only define it there.

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

Constify tfile_interp_line

This adds 'const' to tfile_interp_line.

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

Use function_view in traceframe_walk_blocks

This change traceframe_walk_blocks to take a function_view.  This
simplifies the code somewhat and lets us entirely remove one helper
function.

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

Use unique_ptr for trace_dirname

This changes trace_dirname to use unique_ptr, removing some manual
memory management.

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

Use unique_ptr for trace_filename

This changes trace_filename to use unique_ptr, removing some manual
memory management.

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

Replace use of xfree with byte_vector

This replaces a use of xfree with a byte_vector.

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

Remove a use of xfree

This removes a use of xfree from tracefile-tfile.c, replacing it with
a unique_xmalloc_ptr.

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

Avoid crash with absolute symbol

A user supplied an executable and a remote logfile that could be used
to crash gdb.  The problem is that the BFD section for a particular
symbol was null, because the section was not marked "allocated".
Digging deeper, the problem was that elfread.c dropped the section for
absolute symbols.  This patch fixes the crash.

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

gdbserver: handle all eval_result_type values in tracepoint.cc

It was pointed out[1] that after this commit:

  commit 3812b38d8de5804ad3eadd6c7a5d532402ddabab
  Date:   Thu Oct 20 11:14:33 2022 +0100

      gdbserver: allow agent expressions to fail with invalid memory access

Now that agent expressions might fail with the error
expr_eval_invalid_memory_access, we might overflow the
eval_result_names array in tracepoint.cc.  This is because the
eval_result_names array does not include a string for either
expr_eval_invalid_goto or expr_eval_invalid_memory_access.

I don't know if having expr_eval_invalid_goto missing is also a
problem, but it feels like eval_result_names should just include a
string for every possible error.

I could just add two more strings into the array, but I figure that a
more robust solution will be to move all of the error types, and their
associated strings, into a new ax-result-types.def file, and to then
include this file in both ax.h and tracepoint.cc in order to build
the enum eval_result_type and the eval_result_names string array.
Doing this means it is impossible to have a missing error string in
the future.

[1] https://inbox.sourceware.org/gdb-patches/01059f8a-0e59-55b5-f530-190c26df5ba3@palves.net/

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

gdb/testsuite: avoid stack addresses in test names

When comparing the test results for two different runs of GDB I
noticed a difference in the results for gdb.base/frame-view.exp.

The difference was caused by one of the tests including a stack
address in the test name:

  PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select-frame view 0x7ffff7c5cea8 0x40115b

and

  PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select-frame view 0x7ffff7c5cea8 0x40115b

If for whatever reason the stack address changes between test runs
then it becomes harder to compare results.

Fix this by giving the test a descriptive name that doesn't include a
stack address:

  PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select thread 2 frame from thread 1

and

  PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select thread 2 frame from thread 1

There's no change to what is actually tested after this commit.

gdb/testsuite: return after reporting a test unsupported

In this commit:

  commit 8bcead69665af3a9f9867cd34c3a1daf22120027
  Date:   Tue May 23 11:25:01 2023 +0100

      gdb/testsuite: add test for core file with a 0 pid

a new test gdb.arch/core-file-pid0.exp was added.  This test includes
a pre-generated core file for x86-64 and for other architectures the
test reports 'unsupported'.

However, after reporting 'unsupported' the test failed to perform an
early return, so the test would then carry on and try to actually
perform the test, which resulted in some TCL errors.

Fix this by returning after reporting the test unsupported.

gdb: include location number in breakpoint error message

This commit improves the output of this previous commit:

  commit 2dc3457a454a35d0617dc1f9cc1db77468471f95
  Date:   Fri Oct 14 13:22:55 2022 +0100

      gdb: include breakpoint number in testing condition error message

The earlier commit extended the error message:

  Error in testing breakpoint condition:

to include the breakpoint number, e.g.:

  Error in testing breakpoint condition 3:

This commit extends takes this further, and includes the location
number if the breakpoint has multiple locations, so we might now see:

  Error in testing breakpoint condition 3.2:

Just as with how GDB reports a normal breakpoint stop, if a breakpoint
only has a single location then the location number is not included,
this keeps things nice and consistent.

I've extended one of the tests to cover the new functionality.

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

gdb/testsuite: Testing with the nvfortran compiler

Currently, the Fortran test suite does not run with NVIDIA's Fortran
compiler (nvfortran).

The goal here is to get the tests running and preventing further
regressions during future work. This change does not do anything to fix
existing failures.

Teach the compiler detection about nvfortran. There is no underlying
information about whether this compiler is related to flang classic or
flang, so we cannot reuse the main and type definitions. Therefore, we
explicitly record the main method and type information observed when
using nvfortran.

The main name was extracted by trying to set breakpoints on both MAIN_
and MAIN__.

The following mapping of test to type names was used to extract how
nvfortran reports types.

info-types.exp: fortran_int4, fortran_int8, fortran_real4,
fortran_logical4

common-block.exp: fortran_real8

complex.exp: fortran_complex4 fortran_complex8

logical.exp: fortran_character1. Ran ptype on "c".

Types defined as fortran_complex16 do not compile with nvfortran, so it
was left unset.

gdb.fortran regression tests run with GNU, Intel, Intel LLVM and ACfL.
No regressions detected.

The gdb.fortran test results with nvfortran 23.3 are as follows.

Before:

    # of expected passes        523
    # of unexpected failures    107
    # of known failures         2
    # of unresolved testcases   1
    # of untested testcases     7
    # of duplicate test names   2

After:

    # of expected passes        5696
    # of unexpected failures    271
    # of known failures         12
    # of untested testcases     9
    # of unsupported tests      5

As can be seen from the above, there are now considerably more passing
assertions.

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

Automatic date update in version.in

PR30592 objcopy: allow --set-section-flags to add or remove SHF_X86_64_LARGE

For example, objcopy --set-section-flags .data=alloc,large will add
SHF_X86_64_LARGE to the .data section.  Omitting "large" will drop the
SHF_X86_64_LARGE flag.

The bfd_section flag is named generically, SEC_ELF_LARGE, in case other
processors want to follow SHF_X86_64_LARGE.  SEC_ELF_LARGE has the same
value as SEC_TIC54X_BLOCK used by coff.

bfd/
    * section.c: Define SEC_ELF_LARGE.
    * bfd-in2.h: Regenerate.
    * elf64-x86-64.c (elf_x86_64_section_flags, elf_x86_64_fake_sections,
    elf_x86_64_copy_private_section_data): New.

binutils/
    * NEWS: Mention the new feature for objcopy.
    * doc/binutils.texi: Mention "large".
    * objcopy.c (parse_flags): Parse "large".
    (check_new_section_flags): Error if "large" is used with a
    non-x86-64 ELF target.
    * testsuite/binutils-all/x86-64/large-sections.d: New.
    * testsuite/binutils-all/x86-64/large-sections.s: New.
    * testsuite/binutils-all/x86-64/large-sections-i386.d: New.
    * testsuite/binutils-all/x86-64/large-sections-2.d: New.
    * testsuite/binutils-all/x86-64/large-sections-2-x32.d: New.

Automatic date update in version.in

gdb/cp-namespace.c: Fix assert failure caused by malformed user input

When debugging C++ programs, it is possible to trigger a spurious assert
failure when attempting to set a breakpoint on a malformed symbol name.
Names of the form 'A>::B' and 'A)::B' trigger this assert failure in
cp_lookup_bare_symbol:

    $ gdb gdb
    [...]
    (gdb) br test>::assert
    Function "test>::assert" not defined.
    Make breakpoint pending on future shared library load? (y or [n]) y
    Breakpoint 1 (test>::assert) pending.
    (gdb) start
    [...]
    cp-namespace.c:181: internal-error: cp_lookup_bare_symbol: Assertion `strstr (name, "::") == NULL' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    ----- Backtrace -----
    0x5217e2 gdb_internal_backtrace_1
            /home/amerey/binutils-gdb/gdb/bt-utils.c:122
    0x521885 _Z22gdb_internal_backtracev
            /home/amerey/binutils-gdb/gdb/bt-utils.c:168
    0xaf8303 internal_vproblem
            /home/amerey/binutils-gdb/gdb/utils.c:396
    0xaf86be _Z15internal_verrorPKciS0_P13__va_list_tag
            /home/amerey/binutils-gdb/gdb/utils.c:476
    0xccdb3f _Z18internal_error_locPKciS0_z
            /home/amerey/binutils-gdb/gdbsupport/errors.cc:58
    0x5dded9 cp_lookup_bare_symbol
            /home/amerey/binutils-gdb/gdb/cp-namespace.c:181
    0x5de39d cp_lookup_symbol_in_namespace
            /home/amerey/binutils-gdb/gdb/cp-namespace.c:328
    [...]

Currently this assert is skipped if the symbol name contains '<' or '('.
Fix this spurious failure by also skipping the assert when the symbol
name contains '>' or ')'.

Regression tested on F38 x86_64.

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

Automatic date update in version.in

Fix result of DAP setExpression

A co-worker, Andry, noticed that the DAP setExpression implementation
returned the wrong fields -- it used "result" rather than "value", and
included "memoryReference", which isn't in the spec (an odd oversight,
IMO).

This patch fixes the problems.

Remove unchecked casts to mi_interp

Simon noticed a crash that could be caused via new Python
gdb.execute_mi function.  Looking into this, I found a few unchecked
casts to mi_interp, like:

-  struct mi_interp *mi = (struct mi_interp *) command_interp ();

This patch replaces all such casts with safer variants.

For -gdb-exit and mi_load_progress, I chose to have the functions
simply not generate any output.  It didn't seem useful to do so.

Some casts I eliminated by adding a parameter to a function.  Then, in
mi_execute_command, I changed the code to use
gdb::checked_static_cast.  This is appropriate because this particular
overload can only be called by the MI interpreter.

There does not seem to be a very good way to test -gdb-exit.

Regression tested on x86-64 Fedora 36.

gdb: check max-value-size when reading strings for printf

I noticed that the printf code for strings, printf_c_string and
printf_wide_c_string, don't take max-value-size into account, but do
load a complete string from the inferior into a GDB buffer.

As such it would be possible for an badly behaved inferior to cause
GDB to try and allocate an excessively large buffer, potentially
crashing GDB, or at least causing GDB to swap lots, which isn't
great.

We already have a setting to protect against this sort of thing, the
'max-value-size'.  So this commit updates the two function mentioned
above to check the max-value-size and give an error if the
max-value-size is exceeded.

If the max-value-size is exceeded, I chose to continue reading
inferior memory to figure out how long the string actually is, we just
don't store the results.  The benefit of this is that when we give the
user an error we can tell the user how big the string actually is,
which would allow them to correctly adjust max-value-size, if that's
what they choose to do.

The default for max-value-size is 64k so there should be no user
visible changes after this commit, unless the user was previously
printing very large strings.  If that is the case then the user will
now need to increase max-value-size.

gdb: remove last alloca call from printcmd.c

This commit removes the last alloca call from printcmd.c.  This is
similar to the patches I originally posted here:

  https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/

However, this change was not included in that original series.

The original series received push back because it was thought that
replacing alloca with a C++ container type would introduce unnecessary
malloc/free overhead.

However, in this case we are building a string, and (at least for
GCC), the std::string type has a small string optimisation, where
small strings are stored on the stack.

And in this case we are building what will usually be a very small
string, we're just constructing a printf format specifier for a hex
value, so it'll be something like '%#x' -- though it could also have a
width in there too -- but still, it should normally fit within GCCs
small string buffer.

So, in this commit, I propose replacing the use of alloca with a
std::string.  This shouldn't result (normally) in any additional
malloc or free calls, so should be similar in performance to the
original approach.

There should be no user visible differences after this commit.

gdb: remove two uses of alloca from printcmd.c

Remove a couple of uses of alloca from printcmd.c, and replace them
with gdb::byte_vector.

An earlier variant of this patch was proposed in this thread:

  https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/

however, there was push back on that thread due to it adding extra
dynamic allocation, i.e. moving the memory buffers off the stack on to
the heap.

However, of all the patches originally proposed, I think in these two
cases moving off the stack is the correct thing to do.  Unlike all the
other patches in the original series, where the data being read
was (mostly) small in size, a register, or a couple of registers, in
this case we are reading an arbitrary string from the inferior.  This
could be any size, and so should not be placed on the stack.

So in this commit I replace the use of alloca with std::byte_vector
and simplify the logic a little (I think) to take advantage of the
ability of std::byte_vector to dynamically grow in size.

Of course, really, we should probably be checking the max-value-size
setting as we load the string to stop GDB crashing if a corrupted
inferior causes GDB to try read a stupidly large amount of
memory... but I'm leaving that for a follow on patch.

There should be no user visible changes after this commit.

gdb: fix printf of wchar_t early in a gdb session

Given this test program:

  #include <wchar.h>

  const wchar_t wide_str[] = L"wide string";

  int
  main (void)
  {
    return 0;
  }

I observed this GDB behaviour:

  $ gdb -q /tmp/printf-wchar_t
  Reading symbols from /tmp/printf-wchar_t...
  (gdb) start
  Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8.
  Starting program: /tmp/printf-wchar_t

  Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8
  25   return 0;
  (gdb) printf "%ls\n", wide_str

  (gdb)

Notice that the printf results in a blank line rather than the
expected 'wide string' output.

I tracked the problem down to printf_wide_c_string (in printcmd.c), in
this function we do this:

  struct type *wctype = lookup_typename (current_language,
 "wchar_t", NULL, 0);
  int wcwidth = wctype->length ();

the problem here is that 'wchar_t' is a typedef.  If we look at the
comment on type::length() we see this:

  /* Note that if thistype is a TYPEDEF type, you have to call check_typedef.
     But check_typedef does set the TYPE_LENGTH of the TYPEDEF type,
     so you only have to call check_typedef once.  Since value::allocate
     calls check_typedef, X->type ()->length () is safe.  */

What this means is that after calling lookup_typename we should call
check_typedef in order to ensure that the length of the typedef has
been setup correctly.  We are not doing this in printf_wide_c_string,
and so wcwidth is incorrectly calculated as 0.  This is what leads GDB
to print an empty string.

We can see in c_string_operation::evaluate (in c-lang.c) an example of
calling check_typedef specifically to fix this exact issue.

Initially I did fix this problem by adding a check_typedef call into
printf_wide_c_string, but then I figured why not move the
check_typedef call up into lookup_typename itself, that feels like it
should be harmless when looking up a non-typedef type, but will avoid
bugs like this when looking up a typedef.  So that's what I did.

I can then remove the extra check_typedef call from c-lang.c, I don't
see any other places where we had extra check_typedef calls.  This
doesn't mean we definitely had bugs -- so long as we never checked the
length, or, if we knew that check_typedef had already been called,
then we would be fine.

I don't see any test regressions after this change, and my new test
case is now passing.

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

ld: fix build with old glibc / gcc

"rename" conflicts with a function of that name, which gcc from that
same timeframe then complains about. Use a name matching that of
struct input_remap's respective field.

arc: Update/Add ARCv3 support.

The ARC HS5x and ARC HS6x processors are based on the new ARCv3 ISA
that implements a full range of 32-bit and 64-bit instructions.  These
processors feature a high-speed 10-stage, dual-issue pipeline that
offers increased utilization of functional units with a limited
increase in power and area.  The HS5x processors feature a 32-bit
pipeline that can execute all ARCv3 32-bit instructions, while the
HS6x processors feature a full 64-bit pipeline and register file that
can execute both 32-bit and 64-bit instructions.  In addition, the ARC
HS6x supports 64-bit virtual and 52-bit physical address spaces to
enable direct addressing of current and future large memories, as well
as 128-bit loads and stores for efficient data movement.

This readelf patch updates/adds Synopsys ARCv3 machine name fileds and
supported relocations.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>