From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A1FCD386FC35; Thu, 3 Jun 2021 21:38:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A1FCD386FC35 From: "andrew.burgess at embecosm dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/26819] RISC-V: internal-error: int finish_step_over(execution_control_state*): Assertion Date: Thu, 03 Jun 2021 21:38:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: andrew.burgess at embecosm dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: andrew.burgess at embecosm dot com X-Bugzilla-Target-Milestone: 11.1 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 21:38:45 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26819 --- Comment #40 from Andrew Burgess --- Final comment for the night. I now have this test passing reliably, I chan= ged the file spike-2-hwthread.cfg (this is one of the files that the steps to reproduce document has us download), this is the openocd config file. With= in this file are two lines like this: target create $_TARGETNAME_0 riscv -chain-position $_CHIPNAME.cpu -rtos hwthread target create $_TARGETNAME_1 riscv -chain-position $_CHIPNAME.cpu -coreid= 1 I changed these lines to be this: target create $_TARGETNAME_0 riscv -chain-position $_CHIPNAME.cpu -rtos hwthread -coreid 0 target create $_TARGETNAME_1 riscv -chain-position $_CHIPNAME.cpu -rtos hwthread -coreid 1 And now the test passes just fine. As I've said in previous comments, I'm no openocd expert, I added the extra '-rtos hwthread' for the second core as it is the presence of this rtos set= ting that is causing openocd to send back the thread-id. Maybe there's more goi= ng on here and adding this flag is bad for some reason? I added the '-coreid = 0' to the first core just for symmetry, I suspect 0 is the default. Unless there's new evidence that comes up, I'm pretty convinced that the is= sue here was either openocd has a bug, or openocd was misconfigured, however, I think there is an open issue for whether GDB could/should have handled this situation better? I think that the packets coming from the remote should be considered user input, and as such, we should not rely on them being "correct". As such, w= hen invalid packets arrive GDB should be throwing an error, not quitting with an assertion failure. I'm not really sure where we should be catching this particular error, or w= hat we should do. I doubt we can reasonably expect to recover, I think the tar= get has shown itself to be unreliable in this case (reporting a stop against a thread that should not be running)... --=20 You are receiving this mail because: You are on the CC list for the bug.=