bug#50453: 27.2; Portable dumper broken on MSW

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Having recently had an opportunity to update the Emacs installed on some
machines previously running 24.5, I noticed that Emacs 27.2 doesn't seem
to load portable dumps, and instead fails with an out-of-memory error,
the precise error message being:

emacs: could not load dump file
"C:\PROGRAM FILES\EMACS\I686\libexec/emacs/27.2/i686-w64-mingw32/emacs.pdmp": out of memory.

Emacs operates normally if the portable dump file is removed, or when
using unexec dumping.

Admittedly, the machine is a Pentium 4 with 768 megabytes of memory (and
what would you expect from a PC used to operate legacy software), but I
see no reason loading pdumps should require more than that, as the
previous dumper worked just fine.

In GNU Emacs 27.2 (build 1, i686-w64-mingw32)
 of 2021-09-07 built on bubbles
Windowing system distributor 'Microsoft Corp.', version 4.10.2222
System Description: Microsoft Windows 98 (v4.10.2222)

Recent messages:

Configured using:
 'configure --without-dbus --host=i686-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: enu
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
warnings tooltip cus-start eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 8 163155 11505)
 (symbols 24 20691 1)
 (strings 16 56914 2810)
 (string-bytes 1 2369595)
 (vectors 8 30187)
 (vector-slots 4 1194144 19878)
 (floats 8 199 93)
 (intervals 28 286 32)
 (buffers 576 13))

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> Date: Tue, 07 Sep 2021 20:46:31 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Having recently had an opportunity to update the Emacs installed on some
> machines previously running 24.5, I noticed that Emacs 27.2 doesn't seem
> to load portable dumps, and instead fails with an out-of-memory error,
> the precise error message being:
> 
> emacs: could not load dump file
> "C:\PROGRAM FILES\EMACS\I686\libexec/emacs/27.2/i686-w64-mingw32/emacs.pdmp": out of memory.
> 
> Emacs operates normally if the portable dump file is removed, or when
> using unexec dumping.

How do you mean "operates normally if the portable dump file is
removed"?  Without a pdmp file, Emacs should load all the preloaded
Lisp files when it starts up, which is definitely not something I'd
call "normal".  Don't you see a long series of "Loading foo..."
messages when Emacs starts without a pdmp file?

> Admittedly, the machine is a Pentium 4 with 768 megabytes of memory (and
> what would you expect from a PC used to operate legacy software), but I
> see no reason loading pdumps should require more than that, as the
> previous dumper worked just fine.

First, the important figure is how much of the 768MB is free when
Emacs loads.

And second, you are using Emacs on Windows 9X, something that a few
people do, so perhaps we have some bug related to that version of
Windows.  If you can run Emacs under GDB, please step through
pdumper_load and tell where it bails out.  "Out of memory" is its
default error, so maybe the actual problem is something else, and we
just mis-diagnose it.  One possible issue could be with the way we
read the pdumper file as a memory-mapped file: perhaps something there
doesn't work on Windows 9X.

Thanks.

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> How do you mean "operates normally if the portable dump file is
> removed"?  Without a pdmp file, Emacs should load all the preloaded
> Lisp files when it starts up, which is definitely not something I'd
> call "normal".  Don't you see a long series of "Loading foo..."
> messages when Emacs starts without a pdmp file?

I meant to say that while Emacs does load loadup.el from source, it more
or less works normally after the load completes.

> First, the important figure is how much of the 768MB is free when
> Emacs loads.

That shouldn't be a problem; none of the indicators in the resource
meter report more than 45% utilization when the crash occurs.

> And second, you are using Emacs on Windows 9X, something that a few
> people do, so perhaps we have some bug related to that version of
> Windows.  If you can run Emacs under GDB, please step through
> pdumper_load and tell where it bails out.

That is proving to be a problem.  MinGW flat out refuses to start, while
the GDB from ezwinports complains about "KERNEL32.DLL" missing the
symbol "AttachConsole".  Do you know how I can obtain a copy of GDB that
will still work on this old system?  Thanks in advance!

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 50453@debbugs.gnu.org
> Date: Wed, 08 Sep 2021 20:37:34 +0800
> 
> > And second, you are using Emacs on Windows 9X, something that a few
> > people do, so perhaps we have some bug related to that version of
> > Windows.  If you can run Emacs under GDB, please step through
> > pdumper_load and tell where it bails out.
> 
> That is proving to be a problem.  MinGW flat out refuses to start, while
> the GDB from ezwinports complains about "KERNEL32.DLL" missing the
> symbol "AttachConsole".

