espressif/binutils-gdb
1
0
Fork 0
mirror of https://github.com/espressif/binutils-gdb.git synced 2025-08-06 14:49:38 +08:00
Code Issues Packages Projects Releases Wiki Activity

Fix Ravenscar "process" resume

Browse Source 
A coworker noticed that gdb would send the wrong vCont packet to qemu
when debugging a Ravenscar program:

    > (gdb) thread 2
    > [Switching to thread 2 (Thread 1.2)]
    > #0  0x0000000000001000 in ?? ()

    > (gdb) c
    [...]
    > Sending packet: $vCont;c:p1.1#e2...Ack

Here, we've switched to thread 2, but the packet says to resume thread
1.

This turned out to be a bug in ravenscar_thread_target::resume, which
did not properly handle the case of a "process" resume.  In
particular, the resume method would be passed a ptid of (1, 0, 0) --
but then rewrite this to its saved ptid.

This patch fixes the problem by recognizing this case in the resume
method.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

	* ravenscar-thread.c (ravenscar_thread_target::resume): Handle
	"is_pid" case.
This commit is contained in:
Tom Tromey
2020-08-07 10:26:45 -06:00
parent e09eef98a6
commit 39e2018a4e
2 changed files with 11 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
gdb/ravenscar-thread.c
View File

@ -363,7 +363,12 @@ ravenscar_thread_target::resume (ptid_t ptid, int step,
/* If we see a wildcard resume, we simply pass that on. Otherwise,
arrange to resume the base ptid. */
inferior_ptid = m_base_ptid;
if (ptid != minus_one_ptid)
if (ptid.is_pid ())
{
/* We only have one process, so resume all threads of it. */
ptid = minus_one_ptid;
}
else if (ptid != minus_one_ptid)
ptid = m_base_ptid;
beneath ()->resume (ptid, step, siggnal);
}