This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
New mingw32 support problems
- From: "Pierre Muller" <muller at ics dot u-strasbg dot fr>
- To: <gdb at sourceware dot org>, "'Pedro Alves'" <pedro_alves at portugalmail dot pt>, "'Joel Brobecker'" <brobecker at adacore dot com>
- Date: Thu, 18 Oct 2007 09:34:50 +0200
- Subject: New mingw32 support problems
I tried the new patch from Pedro for mingw
under rxvt msys 1.0.10.
$ msysinfo
msysinfo-1.3: Send this to the MSYS support list:
MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32
GNU bash, version 3.1.0(3)-release (i686-pc-msys); ENV=.profile
GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix
gcc.exe (GCC) 3.4.2 (mingw-special); targ=MINGW32
GNU ld version 2.16.91 20060119
789320 Tue Mar 16 12:32:49 2004 /bin/msys-1.0.dll
1064960 Thu Apr 05 11:48:16 2007 /mingw/bin/make.exe
88064 Tue Sep 21 11:15:22 2004 /mingw/bin/gcc.exe
685568 Fri Jan 20 07:41:43 2006 /mingw/bin/ld.exe
HOME=/home/Pierre
Sysname=MINGW32_NT-5.1 OSTYPE=msys TERM=msys
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/program files/imagemagi
ck-6.3.4-q16:/c/Program Files/MiKTeX 2.5/miktex/bin:/c/WINDOWS/s
ystem32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:.:/c/Program Files/O
penVPN/bin:/c/pas/fpc-2.2.0/bin/i386-Win32
$ ls -tx /c/cygwin/usr/local/src/cvs/build-mingw/gdb
First problem:
when I configure without arguments at src level
and start 'make all-gdb', I get into troubles...
I finally understood that the problem was that
the src level also enables gdbtk, which is disabled
by default under cygwin.
Of course, mingw32 is no able to compile gdbtk.
I finally was able to create a gdb.exe using
../src/configure --disable-nls --disable-tui --disable-deps --disable-gdbtk;
make all-gdb
I am not sure all these options are needed.
Second problem:
Using gdb.exe on itself.
Using
"./gdb ./gdb"
in build-mingw/gdb directory
leads to a problem if I try to use
gdb recursively.
I need three levels to get the problem
(I tested the same with a cygwin gdb
and it works OK for cygwin).
$ ./gdb ./gdb
GNU gdb 6.7.50-20071017-cvs
Copyright (C) 2007 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 "i686-pc-mingw32"...
Setting up the environment for debugging gdb.
During symbol reading, struct/union type gets multiply defined: struct type.
Breakpoint 1 at 0x40bc07: file ../../src/gdb/utils.c, line 817.
Breakpoint 2 at 0x41932f: file ../../src/gdb/cli/cli-cmds.c, line 199.
(top-gdb) set prompt level1>
level1> r ./gdb
Starting program: c:\cygwin\usr\local\src\cvs\build-mingw\gdb/./gdb.exe
./gdb
GNU gdb 6.7.50-20071017-cvs
Copyright (C) 2007 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 "i686-pc-mingw32"...
Setting up the environment for debugging gdb.
During symbol reading, struct/union type gets multiply defined: struct type.
Breakpoint 1 at 0x40bc07: file ../../src/gdb/utils.c, line 817.
Breakpoint 2 at 0x41932f: file ../../src/gdb/cli/cli-cmds.c, line 199.
(top-gdb) set prompt level2>
level2> r ./gdb
Starting program: c:\cygwin\usr\local\src\cvs\build-mingw\gdb/./gdb.exe
./gdb
GNU gdb 6.7.50-20071017-cvs
Copyright (C) 2007 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 "i686-pc-mingw32"...
Setting up the environment for debugging gdb.
During symbol reading, struct/union type gets multiply defined: struct type.
Breakpoint 1 at 0x40bc07: file ../../src/gdb/utils.c, line 817.
Breakpoint 2 at 0x41932f: file ../../src/gdb/cli/cli-cmds.c, line 199.
(top-gdb) q
gdb: unknown target exception 0xc0000008 at 0x7c90eb74
Program received signal ?, Unknown signal.
0x7c90eb74 in ?? ()
level1> warning: Can not parse XML library list; XML support was disabled at
compile time
level1> bt
#0 0x7c90eb74 in ?? ()
#1 0xc0000008 in ?? ()
#2 0x00000000 in ?? ()
level1> x /8x $ebp
0x22f870: 0x0022f884 0x7c90eb94 0x7c90d592 0x7c809b8b
0x22f880: 0x00000748 0x0022f898 0x7c85a389 0x00000748
level1>
Using cygwin gdb as level 1 I get
better information for the backtrace:
gdb: unknown target exception 0xc0000008 at 0x7c90eb74
Program received signal ?, Unknown signal.
0x7c90eb74 in ntdll!LdrAlternateResourcesEnabled ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
cyggdb> bt
#0 0x7c90eb74 in ntdll!LdrAlternateResourcesEnabled ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c90eb94 in ntdll!LdrAccessOutOfProcessResource ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c90d592 in ntdll!ZwClose () from
/cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c809b8b in KERNEL32!CloseHandle ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll
#4 0x0000074c in ?? ()
#5 0x0022f898 in ?? ()
#6 0x7c85a389 in KERNEL32!GetThreadSelectorEntry ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll
#7 0x0000074c in ?? ()
#8 0x00001168 in ?? ()
#9 0x0000115c in ?? ()
#10 0x0022f8b8 in ?? ()
#11 0x7c85a59b in KERNEL32!ContinueDebugEvent ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll
#12 0x00001168 in ?? ()
#13 0x0000115c in ?? ()
#14 0x0022f93c in ?? ()
#15 0x7c97e4c0 in ntdll!NtAccessCheckByTypeResultListAndAuditAlarm ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#16 0x0000115c in ?? ()
#17 0x00001168 in ?? ()
#18 0x0022f8e8 in ?? ()
#19 0x004680bf in win32_continue (continue_status=1868, id=4456)
at ../../src/gdb/win32-nat.c:1125
Previous frame inner to this frame (corrupt stack?)
cyggdb> x /8x $ebp
0x22f870: 0x0022f884 0x7c90eb94 0x7c90d592 0x7c809b8b
0x22f880: 0x0000074c 0x0022f898 0x7c85a389 0x0000074c
cyggdb> f 3
#3 0x7c809b8b in KERNEL32!CloseHandle ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll
cyggdb> x /4x $ebp
0x22f884: 0x0022f898 0x7c85a389 0x0000074c 0x00001168
Which means that the handle 0x74C is invalid,
and indeed, if I look at the handles
with ProcessExplorer v10.21
I find no open handle 0x74C
Could someone please test this
and report if this is specific to my setup
or a generic problem with mingw32 support?
PS: this recursive problem seems not to be specific
to Pedro's patch:
I checked mingw32 gdb-6.3, it works OK
but mingw32 gdb-6.6 shows the same bug.
So it seems that the problem is
not new.
Pierre Muller