Yes, latest GDB releases no longer support old Windows versions, even
XP is in danger (although it still works for me).  And MinGW64 dropped
XP support several years ago.

> Do you know how I can obtain a copy of GDB that
> will still work on this old system?  Thanks in advance!

Try the old mingw.org ports from here:

  https://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/

Thanks.

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Try the old mingw.org ports from here:
>
>   https://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/

Thanks.  GDB 7.0 is the newest version that will run, but it complains
that the executable is built with DWARF-4 debug information, while it
only supports DWARF-2.  I verified that CFLAGS does contain -gdwarf-2,
which I believe configure defaults to on MinGW.

Do you know what might be wrong here? TIA.

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Nevermind, I was able to get the debugger to work, though not very
reliably.

It appears to fail at line 5428 of pdumper.c, where dump_mmap_contiguous
returns false.  Unfortunately, the GDB session is extremely unreliable;
I was only able to get this information after Windows crashed a dozen or
so times.

Thanks.

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 50453@debbugs.gnu.org
> Date: Thu, 09 Sep 2021 19:34:49 +0800
> 
> Nevermind, I was able to get the debugger to work, though not very
> reliably.
> 
> It appears to fail at line 5428 of pdumper.c, where dump_mmap_contiguous
> returns false.  Unfortunately, the GDB session is extremely unreliable;
> I was only able to get this information after Windows crashed a dozen or
> so times.

That's what I guessed might be the problem.

Can you put a breakpoint in dump_map_file_w32 and verify that it is
called?  If it is indeed called, can you step through it and see if it
fails, and if so, how?

Thanks.

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you put a breakpoint in dump_map_file_w32 and verify that it is
> called?  If it is indeed called, can you step through it and see if it
> fails, and if so, how?

I tried a few times, but I gave up because Windows kept crashing.

