Problem with continue/halt

Freddie Chopin
Sat Jun 21 06:52:00 GMT 2014


First of all - GDB is built for Windows using mingw32-w64 toolchain, the 
problem happens for both 32- and 64-bit version.

I've just compiled GDB from yesterday - 
db988f621f38b0123334c7e481deb113b9b5b9bf, 20.06.2014 00:00:42. When I 
use that with OpenOCD (remote GDB server), I can do most of the things 
like single stepping, viewing memory, adding breakpoints (which work 
fine as long as the target is stopped), but the moment I do a "continue" 
when there is no breakpoint to halt on, I can no longer halt the chip...

Here is the session log:

> > arm-none-eabi-gdb file.elf
> GNU gdb (GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain-140620)
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <>.
> Find the GDB manual and other documentation resources online at:
> <>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from file.elf...done.
> (gdb) target remote localhost:3333
> Remote debugging using localhost:3333
> 0x08001184 in DpAppl_ProfibusInit () at DpAppl.c:368
> 368     }//void DpAppl_ProfibusInit( void )
> (gdb) monitor reset init
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0xc1000000 pc: 0x08000120 msp: 0x20001308
> (gdb) c
> Continuing.

At this point I pressed "Ctrl+C" like few minutes ago and absolutely 
nothing happens. This very simple scenario works fine with a GDB which I 
compiled ~3 months ago (2cafe348f61bae1037dac338ba434ebf86c0d670, 
04.04.2014 23:00:58) - "Ctrl+C" halts the target instantly. I've also 
tried the same with GDB from today's morning and the problem remains.

The only way to gain control over GDB is to shutdown GDB server 
(OpenOCD), which results in a following error:

> Exception condition detected on fd 384
> Remote communication error.  Target disconnected.: No error.
> (gdb)

Do note that GDB is not frozen - when I do something via OpenOCD the 
output is seen correctly in the GDB's console - it just somehow cannot 
receive the interrupt that halts the target...

If I do the debugging with Eclipse the problem is obviously the same.

Any ideas what's the problem - is there a problem in GDB or am I doing 
something wrong? I can try to bisect the problem a bit, but I'm not sure 
how long that would take me - I build GDB on Linux, but I have to use it 
on Windows.

Thanks for help!


More information about the Gdb mailing list