From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E56763838027; Mon, 7 Jun 2021 08:30:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E56763838027 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: Mon, 07 Jun 2021 08:30:47 +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: --- 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: Mon, 07 Jun 2021 08:30:48 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26819 --- Comment #43 from Andrew Burgess --- Jan, My guess for what is happening is this (and it is just a guess): - GDB sets all threads running, maybe does a step for one thread=20 and continue for all the others, or maybe it really does continue all threads, I doubt it matters. - One thread (lets call it thread 1) stops for a legitimate=20 reason (e.g. breakpoint). - As we are in all stop mode, openocd then tries to stop the remaining threads, but - Before the other thread(s) can be stopped one of them (lets call this=20 thread 2) stops for some other legitimate reason (e.g. breakpoint). - OpenOCD reports the first stop (from thread 1) to GDB, - GDB decides to single step forward just that one thread (thread 1), and so sends a vCont;s:2 to the remote, but - OpenOCD spots that it has a pending stop for thread 2, and so sends that stop back to GDB. It also seems weird that OpenOCD can have multiple threads in existence, but gates its use of sending back the 'thread-id' in a stop packet on whether t= he thread has rtos data attached. I don't know OpenOCD internals, but it feels like, if OpenOCD has multiple target objects in existence then it should al= ways be sending back a thread-id. To be honest, it's really not going to hurt if OpenOCD _always_ sent back a thread-id, even if there is only 1 thread - mu= ch better that than the current situation where sometimes there is no thread-i= d at all. Joel, I started looking at whether we can spot an invalid stop packet coming in, I think I have a plan, I'll post something to the list once I have a patch. --=20 You are receiving this mail because: You are on the CC list for the bug.=