However, the portable dumper seems to rely on a function named
`MapViewOfFileEx' at line 4499 of pdumper.c.

According to the documentation, the function is only available on
Windows XP or later; this seems to be a convincing explanation for the
failure.

Specifically, I'm referring to the "Requirements" section of:
https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-mapviewoffileex,
which states:

Minimum supported client: Windows XP [desktop apps only]

Thanks.

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

If VM_SUPPORTED is defined to 0, Emacs loads the pdmp file normally.
Perhaps Emacs could test for is_window_9x (), and if affirmative, fall
back to using dump_mmap_contiguous_heap?

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 50453@debbugs.gnu.org
> Date: Thu, 09 Sep 2021 20:55:02 +0800
> 
> If VM_SUPPORTED is defined to 0, Emacs loads the pdmp file normally.
> Perhaps Emacs could test for is_window_9x (), and if affirmative, fall
> back to using dump_mmap_contiguous_heap?

It's possible, but only as the last resort, because it will cause the
startup to be much slower.

How did you try that?  Did you rebuild Emacs?  If so, I would like you
to try a different change first, before we decide to give up on the
memory-mapped file approach.

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> It's possible, but only as the last resort, because it will cause the
> startup to be much slower.

> How did you try that?  Did you rebuild Emacs?  If so, I would like you
> to try a different change first, before we decide to give up on the
> memory-mapped file approach.

Yes, I rebuilt Emacs.  I would be glad to test another change, thanks!

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 50453@debbugs.gnu.org
> Date: Fri, 10 Sep 2021 08:48:47 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How did you try that?  Did you rebuild Emacs?  If so, I would like you
> > to try a different change first, before we decide to give up on the
> > memory-mapped file approach.
> 
> Yes, I rebuilt Emacs.  I would be glad to test another change, thanks!

Please try the patch below.

diff --git a/src/pdumper.c b/src/pdumper.c
index 7730ea3..2291fce 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -4537,15 +4537,28 @@ dump_map_file_w32 (void *base, int fd, off_t offset, size_t size,
   uint32_t offset_low = (uint32_t) (full_offset & 0xffffffff);
 
   int error;
+  DWORD protect;
   DWORD map_access;
 
   file = (HANDLE) _get_osfhandle (fd);
   if (file == INVALID_HANDLE_VALUE)
     goto out;
 
+  switch (protection)
+    {
+    case DUMP_MEMORY_ACCESS_READWRITE:
+      protect = PAGE_WRITECOPY;	/* for Windows 9X */
+      break;
+    default:
+    case DUMP_MEMORY_ACCESS_NONE:
+    case DUMP_MEMORY_ACCESS_READ:
+      protect = PAGE_READONLY;
+      break;
+    }
+
   section = CreateFileMapping (file,
 			       /*lpAttributes=*/NULL,
-			       PAGE_READONLY,
+			       protect,
 			       /*dwMaximumSizeHigh=*/0,
 			       /*dwMaximumSizeLow=*/0,
 			       /*lpName=*/NULL);

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Please try the patch below.

Thanks.  Emacs correctly loads the dump file with that patch in place.

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 50453@debbugs.gnu.org
> Date: Sat, 11 Sep 2021 10:57:12 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please try the patch below.
> 
> Thanks.  Emacs correctly loads the dump file with that patch in place.

Great, thanks for testing.

Daniel, any comments to that patch (copied below for your
convenience)?

And while at that, can you tell why we request
DUMP_MEMORY_ACCESS_READWRITE and not DUMP_MEMORY_ACCESS_READ when
loading from the pdumper file?  Do we expect the need to change values
loaded from the file?

Here's the patch I was talking about, it is needed for supporting
FILE_MAP_COPY flag in the MapViewOfFileEx call on Windows 9X:

diff --git a/src/pdumper.c b/src/pdumper.c
index 7730ea3..2291fce 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -4537,15 +4537,28 @@ dump_map_file_w32 (void *base, int fd, off_t offset, size_t size,
   uint32_t offset_low = (uint32_t) (full_offset & 0xffffffff);
 
   int error;
+  DWORD protect;
   DWORD map_access;
 
   file = (HANDLE) _get_osfhandle (fd);
   if (file == INVALID_HANDLE_VALUE)
     goto out;
 
+  switch (protection)
+    {
+    case DUMP_MEMORY_ACCESS_READWRITE:
+      protect = PAGE_WRITECOPY;	/* for Windows 9X */
+      break;
+    default:
+    case DUMP_MEMORY_ACCESS_NONE:
+    case DUMP_MEMORY_ACCESS_READ:
+      protect = PAGE_READONLY;
+      break;
+    }
+
   section = CreateFileMapping (file,
 			       /*lpAttributes=*/NULL,
-			       PAGE_READONLY,
+			       protect,
 			       /*dwMaximumSizeHigh=*/0,
 			       /*dwMaximumSizeLow=*/0,
 			       /*lpName=*/NULL);

bug#50453: 27.2; Portable dumper broken on MSW

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Thanks.  Emacs correctly loads the dump file with that patch in place.
>
> Great, thanks for testing.

If I understand correctly, the reported bug here was fixed, but this
question remains:

> And while at that, can you tell why we request
> DUMP_MEMORY_ACCESS_READWRITE and not DUMP_MEMORY_ACCESS_READ when
> loading from the pdumper file?  Do we expect the need to change values
> loaded from the file?

This is still the case on the trunk.  Daniel, do you have any comments
here?

bug#50453: 27.2; Portable dumper broken on MSW

[Gerd Möllmann]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> And while at that, can you tell why we request
>> DUMP_MEMORY_ACCESS_READWRITE and not DUMP_MEMORY_ACCESS_READ when
>> loading from the pdumper file?  Do we expect the need to change values
>> loaded from the file?
>
> This is still the case on the trunk.  Daniel, do you have any comments
> here?

I'm not Daniel, but what about relocations?  After mapping a .pdmp,
pointers have to be computed that fit the location in memory where the
.pdmp has been mapped.

bug#50453: 27.2; Portable dumper broken on MSW

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]



On August 25, 2022 07:47:12 Gerd Möllmann <gerd.moellmann@gmail.com> wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>>> And while at that, can you tell why we request
>>> DUMP_MEMORY_ACCESS_READWRITE and not DUMP_MEMORY_ACCESS_READ when
>>> loading from the pdumper file?  Do we expect the need to change values
>>> loaded from the file?
>>
>> This is still the case on the trunk.  Daniel, do you have any comments
>> here?
>
> I'm not Daniel, but what about relocations?  After mapping a .pdmp,
> pointers have to be computed that fit the location in memory where the
> .pdmp has been mapped.

Right. We want COW.


[-- Attachment #2: Type: text/html, Size: 1745 bytes --]

bug#50453: 27.2; Portable dumper broken on MSW

[Lars Ingebrigtsen]

Daniel Colascione <dancol@dancol.org> writes:

>  I'm not Daniel, but what about relocations?  After mapping a .pdmp,
>  pointers have to be computed that fit the location in memory where the
>  .pdmp has been mapped.
>
> Right. We want COW.

OK, then I guess there's nothing more to be done here, and I'm closing
this bug report.

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> If I understand correctly, the reported bug here was fixed

Well, unfortunately not on Emacs 28.

The unexec build works on Windows 9x, so it's not a very bad problem.

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Daniel Colascione <dancol@dancol.org>,
>   50453@debbugs.gnu.org
> Date: Fri, 26 Aug 2022 09:05:57 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > If I understand correctly, the reported bug here was fixed
> 
> Well, unfortunately not on Emacs 28.
> 
> The unexec build works on Windows 9x, so it's not a very bad problem.

Sorry, I don't understand: the change which uses the flags as needed
for Windows 9X is on the emacs-28 branch, and you said in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50453#50 that with that
change Emacs starts up on Windows 98.  So what are the problems that
remain to be fixed here?

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I don't understand: the change which uses the flags as needed
> for Windows 9X is on the emacs-28 branch, and you said in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50453#50 that with that
> change Emacs starts up on Windows 98.  So what are the problems that
> remain to be fixed here?

See bug#52295.  Killing text either doesn't work, or Emacs crashes.

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  dancol@dancol.org,  50453@debbugs.gnu.org
> Date: Fri, 26 Aug 2022 15:40:23 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sorry, I don't understand: the change which uses the flags as needed
> > for Windows 9X is on the emacs-28 branch, and you said in
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50453#50 that with that
> > change Emacs starts up on Windows 98.  So what are the problems that
> > remain to be fixed here?
> 
> See bug#52295.  Killing text either doesn't work, or Emacs crashes.

OK, but that's a separate problem with a separate bug number.  It
shouldn't prevent us from closing this one.

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 50453@debbugs.gnu.org
> Date: Thu, 09 Sep 2021 20:40:49 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you put a breakpoint in dump_map_file_w32 and verify that it is
> > called?  If it is indeed called, can you step through it and see if it
> > fails, and if so, how?
> 
> I tried a few times, but I gave up because Windows kept crashing.
> 
> However, the portable dumper seems to rely on a function named
> `MapViewOfFileEx' at line 4499 of pdumper.c.
> 
> According to the documentation, the function is only available on
> Windows XP or later; this seems to be a convincing explanation for the
> failure.

