New mingw32 support problems

New mingw32 support problems

[Pierre Muller]

  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

Re: New mingw32 support problems

[Eli Zaretskii]

> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Date: Thu, 18 Oct 2007 09:34:50 +0200
> 
> 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.

No clue about this one.

> gdb: unknown target exception 0xc0000008 at 0x7c90eb74
> 
> Program received signal ?, Unknown signal.

I think this is because GDB does not support Windows exception codes,
see the various STATUS_* constants in winbase.h.  0xc0000008 is
invalid handle.

> Using cygwin gdb as level 1 I get
> better information for the backtrace:
> gdb: unknown target exception 0xc0000008 at 0x7c90eb74

So it looks like Cygwin also doesn't support these exceptions?

Re: New mingw32 support problems

[Pedro Alves]

Pierre Muller wrote:
>   I tried the new patch from Pedro for mingw
> under rxvt msys 1.0.10.
> 

Thanks!

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

I don't use msys.  I build from a cygwin environment, with a
few shell scripts wrapping mingw32-gcc/mingw32-g++ that
simply call cygpath on absolute paths (-I, -L, sources,
outputs, etc).

I built with:
   $ ../src/configure --build=mingw32 --host=mingw32 --target=mingw32

TUI is disabled automatically, since there's no curses, and I don't
have the gdbtk here.

> level1> warning: Can not parse XML library list; XML support was disabled at
> compile time
> 

> 
> Using cygwin gdb as level 1 I get
> better information for the backtrace:

You have DLL support disabled.  If you rebuild the mingw gdb
with libexpat available, you'll get as good
backtrace information.

>   Could someone please test this
> and report if this is specific to my setup
> or a generic problem with mingw32 support?
> 

I see it here too.  More comments in the next email.

Cheers,
Pedro Alves

Re: New mingw32 support problems

[Pedro Alves]

Eli Zaretskii wrote:
>> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
>> Date: Thu, 18 Oct 2007 09:34:50 +0200
>>
>> 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.
> 
> No clue about this one.
> 
>> gdb: unknown target exception 0xc0000008 at 0x7c90eb74
>>
>> Program received signal ?, Unknown signal.
> 
> I think this is because GDB does not support Windows exception codes,
> see the various STATUS_* constants in winbase.h.  0xc0000008 is
> invalid handle.
> 

A few comments:  I won't have much time to help debug this in the
comming days.

