[Bug gdb/17096] New: async support breaks remote debugging on Windows

["freddie_chopin at op dot pl" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17096

            Bug ID: 17096
           Summary: async support breaks remote debugging on Windows
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: freddie_chopin at op dot pl

GDB is cross-compiled for Windows using mingw32-w64 toolchain (most recent
package from Arch Linux, so that's GCC 4.9.0), the problem happens for both 32-
and 64-bit version.

When I use GDB 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)
>  7.8.50.20140620-cvs
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> 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:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> 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 snapshot right before
"async target support" - "Ctrl+C" halts the target instantly.

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...

This commit (before whole "async support" series) works fine:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=434415618f6bb9ac428a8d18ab33111920cd04dc

This commit (after whole "async support" series) has the problem:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=a09dd4413d1a4ea063173d4822635f41c885f6fe

For completeness - current HEAD still has the problem.

If anyone didn't notice that already, then this probably is Windows specific,
or even mingw-w64 specific, or maybe remote-target-OpenOCD specific.

-- 
You are receiving this mail because:
You are on the CC list for the bug.