aboutsummaryrefslogtreecommitdiff
path: root/docs/devel/multiple-iothreads.txt
diff options
context:
space:
mode:
authorMatheus Tavares Bernardino <quic_mathbern@quicinc.com>2023-08-01 12:37:11 -0300
committerRichard Henderson <richard.henderson@linaro.org>2023-08-06 10:10:11 -0700
commit6c78de6eb6f986b2e06e95fabad62731a44aaafd (patch)
treee5d6444cc55dea1753c1a8ddb1e8ef2fe1228d73 /docs/devel/multiple-iothreads.txt
parentc30d0b861cea8539ee0acb55a1a949ed4b5ec82a (diff)
gdbstub: use 0 ("any process") on packets with no PID
Previously, qemu-user would always report PID 1 to GDB. This was changed at dc14a7a6e9 (gdbstub: Report the actual qemu-user pid, 2023-06-30), but read_thread_id() still considers GDB packets with "no PID" as "PID 1", which is not the qemu-user PID. Fix that by parsing "no PID" as "0", which the GDB Remote Protocol defines as "any process". Note that this should have no effect for system emulation as, in this case, gdb_create_default_process() will assign PID 1 for the first process and that is what the gdbstub uses for GDB requests with no PID, or PID 0. This issue was found with hexagon-lldb, which sends a "Hg" packet with only the thread-id, but no process-id, leading to the invalid usage of "PID 1" by qemu-hexagon and a subsequent "E22" reply. Signed-off-by: Matheus Tavares Bernardino <quic_mathbern@quicinc.com> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <78a3b06f6ab90a7ff8e73ae14a996eb27ec76c85.1690904195.git.quic_mathbern@quicinc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Diffstat (limited to 'docs/devel/multiple-iothreads.txt')
0 files changed, 0 insertions, 0 deletions