That's correct.  When an invalid handle is passed to the win32 api
function `CloseHandle', and iff a debugger is attached, an 
EXCEPTION_INVALID_HANDLE first chance exception will be thrown.  This
is a debugging api feature.  It would be somewhat like the unix
equivalent of giving gdb the ability to trap syscalls with
invalid args.

Pierre's launched:

gdb1
  +-----gdb2
         +-----gdb3

In this case, gdb2 is issuing an invalid CloseHandle, and gdb1 is
seeing it in the form of an EXCEPTION_INVALID_HANDLE.
I could reproduce it here, and I noticed it is even easier to
reproduce (no need to quit) it if we use "set new-console 1" in
all the gdbs.  I bet that gdb3 could be replaced with something
else, and the "problem" would still trigger.

This exception, being a debugger api facility, shouldn't
be passed to the inferior, which naturally doesn't handle it,
thus resulting in the second chance exception, this time
caught by gdb as:

gdb: unknown target exception 0xc0000008 at 0x7c90eb74
"Program received signal ?, Unknown signal."

But, this time, it is too late to ignore the exception, the
inferior is going to have to die.
That would be the equivalent of having a 'close(-1);' kill
the inferior instead of just setting errno.

I don't know why this triggers on a MinGW gdb and not on
a Cygwin gdb.  From the trace, it seems that is it something
inside Windows that is borking it.  The normal case is to
have the exception thrown from inside
0x7C90EB74

Maybe we are indeed
corrupting something that manifests like this, or maybe we
aren't.  I hacked win32-nat.c to ignore it and nothing
bad happened.  gdb1, gdb2 and gdb3 continued working
as expected.

Adding proper support for stopping and resuming/passing/ignoring
win32 first chance exceptions support into gdb would be a nice
project.
A quick alternative would be to eat a first chance
EXCEPTION_INVALID_HANDLE that comes from inside ntdll.dll.
Since we won't be doing anything useful with it,
we might as well silence it ...  dunno.

>> gdb: unknown target exception 0xc0000008 at 0x7c90eb74
> 
> So it looks like Cygwin also doesn't support these exceptions?
> 

It doesn't.

Cheers,
Pedro Alves

RE: New mingw32 support problems

[Pierre Muller]

 I think that I found the reason of the behavior difference
between cygwin and mingw32 compiled GDBs.

  Cygwin installs an exception handler in cygwin1.dll
that has the following code:
winsup/cygwin/exceptions.cc around line 550 in current cvs src tree:

    case STATUS_INVALID_HANDLE:
      /* CloseHandle will throw this exception if it is given an
         invalid handle.  We don't care about the exception; we just
         want CloseHandle to return an error.  This can be revisited
         if gcc ever supports Windows style structured exception
         handling.  */
      return 0;

while mingw32 installs apparently no exception handler
at all.

   The problem seems to be coming from the fact that 
GDB is closing some handles that it should not close
according to the win32 API.
   This is especially the case for the thread handles,
that are normally closed by the system after
the EXIT_THREAD_DEBUG_EVENT and EXIT_PROCESS_DEBUG_EVENT
events.

This comes from Microsoft docs online:
http://msdn2.microsoft.com/en-us/library/ms679285.aspx

After the ContinueDebugEvent function succeeds, the specified thread
continues. Depending on the debugging event previously reported by the
thread, different actions occur. If the continued thread previously reported
an EXIT_THREAD_DEBUG_EVENT debugging event, ContinueDebugEvent closes the
handle the debugger has to the thread. If the continued thread previously
reported an EXIT_PROCESS_DEBUG_EVENT debugging event, ContinueDebugEvent
closes the handles the debugger has to the process and to the thread.

  But I vaguely remember that those calls where added for some good
reasons to the win32-nat.c source. Maybe the closing by the system
is version dependent...

  I am currently trying to understand how to 
tell the system not to pass those STATUS_INVALID_HANDLE down
to the debuggee, and the code seems to work more or less now.

 I will post a RFC in a separate email

Pierre  

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Pedro Alves
> Sent: Friday, October 19, 2007 2:59 AM
> To: Eli Zaretskii
> Cc: Pierre Muller; gdb@sourceware.org; brobecker@adacore.com
> Subject: Re: New mingw32 support problems
> 
> Eli Zaretskii wrote:
> >> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> >> Date: Thu, 18 Oct 2007 09:34:50 +0200
> >>
> >> 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.
> >
> > No clue about this one.
> >
> >> gdb: unknown target exception 0xc0000008 at 0x7c90eb74
> >>
> >> Program received signal ?, Unknown signal.
> >
> > I think this is because GDB does not support Windows exception codes,
> > see the various STATUS_* constants in winbase.h.  0xc0000008 is
> > invalid handle.
> >
> 
> A few comments:  I won't have much time to help debug this in the
> comming days.
> 
> That's correct.  When an invalid handle is passed to the win32 api
> function `CloseHandle', and iff a debugger is attached, an
> EXCEPTION_INVALID_HANDLE first chance exception will be thrown.  This
> is a debugging api feature.  It would be somewhat like the unix
> equivalent of giving gdb the ability to trap syscalls with
> invalid args.
> 
> Pierre's launched:
> 
> gdb1
>   +-----gdb2
>          +-----gdb3
> 
> In this case, gdb2 is issuing an invalid CloseHandle, and gdb1 is
> seeing it in the form of an EXCEPTION_INVALID_HANDLE.
> I could reproduce it here, and I noticed it is even easier to
> reproduce (no need to quit) it if we use "set new-console 1" in
> all the gdbs.  I bet that gdb3 could be replaced with something
> else, and the "problem" would still trigger.
> 
> This exception, being a debugger api facility, shouldn't
> be passed to the inferior, which naturally doesn't handle it,
> thus resulting in the second chance exception, this time
> caught by gdb as:
> 
> gdb: unknown target exception 0xc0000008 at 0x7c90eb74
> "Program received signal ?, Unknown signal."
> 
> But, this time, it is too late to ignore the exception, the
> inferior is going to have to die.
> That would be the equivalent of having a 'close(-1);' kill
> the inferior instead of just setting errno.
> 
> I don't know why this triggers on a MinGW gdb and not on
> a Cygwin gdb.  From the trace, it seems that is it something
> inside Windows that is borking it.  The normal case is to
> have the exception thrown from inside
> 0x7C90EB74
> 
> Maybe we are indeed
> corrupting something that manifests like this, or maybe we
> aren't.  I hacked win32-nat.c to ignore it and nothing
> bad happened.  gdb1, gdb2 and gdb3 continued working
> as expected.
> 
> Adding proper support for stopping and resuming/passing/ignoring
> win32 first chance exceptions support into gdb would be a nice
> project.
> A quick alternative would be to eat a first chance
> EXCEPTION_INVALID_HANDLE that comes from inside ntdll.dll.
> Since we won't be doing anything useful with it,
> we might as well silence it ...  dunno.
> 
> >> gdb: unknown target exception 0xc0000008 at 0x7c90eb74
> >
> > So it looks like Cygwin also doesn't support these exceptions?
> >
> 
> It doesn't.
> 
> Cheers,
> Pedro Alves

