public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/26819] RISC-V: internal-error: int finish_step_over(execution_control_state*): Assertion
Date: Thu, 14 Jan 2021 01:27:45 +0000	[thread overview]
Message-ID: <bug-26819-4717-0SKzV9s2i1@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-26819-4717@http.sourceware.org/bugzilla/>

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

--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8f66807b98f7634c43149ea62e454ea8f877691d

commit 8f66807b98f7634c43149ea62e454ea8f877691d
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date:   Wed Jan 13 20:26:58 2021 -0500

    gdb: better handling of 'S' packets

    This commit builds on work started in the following two commits:

      commit 24ed6739b699f329c2c45aedee5f8c7d2f54e493
      Date:   Thu Jan 30 14:35:40 2020 +0000

          gdb/remote: Restore support for 'S' stop reply packet

      commit cada5fc921e39a1945c422eea055c8b326d8d353
      Date:   Wed Mar 11 12:30:13 2020 +0000

          gdb: Handle W and X remote packets without giving a warning

    This is related to how GDB handles remote targets that send back 'S'
    packets.

    In the first of the above commits we fixed GDB's ability to handle a
    single process, single threaded target that sends back 'S' packets.
    Although the 'T' packet would always be preferred to 'S' these days,
    there's nothing really wrong with 'S' for this situation.

    The second commit above fixed an oversight in the first commit, a
    single-process, multi-threaded target can send back a process wide
    event, for example the process exited event 'W' without including a
    process-id, this also is fine as there is no ambiguity in this case.

    In PR gdb/26819 we run into yet another problem with the above
    commits.  In this case we have a single process with two threads, GDB
    hits a breakpoint in thread 2 and then performs a stepi:

      (gdb) b main
      Breakpoint 1 at 0x1212340830: file infinite_loop.S, line 10.
      (gdb) c
      Continuing.

      Thread 2 hit Breakpoint 1, main () at infinite_loop.S:10
      10    in infinite_loop.S
      (gdb) set debug remote 1
      (gdb) stepi
      Sending packet: $vCont;s:2#24...Packet received: S05
      ../binutils-gdb/gdb/infrun.c:5807: internal-error: int
finish_step_over(execution_control_state*): Assertion
`ecs->event_thread->control.trap_expected' failed.

    What happens in this case is that on the RISC-V target displaced
    stepping is not supported, so when the stepi is issued GDB steps just
    thread 2.  As only a single thread was set running the target decides
    that is can get away with sending back an 'S' packet without a
    thread-id.  GDB then associates the stop with thread 1 (the first
    non-exited thread), but as thread 1 was not previously set executing
    the assertion seen above triggers.

    As an aside I am surprised that the target sends pack 'S' in this
    situation.  The target is happy to send back 'T' (including thread-id)
    when multiple threads are set running, so (to me) it would seem easier
    to just always use the 'T' packet when multiple threads are in use.
    However, the target only uses 'T' when multiple threads are actually
    executing, otherwise an 'S' packet it used.

    Still, when looking at the above situation we can see that GDB should
    be able to understand which thread the 'S' reply is referring too.

    The problem is that is that in commit 24ed6739b699 (above) when a stop
    reply comes in with no thread-id we look for the first non-exited
    thread and select that as the thread the stop applies too.

    What we should really do is select the first non-exited, resumed thread,
    and associate the stop event with this thread.  In the above example
    both thread 1 and 2 are non-exited, but only thread 2 is resumed, so
    this is what we should use.

    There's a test for this issue included which works with stock
    gdbserver by disabling use of the 'T' packet, and enabling
    'scheduler-locking' within GDB so only one thread is set running.

    gdb/ChangeLog:

            PR gdb/26819
            * remote.c
            (remote_target::select_thread_for_ambiguous_stop_reply): New
            member function.
            (remote_target::process_stop_reply): Call
            select_thread_for_ambiguous_stop_reply.

    gdb/testsuite/ChangeLog:

            PR gdb/26819
            * gdb.server/stop-reply-no-thread-multi.c: New file.
            * gdb.server/stop-reply-no-thread-multi.exp: New file.

    Change-Id: I9b49d76c2a99063dcc76203fa0f5270a72825d15

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2021-01-14  1:27 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-30 16:11 [Bug gdb/26819] New: " jmatyas at codasip dot com
2020-10-30 16:13 ` [Bug gdb/26819] " jmatyas at codasip dot com
2020-11-08  9:07 ` [Bug gdb/26819] RISC-V: " jmatyas at codasip dot com
2020-11-08 10:07 ` andrew.burgess at embecosm dot com
2020-11-08 11:10 ` jmatyas at codasip dot com
2020-11-08 11:13 ` jmatyas at codasip dot com
2020-11-09  9:51 ` andrew.burgess at embecosm dot com
2021-01-06  6:37 ` jmatyas at codasip dot com
2021-01-06  9:35 ` andrew.burgess at embecosm dot com
2021-01-08 11:03 ` jmatyas at codasip dot com
2021-01-08 16:09 ` simark at simark dot ca
2021-01-14  1:27 ` cvs-commit at gcc dot gnu.org [this message]
2021-01-14  1:29 ` simark at simark dot ca
2021-01-14  9:11 ` andrew.burgess at embecosm dot com
2021-01-14  9:41 ` jmatyas at codasip dot com
2021-01-16 11:00 ` jmatyas at codasip dot com
2021-01-16 11:03 ` jmatyas at codasip dot com
2021-01-16 11:04 ` jmatyas at codasip dot com
2021-01-17  3:36 ` simark at simark dot ca
2021-01-17 22:37 ` jmatyas at codasip dot com
2021-01-17 22:38 ` jmatyas at codasip dot com
2021-01-17 22:39 ` jmatyas at codasip dot com
2021-01-18  5:15 ` simark at simark dot ca
2021-01-18 11:01 ` jmatyas at codasip dot com
2021-01-18 15:23 ` sebastian.huber@embedded-brains.de
2021-01-27 12:35 ` jmatyas at codasip dot com
2021-01-27 16:00 ` simark at simark dot ca
2021-02-07 21:20 ` jmatyas at codasip dot com
2021-02-08  2:00 ` simon.marchi at polymtl dot ca
2021-02-08  2:02 ` simon.marchi at polymtl dot ca
2021-02-20 20:51 ` simark at simark dot ca
2021-02-24  9:17 ` jmatyas at codasip dot com
2021-02-25  7:41 ` jmatyas at codasip dot com
2021-02-25 20:50 ` simark at simark dot ca
2021-03-04 23:23 ` jmatyas at codasip dot com
2021-03-04 23:24 ` jmatyas at codasip dot com
2021-03-04 23:25 ` jmatyas at codasip dot com
2021-03-04 23:25 ` jmatyas at codasip dot com
2021-03-04 23:27 ` simark at simark dot ca
2021-03-04 23:46 ` jmatyas at codasip dot com
2021-03-04 23:49 ` jmatyas at codasip dot com
2021-06-03 20:41 ` andrew.burgess at embecosm dot com
2021-06-03 21:19 ` andrew.burgess at embecosm dot com
2021-06-03 21:38 ` andrew.burgess at embecosm dot com
2021-06-06 14:28 ` brobecker at gnat dot com
2021-06-07  5:28 ` jmatyas at codasip dot com
2021-06-07  8:30 ` andrew.burgess at embecosm dot com
2021-08-06  1:41 ` lennordocdoc0921 at gmail dot com
2022-04-09 15:07 ` [Bug tdep/26819] " tromey at sourceware dot org
2022-11-29 19:38 ` tromey at sourceware dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-26819-4717-0SKzV9s2i1@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).