Problem with continue/halt

Problem with continue/halt

[Freddie Chopin]

Hello!

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)
>  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 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!

Regards,
FCh

Re: Problem with continue/halt

[Freddie Chopin]

Hello again!

The problem is still there with the most recent git snapshot. I tried 
compiling some older versions (like 7.7 or 7.7.1 or the one which worked 
some time ago), but the build fails in each case - I guess this must be 
somehow related to using mingw-w64 4.9.0 and the -Werror flag.

I'll try to find the first "new" version that compiles fine for me and 
hope it will not have the bug...

Regards,
FCh

Re: Problem with continue/halt

[Eli Zaretskii]

> Date: Thu, 26 Jun 2014 10:44:23 +0200
> From: Freddie Chopin <freddie_chopin@op.pl>
> 
> The problem is still there with the most recent git snapshot. I tried 
> compiling some older versions (like 7.7 or 7.7.1 or the one which worked 
> some time ago), but the build fails in each case - I guess this must be 
> somehow related to using mingw-w64 4.9.0 and the -Werror flag.

Are you per chance compiling with LTO?  If so, don't.

Re: Problem with continue/halt

[Freddie Chopin]

W dniu 2014-06-26 17:24, Eli Zaretskii pisze:
> Are you per chance compiling with LTO?  If so, don't.

I'm using the same command as the one which worked fine previously:

> $SRCDIR/$BINUTILS_GDB/configure --build=$BUILD \
>     --host=$HOST_MINGW \
>     --target=$TARGET \
>     --prefix=$INSTALLDIR_MINGW \
>     --infodir=$INSTALLDIR_MINGW_DOC/info \
>     --mandir=$INSTALLDIR_MINGW_DOC/man \
>     --htmldir=$INSTALLDIR_MINGW_DOC/html \
>     --pdfdir=$INSTALLDIR_MINGW_DOC/pdf \
>     --disable-nls \
>     --enable-plugins \
>     --with-sysroot=$INSTALLDIR_MINGW/arm-none-eabi \
>     --disable-sim \
>     --with-python=no \
>     --with-lzma=no \
>     --with-libexpat=$BUILDDIR_MINGW/host-libs/usr \
>     --with-libiconv-prefix=$BUILDDIR_MINGW/host-libs/usr \
>     --with-system-gdbinit=$INSTALLDIR_MINGW/$HOST_MINGW/arm-none-eabi/lib/gdbinit \
>     '--with-gdb-datadir='\''${prefix}'\''/arm-none-eabi/share/gdb' \
>     "--with-pkgversion=$PKGVERSION"
>
>     make -j$JOBS

So I'm not enabling LTO explicitly, maybe that's enabled by default somehow?

BTW - do you mean LTO is the cause for the continue/halt problem or the 
issue of building older versions?

Regards,
FCh

Re: Problem with continue/halt

[Eli Zaretskii]

> Date: Thu, 26 Jun 2014 17:38:56 +0200
> From: Freddie Chopin <freddie_chopin@op.pl>
> 
> W dniu 2014-06-26 17:24, Eli Zaretskii pisze:
> > Are you per chance compiling with LTO?  If so, don't.
> 
> I'm using the same command as the one which worked fine previously:
> 
> > $SRCDIR/$BINUTILS_GDB/configure --build=$BUILD \
> >     --host=$HOST_MINGW \
> >     --target=$TARGET \
> >     --prefix=$INSTALLDIR_MINGW \
> >     --infodir=$INSTALLDIR_MINGW_DOC/info \
> >     --mandir=$INSTALLDIR_MINGW_DOC/man \
> >     --htmldir=$INSTALLDIR_MINGW_DOC/html \
> >     --pdfdir=$INSTALLDIR_MINGW_DOC/pdf \
> >     --disable-nls \
> >     --enable-plugins \
> >     --with-sysroot=$INSTALLDIR_MINGW/arm-none-eabi \
> >     --disable-sim \
> >     --with-python=no \
> >     --with-lzma=no \
> >     --with-libexpat=$BUILDDIR_MINGW/host-libs/usr \
> >     --with-libiconv-prefix=$BUILDDIR_MINGW/host-libs/usr \
> >     --with-system-gdbinit=$INSTALLDIR_MINGW/$HOST_MINGW/arm-none-eabi/lib/gdbinit \
> >     '--with-gdb-datadir='\''${prefix}'\''/arm-none-eabi/share/gdb' \
> >     "--with-pkgversion=$PKGVERSION"
> >
> >     make -j$JOBS
> 
> So I'm not enabling LTO explicitly, maybe that's enabled by default somehow?

If you add -v to the GCC command line, it will show you what it is
doing.

> BTW - do you mean LTO is the cause for the continue/halt problem or the 
> issue of building older versions?

The former, I think.

Re: Problem with continue/halt

[Freddie Chopin]

OK, I'm getting closer... Wit this commit it still works fine:

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

With this one (3 days later) doing "continue" causes the freeze:

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

Browsing through the commits I suspect this one ("enable target async by 
default; separate MI and target notions of async") to be the cause of 
the problem I'm seeing:

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

I tried playing with the new options "set mi-async" and "set 
target-async" (both are set to off in here), but this makes no 
difference for me.

I'll verify that this is the commit that causes trouble and report back.

Regards,
FCh

Re: Problem with continue/halt - async support

[Freddie Chopin]

W dniu 2014-06-27 09:23, Freddie Chopin pisze:
> OK, I'm getting closer... Wit this commit it still works fine:
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=41aa47b48f0794fdfccc0f2c283433d8e35c5a2c
>
>
> With this one (3 days later) doing "continue" causes the freeze:
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=11b28b91b2c51898e1347e62909811cc7dd720ea
>
>
> Browsing through the commits I suspect this one ("enable target async by
> default; separate MI and target notions of async") to be the cause of
> the problem I'm seeing:
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=329ea57934a9d4b250a0b417af1ec47bc2d0ceb6
>
>
> I tried playing with the new options "set mi-async" and "set
> target-async" (both are set to off in here), but this makes no
> difference for me.
>
> I'll verify that this is the commit that causes trouble and report back.

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, then this probably is Windows specific, or 
even mingw-w64 specific, or maybe remote-target-OpenOCD specific. As I 
wrote previously - GDB is compiled with the most recent package from 
Arch Linux, so that's GCC 4.9.0 mingw-w64. The problem is the same for 
32-bit and 64-bit compilation.

Any ideas what can I test to help with the bug? I'm going to post a bug 
report too...

I added Pedro Alves to CC of this e-mail.

Regards,
FCh

Re: Problem with continue/halt - async support

[Eli Zaretskii]

> Date: Fri, 27 Jun 2014 10:26:48 +0200
> From: Freddie Chopin <freddie_chopin@op.pl>
> CC: palves@redhat.com
> 
> 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, then this probably is Windows specific, or 
> even mingw-w64 specific, or maybe remote-target-OpenOCD specific. As I 
> wrote previously - GDB is compiled with the most recent package from 
> Arch Linux, so that's GCC 4.9.0 mingw-w64. The problem is the same for 
> 32-bit and 64-bit compilation.
> 
> Any ideas what can I test to help with the bug? I'm going to post a bug 
> report too...

Thanks for digging into this.

I suggest to start by posting a full self-contained recipe for
reproducing the problem.  It would be nice if the problem were
reproducible in native debugging, but if that's impossible, then a
target-specific recipe is also OK.