Re: New mingw32 support problems

[Pedro Alves]

Pierre Muller wrote:
>  I think that I found the reason of the behavior difference
> between cygwin and mingw32 compiled GDBs.
>
>   Cygwin installs an exception handler in cygwin1.dll
> that has the following code:
> winsup/cygwin/exceptions.cc around line 550 in current cvs src tree:
>
>     case STATUS_INVALID_HANDLE:
>       /* CloseHandle will throw this exception if it is given an
>          invalid handle.  We don't care about the exception; we just
>          want CloseHandle to return an error.  This can be revisited
>          if gcc ever supports Windows style structured exception
>          handling.  */
>       return 0;
>
> while mingw32 installs apparently no exception handler
> at all.
>
>    The problem seems to be coming from the fact that
> GDB is closing some handles that it should not close
> according to the win32 API.
>    This is especially the case for the thread handles,
> that are normally closed by the system after
> the EXIT_THREAD_DEBUG_EVENT and EXIT_PROCESS_DEBUG_EVENT
> events.
>
> This comes from Microsoft docs online:
> http://msdn2.microsoft.com/en-us/library/ms679285.aspx
>
> After the ContinueDebugEvent function succeeds, the specified thread
> continues. Depending on the debugging event previously reported by the
> thread, different actions occur. If the continued thread previously reported
> an EXIT_THREAD_DEBUG_EVENT debugging event, ContinueDebugEvent closes the
> handle the debugger has to the thread. If the continued thread previously
> reported an EXIT_PROCESS_DEBUG_EVENT debugging event, ContinueDebugEvent
> closes the handles the debugger has to the process and to the thread.
>

This explanation fits so right to the symptons, that I can't see
how it can't be it.  :)

I've seen something of the sort in Windows CE.  There's currently this beauty
in gdbserver/win32-low.c:

#ifndef _WIN32_WCE
  /* On Windows CE this handle can't be closed.  The OS reuses
     it in the debug events, while the 9x/NT versions of Windows
     probably use a DuplicateHandle'd one.  */
  CloseHandle (pi.hThread);
#endif

Seems like it was another manifestation of the same API usage violation?

>   But I vaguely remember that those calls where added for some good
> reasons to the win32-nat.c source. Maybe the closing by the system
> is version dependent...
>

I remember reading something about having handles to the executable open
would prevent updating it in place?  Could it be that just fixing the
thread CloseHandles fixes the issue?

Cheers,
Pedro Alves