The current MS documentation is "inaccurate", to say the least: they
consistently removed from it any references to versions of Windows
before Windows 2000/XP.

I use this instead:

  http://winapi.freetechsecrets.com/win32/WIN32MapViewOfFileEx.htm

and it says this is available on Windows 9X, but there's a special
requirement regarding the flags, and I see that we don't fulfill that
requirement.

But I don't know how to proceed from here: you are probably unable to
build Emacs for Windows 98, and I don't know how else to ask you to
try some modifications of the current code.  Any ideas?

> Specifically, I'm referring to the "Requirements" section of:
> https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-mapviewoffileex,
> which states:
> 
> Minimum supported client: Windows XP [desktop apps only]

That's a lie.

bug#50453: 27.2; Portable dumper broken on MSW

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> The current MS documentation is "inaccurate", to say the least: they
> consistently removed from it any references to versions of Windows
> before Windows 2000/XP.
>
> I use this instead:
>
>   http://winapi.freetechsecrets.com/win32/WIN32MapViewOfFileEx.htm
>
> and it says this is available on Windows 9X, but there's a special
> requirement regarding the flags, and I see that we don't fulfill that
> requirement.

> But I don't know how to proceed from here: you are probably unable to
> build Emacs for Windows 98, and I don't know how else to ask you to
> try some modifications of the current code.  Any ideas?

I have successfully built Emacs for Windows 98, with functional
debugging information, using MinGW GCC 7.4, though GDB is still plagued
with Windows crashes.

I'd be happy to test any modification.  TIA.

bug#50453: 27.2; Portable dumper broken on MSW

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 50453@debbugs.gnu.org
> Date: Thu, 09 Sep 2021 16:07:09 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Try the old mingw.org ports from here:
> >
> >   https://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/
> 
> Thanks.  GDB 7.0 is the newest version that will run, but it complains
> that the executable is built with DWARF-4 debug information, while it
> only supports DWARF-2.  I verified that CFLAGS does contain -gdwarf-2,
> which I believe configure defaults to on MinGW.
> 
> Do you know what might be wrong here? TIA.

Yes, it's a messup of terminology: the format is DWARF-2, but its
version is 4, and I guess GDB 7.0 didn't support DWARF-2 version 4.