From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rxi8Y-0000Kt-4t for qemu-devel@nongnu.org; Wed, 15 Feb 2012 11:55:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rxi8U-0000yA-2Y for qemu-devel@nongnu.org; Wed, 15 Feb 2012 11:55:22 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:35231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rxi8T-0000xu-OX for qemu-devel@nongnu.org; Wed, 15 Feb 2012 11:55:17 -0500 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Rxi8S-0001vU-2k from meador_inge@mentor.com for qemu-devel@nongnu.org; Wed, 15 Feb 2012 08:55:16 -0800 From: Meador Inge Date: Wed, 15 Feb 2012 10:55:13 -0600 Message-ID: <1329324914-12296-1-git-send-email-meadori@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain Subject: [Qemu-devel] [PATCH v1 0/1] Fix GDB semihosting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi All, GDB semihosting support is broken in the current trunk. When debugging a basic "Hello, World" application via the QEMU GDB stub: $ qemu-system-arm -s -S -M integratorcp -cpu any --semihosting --monitor null --serial null -kernel hello GDB (7.2.50) receives an interrupt before anything is printed: Program received signal SIGINT, Interrupt. As an example, consider this processing of the 'isatty' syscall. 'gdb_do_syscall' gets executed while 'current_run_state == RUN_STATE_RUNNING'. It then changes the VM and GDB server state with: s->state = RS_SYSCALL; vm_stop(RUN_STATE_DEBUG); s->state = RS_IDLE; which leaves the GDB server state in 'RS_IDLE', but since the syscall happens while in the TCG thread the 'RUN_STATE_DEBUG' stop does not happen immediately. This leads to the following course of events: 1. 'gdb_do_syscall' finishes up by sending a 'Fisatty,00000001' packet to the GDB client. 2. 'RUN_STATE_DEBUG' get pulled from the event queue. 3. 'gdb_vm_state_change' is invoked thus causing a 'T05thread:01;' reply to be sent back to the GDB client. 4. A payload of '+$F1#77+' comes in containing the syscall reply and the 'T05' ACK. 5. '+$F1#77' is processed and 'gdb_handle_packet' transitions the state back 'RUN_STATE_RUNNING'. 6. 'gdb_read_byte' starts processing the remaining payload of '+', but the current state is 'RUN_STATE_RUNNING' so 'gdb_read_byte' issues a 'vm_stop(RUN_STATE_PAUSED)' which takes effect immediately. 7. 'gdb_vm_state_change' is invoked thus causing a 'T02thread:01;' reply to be sent back to the GDB client. 8. The GDB client interrupts and breaks the semihosting flow. This patch fixes the problem be staying in the 'RS_SYSCALL' state until next packet read comes in. Therefore keeping any 'T' statuses from being sent back to the GDB client while the syscall is still being processed. Meador Inge (1): gdbserver: Keep VM state status replies from happening during a syscall gdbstub.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) -- 1.7.7.6