On 02/16/2012 01:08 PM, Peter Maydell wrote:
> On 16 February 2012 18:39, Meador Inge wrote:
>> On 02/15/2012 02:14 PM, Peter Maydell wrote:
>>> I think the right way to deal with both the problem you were seeing
>>> and this related issue is simply not to try to send the syscall
>>> request unti
On 02/15/2012 02:14 PM, Peter Maydell wrote:
> Here's tracing when it goes wrong:
> gdb_do_syscall: vm_stop(RUN_STATE_DEBUG)
> reply='Fread,0003,04000188,0200'
> gdb_chr_receive bytes 1042
> # got the data back before the state change
> Got ACK
> dropping char $, vm_stop(RUN_STATE_PAUSED)
On 16 February 2012 18:39, Meador Inge wrote:
> On 02/15/2012 02:14 PM, Peter Maydell wrote:
>> I think the right way to deal with both the problem you were seeing
>> and this related issue is simply not to try to send the syscall
>> request until we have really stopped the CPU. That is, when not
I wrote:
> This patch works (in that it fixes this problem with a test case I have
> coincidentally received from another reporter this week), although I
> notice that doing read/write syscalls via gdb is dreadfully slow
> because there seems to be ~1second delay between gdb sending its response
>
On 15 February 2012 16:55, Meador Inge wrote:
> 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.
Wouldn't it be more logical
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 an
