RFA: Support Windows extended error numbers in safe_strerror

classic Classic list List threaded Threaded
98 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

RFA: Support Windows extended error numbers in safe_strerror

Daniel Jacobowitz-2
This is an improved version of a patch Mark Mitchell submitted last
year.  If you give strerror() anything above 42 (sys_nerr) on Windows,
it gives you back "Unknown error" - particularly unfortunate since
WSAECONNREFUSED is way above there, so connecting to a closed socket
will give you a generic error message.  This patch lets us try an
OS-specific interface to fetch an error string.

[Actually you need my next patch too to get the connection refused message;
right now you'll get a timeout.]

Any comments on this patch?

--
Daniel Jacobowitz
CodeSourcery

2006-02-03  Daniel Jacobowitz  <[hidden email]>

        * utils.c (safe_strerror): Try to use FormatMessage for otherwise
        unknown messages on Windows.

Index: src/gdb/utils.c
===================================================================
--- src.orig/gdb/utils.c 2006-02-03 15:13:03.000000000 -0500
+++ src/gdb/utils.c 2006-02-03 15:16:24.000000000 -0500
@@ -1,8 +1,8 @@
 /* General utility routines for GDB, the GNU debugger.
 
    Copyright (C) 1986, 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995,
-   1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free
-   Software Foundation, Inc.
+   1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
+   Free Software Foundation, Inc.
 
    This file is part of GDB.
 
@@ -36,6 +36,10 @@
 #include <pc.h>
 #endif
 
+#ifdef USE_WIN32API
+#include <windows.h>
+#endif
+
 /* SunOS's curses.h has a '#define reg register' in it.  Thank you Sun. */
 #ifdef reg
 #undef reg
@@ -847,7 +851,34 @@ safe_strerror (int errnum)
 {
   char *msg;
 
-  msg = strerror (errnum);
+#ifdef USE_WIN32API
+  /* On Windows, strerror never returns NULL, but it returns a useless
+     string for anything above sys_nerr.  Try a little harder to find
+     a system-provided error message in that case.  */
+  if (errnum >= sys_nerr)
+    {
+      static char *buffer;
+
+      if (buffer)
+ LocalFree (buffer);
+
+      if (FormatMessage (FORMAT_MESSAGE_ALLOCATE_BUFFER
+ | FORMAT_MESSAGE_FROM_SYSTEM,
+ NULL, errnum,
+ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+ (LPTSTR) &buffer, 0, NULL) != 0)
+ {
+  if (strcmp (buffer + strlen (buffer) - 3, ".\r\n") == 0)
+    buffer[strlen (buffer) - 3] = '\0';
+  return buffer;
+ }
+      else
+ msg = NULL;
+    }
+  else
+#endif
+    msg = strerror (errnum);
+
   if (msg == NULL)
     {
       static char buf[32];
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Mark Kettenis
> Date: Fri, 3 Feb 2006 16:54:55 -0500
> From: Daniel Jacobowitz <[hidden email]>
>
> This is an improved version of a patch Mark Mitchell submitted last
> year.  If you give strerror() anything above 42 (sys_nerr) on Windows,
> it gives you back "Unknown error" - particularly unfortunate since
> WSAECONNREFUSED is way above there, so connecting to a closed socket
> will give you a generic error message.  This patch lets us try an
> OS-specific interface to fetch an error string.
>
> [Actually you need my next patch too to get the connection refused message;
> right now you'll get a timeout.]
>
> Any comments on this patch?

I think this is ugly.  When the win32 support was added, we were told
that only minimal changes were necessary.  But people keep pushing
#ifdef EVIL_CLOSED_SOURCE_PLATFORM_FROM_REDMOND patches.

GDB is written for POSIX systems.  It's clear that Windows isn't even
remotely POSIX compliant.

Mark
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Christopher Faylor-12
On Sat, Feb 04, 2006 at 12:25:19AM +0100, Mark Kettenis wrote:

>> Date: Fri, 3 Feb 2006 16:54:55 -0500
>> From: Daniel Jacobowitz <[hidden email]>
>>
>> This is an improved version of a patch Mark Mitchell submitted last
>> year.  If you give strerror() anything above 42 (sys_nerr) on Windows,
>> it gives you back "Unknown error" - particularly unfortunate since
>> WSAECONNREFUSED is way above there, so connecting to a closed socket
>> will give you a generic error message.  This patch lets us try an
>> OS-specific interface to fetch an error string.
>>
>> [Actually you need my next patch too to get the connection refused message;
>> right now you'll get a timeout.]
>>
>> Any comments on this patch?
>
>I think this is ugly.  When the win32 support was added, we were told
>that only minimal changes were necessary.  But people keep pushing
>#ifdef EVIL_CLOSED_SOURCE_PLATFORM_FROM_REDMOND patches.
>
>GDB is written for POSIX systems.  It's clear that Windows isn't even
>remotely POSIX compliant.

Hmm.  As it turns out, I have some email sitting in my "to be sent"
folder that I've held back on sending which is tangentially related
to this.

The gist of the email is that I'm not happy having to support
windows-specific workarounds in gdb while standing on my head in
cygwin-land to make sure that as few workarounds as possible are needed
for programs like gdb.

I'm concerned that the MinGW patches are going to eventually start
encroaching on win32-nat.c (which we've already seen).  I don't *want*
to litter that file with any special non-cygwin accommodations.

I feel hypocritical here because I've suggested several times that the
MinGW people should be sending their patches to the gdb list but now
that that day is here, I find that I have no interest in worrying about
windows-native issues at all.

So, my email suggested that if MinGW is important to gdb then I probably
shouldn't be the maintainer for Windows.  I do understand why people like
Codesourcery want a native version of gdb.  That doesn't mean that I
have to happily support it, though.

So, I'm not sure what to do here.  I agree with Mark, though (and with
Ulrich Drepper when he made points about non-POSIX systems in his blog).

cgf
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

jimb (Bugzilla)
In reply to this post by Mark Kettenis
On 2/3/06, Mark Kettenis <[hidden email]> wrote:
> GDB is written for POSIX systems.  It's clear that Windows isn't even
> remotely POSIX compliant.

Technically, Stallman would say that GDB is written for GNU systems,
and *all* non-GNU support is a distraction.  Iffy.  So I'm not sure
you really want to push that argument too hard.

But I agree, about the patch.

If we had safe_strerror try a macro which the nm-*.h file could
define, I'd feel better about the change.
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Daniel Jacobowitz-2
On Fri, Feb 03, 2006 at 05:06:11PM -0800, Jim Blandy wrote:

> On 2/3/06, Mark Kettenis <[hidden email]> wrote:
> > GDB is written for POSIX systems.  It's clear that Windows isn't even
> > remotely POSIX compliant.
>
> Technically, Stallman would say that GDB is written for GNU systems,
> and *all* non-GNU support is a distraction.  Iffy.  So I'm not sure
> you really want to push that argument too hard.
>
> But I agree, about the patch.
>
> If we had safe_strerror try a macro which the nm-*.h file could
> define, I'd feel better about the change.

Except we're trying to kill the aggravating NM files, remember?  Also,
it would be an XM file, and we've already successfully killed those (or
most of them).  We replaced them with autoconf magic, which is not
fundamentally different from the USE_WIN32API bits.

I'll be back to the rest of this in a separate message.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Daniel Jacobowitz-2
In reply to this post by Christopher Faylor-12
I have some general responses to this thread so far, which
unfortunately hasn't addressed the actual patch at all but the overall
goal of working on MinGW32 i.e. Windows-without-Cygwin.

On Fri, Feb 03, 2006 at 06:39:35PM -0500, Christopher Faylor wrote:
> On Sat, Feb 04, 2006 at 12:25:19AM +0100, Mark Kettenis wrote:
> >I think this is ugly.  When the win32 support was added, we were told
> >that only minimal changes were necessary.  But people keep pushing
> >#ifdef EVIL_CLOSED_SOURCE_PLATFORM_FROM_REDMOND patches.
> >
> >GDB is written for POSIX systems.  It's clear that Windows isn't even
> >remotely POSIX compliant.

I'm sorry you feel the need to use terms like "evil" to deal with a
real operating system that real people use.

I don't know who said "only minimal changes were necessary" but I'm
sure they were making their best guess at the time.

I don't know why you say that GDB was written for POSIX systems.  I
haven't been around long enough in GNU land and GDB land to know what
it was "written for", but I'd wager from changelogs that GDB was
written for SunOS and other proprietary OS's available at the time, and
written with the eventual goal of working on GNU systems.  Neither of
which was a particularly good map onto what we now think of as POSIX.
I'd say that GDB was written for the hosts that were interesting at the
time.  Many of which happened to have a BSD heritage.

> Hmm.  As it turns out, I have some email sitting in my "to be sent"
> folder that I've held back on sending which is tangentially related
> to this.
>
> The gist of the email is that I'm not happy having to support
> windows-specific workarounds in gdb while standing on my head in
> cygwin-land to make sure that as few workarounds as possible are needed
> for programs like gdb.

I'm going to make a couple of points here.  They're mostly aimed at the
GDB list, not at Chris - who's well aware of all of them already.

1.  Cygwin is an amazing, and amazingly useful, piece of work.

2.  Cygwin is not an FSF project.

3.  Relying on Cygwin to support Windows is awkward for a whole lot
of reasons, which are in many cases accepted as good ones, and I hope
that I don't need to rehash right now.  But I will if I have to.  Just
ask.

That's why some people do it with Cygwin and some people do it without.
CodeSourcery has both decided on our own (based on the technical
merits) and heard unequivocally from our customers that relying on
Cygwin just isn't going to cut it.

What I'd _love_ to do is refactor the bits of Cygwin which we need,
which are considerably smaller than the whole of Cygwin, so that we
could link them directly into GDB and not have to worry about it any
more.  Given the copyright status of Cygwin, however, I think this is a
non-starter.  I'm not even sure whether it would fit into the design
of Cygwin, or end up rewriting much of it anyway.

It might be possible to create a minimalist set of POSIX wrapper
functions for Windows which were nowhere near as complete as Cygwin,
were built on top of mingw32, and were moderately more transparent to
GDB.  But I don't think they'd be of much general use besides for GDB,
because there's real limits to how good an emulation you can manage
without - surprise! - reinventing Cygwin!  See #1 above, please.

> I'm concerned that the MinGW patches are going to eventually start
> encroaching on win32-nat.c (which we've already seen).  I don't *want*
> to litter that file with any special non-cygwin accommodations.

How bad do you really expect this to be?  I've never seen the native
MinGW debugging patches; I don't intend to take a look at them, since
right now we (i.e. in my day job) only need Windows hosting and not
Windows native debugging.  But I'd expect that changes would either be
small (if done right), or else relatively easy to break out into a
separate file using this neat target inheritance concept we put so much
effort into.

The question of Windows support is not going to go away at any point in
the foreseeable future.  If the GDB community is going to throw up its
hands and say ugh, well, I'd be pretty disappointed.  And CodeSourcery
would be maintaining a branch with these patches for all of that
foreseeable future, and shipping it.  We're trying as hard as we can to
not do that - it's not good for us, it's not good for GDB, it's not
good for users who would like to build GDB releases on Windows.

I'm sorry a lot of you find the changes either morally or aesthetically
objectionable.  I'm not entirely sure which it is.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Ian Lance Taylor
In reply to this post by Daniel Jacobowitz-2
Daniel Jacobowitz <[hidden email]> writes:

> Except we're trying to kill the aggravating NM files, remember?  Also,
> it would be an XM file, and we've already successfully killed those (or
> most of them).  We replaced them with autoconf magic, which is not
> fundamentally different from the USE_WIN32API bits.

USE_WIN32API is different because it selects an API which is not Unix
like.  It's the only non-Unix-like host which gdb runs on today.  I
think it would be reasonable to have special .h and .c files to handle
Windows code.  You can call them XM files, or you can call them
something else.  Scattering Windows code through the Unix code seems
like a bad idea to me.

I think that scattering autoconf magic through the code is also a bad
idea, and should be avoided.  But I think it is less bad, because at
least the code all looks the same.  Windows code does not.

Ian
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

jimb (Bugzilla)
In reply to this post by Daniel Jacobowitz-2
On 2/3/06, Daniel Jacobowitz <[hidden email]> wrote:
> I'm sorry a lot of you find the changes either morally or aesthetically
> objectionable.  I'm not entirely sure which it is.

When I worked on Emacs from 1990, that was before the autoconf era,
and the code was covered with #ifdef blocks for various architectures
and operating systems.  I found them extremely irritating to work
with, since it took careful examination to figure out exactly what
invariants each branch of the #if expected from the surrounding code.
It didn't help that I didn't usually have documentation handy for
whatever OS-specific bits that #if branch was trying to use.

So I find that kind of thing confusing, and it slows me down.  I don't
expect that everyone has my limitations, but I don't think they're so
rare, either.  A macro that takes documented arguments and is expected
not to randomly refer to stuff from its context is a big improvement
for me.
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Eli Zaretskii
In reply to this post by Christopher Faylor-12
> Date: Fri, 3 Feb 2006 18:39:35 -0500
> From: Christopher Faylor <[hidden email]>
>
> The gist of the email is that I'm not happy having to support
> windows-specific workarounds in gdb while standing on my head in
> cygwin-land to make sure that as few workarounds as possible are needed
> for programs like gdb.

Why do you guys always start important arguments while I'm asleep? ;-)

> I'm concerned that the MinGW patches are going to eventually start
> encroaching on win32-nat.c (which we've already seen).  I don't *want*
> to litter that file with any special non-cygwin accommodations.

Then perhaps we should create a new -nat.c file, say mingw-nat.c, and
maintain it separately.  (For that matter, I'd really love to see
win32-nat.c be renamed to cygwin-nat.c, since that's what it really is
going to be.)  If neither Daniel nor Mark M. can afford becoming
responsible maintainers for such a new native file, I volunteer to do
my best to do that.

Would you agree to such a solution?

> So, I'm not sure what to do here.  I agree with Mark, though (and with
> Ulrich Drepper when he made points about non-POSIX systems in his blog).

I suggest we don't go there, and don't start arguing about Ulrich's
points (which I personally find deeply flawed).  We don't need to
agree on ideology, as long as we find a good way of cooperating
towards common goals, a way that leaves everybody reasonably happy.

After all, even I could drink beer with Ulrich when we met in Japan,
although our email relationship--how should I put it?--leaves a lot to
be desired ;-)
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Eli Zaretskii
In reply to this post by jimb (Bugzilla)
> Date: Fri, 3 Feb 2006 17:06:11 -0800
> From: Jim Blandy <[hidden email]>
> Cc: [hidden email], [hidden email]
>
> If we had safe_strerror try a macro which the nm-*.h file could
> define, I'd feel better about the change.

Which to me sounds strange: when Mark M. suggested his original patch
for the event loop, I asked for the Windows specific parts to be put
in win32-nat.c, instead of littering a system-independent file.
However, no one supported me in that request then, AFAIR.  Would
people who argue for cleansing GDB sources of non-Posix filth please
take a good look at event-loop.c?  If we agree to having that code
there, I don't see how we can possibly lecture Daniel about keeping
system-dependent stuff out.  We need to be consistent about our
standards.

(For the record, in that past discussion about gdb_select I mentioned
above, Daniel argued for having the code in event-loop.c, so Daniel
_is_ consistent about _his_ standards.)
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Eli Zaretskii
In reply to this post by Daniel Jacobowitz-2
> Date: Fri, 3 Feb 2006 22:00:25 -0500
> From: Daniel Jacobowitz <[hidden email]>
> Cc: Mark Kettenis <[hidden email]>, [hidden email]
>
> > If we had safe_strerror try a macro which the nm-*.h file could
> > define, I'd feel better about the change.
>
> Except we're trying to kill the aggravating NM files, remember?  Also,
> it would be an XM file, and we've already successfully killed those (or
> most of them).  We replaced them with autoconf magic, which is not
> fundamentally different from the USE_WIN32API bits.

Right.

But we still can separate system-specific code from system-independent
one.  One way is to have a function which is only defined on systems
which need it.  Something like this:

  #ifdef NEED_FOOBAR
  foobar ();
  #endif

with the body of `foobar' hiding all the rest on a Windows-specific
source file.  I think such a method minimizes the bad impact of
ifdef's and does not annoy too much when one reads the sources.
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Eli Zaretskii
In reply to this post by Ian Lance Taylor
> Cc: Jim Blandy <[hidden email]>, Mark Kettenis <[hidden email]>,   [hidden email]
> From: Ian Lance Taylor <[hidden email]>
> Date: 03 Feb 2006 22:22:10 -0800
>
> It's the only non-Unix-like host which gdb runs on today.

That's not true: there's the DJGPP (a.k.a. MS-DOS) port of GDB, where
GDB still runs.  It just needs less DOS-specific code because it has a
Posix-compliant library (which includes `select' emulation).  But you
can still see an occasional "#ifdef __MSDOS__" or "#ifdef __DJGPP__"
or "#ifdef __GO32__" in the sources.

Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Eli Zaretskii
In reply to this post by jimb (Bugzilla)
> Date: Fri, 3 Feb 2006 22:29:26 -0800
> From: Jim Blandy <[hidden email]>
>
> A macro that takes documented arguments and is expected not to
> randomly refer to stuff from its context is a big improvement for
> me.

The problem with a macro is where to define it.  We previously defined
them on the various *.mt and *.mh files, but now we are trying to
eliminate those.  And the code we are talking about is unsuitable for
the configury stuff, since it is quite long.

So I think, in practice, in this case a macro is not a good solution,
except if it names a function whose implementation is elsewhere.
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Eli Zaretskii
In reply to this post by Daniel Jacobowitz-2
> Date: Fri, 3 Feb 2006 22:27:30 -0500
> From: Daniel Jacobowitz <[hidden email]>
>
> What I'd _love_ to do is refactor the bits of Cygwin which we need,
> which are considerably smaller than the whole of Cygwin, so that we
> could link them directly into GDB and not have to worry about it any
> more.  Given the copyright status of Cygwin, however, I think this is a
> non-starter.  I'm not even sure whether it would fit into the design
> of Cygwin, or end up rewriting much of it anyway.

I think this should be possible, using as the starting point the MinGW
port of glibc (libgw32c from the GnuWin32 download server at
http://prdownloads.sourceforge.net/gnuwin32).  The problem (at least
my problem) is that Some Work Is Needed(tm) to add the missing bits to
that library, e.g. their `select' is a stab that always fails.  So, if
someone wants to go that way, they will need to free some non-trivial
amount of time for the job.

> The question of Windows support is not going to go away at any point in
> the foreseeable future.  If the GDB community is going to throw up its
> hands and say ugh, well, I'd be pretty disappointed.

Me too.  When I work on Windows, I use the MinGW port of GCC
exclusively, even though there's a ``free'' (as in "free beer")
Microsoft compiler one can download from the net.  Not having a good
port of GDB would be a deadly blow for me, and installing Cygwin is
not an option, because I still need to use native Windows programs.

> And CodeSourcery would be maintaining a branch with these patches
> for all of that foreseeable future, and shipping it.

Would CodeSourcery consider supporting a MinGW specific port, along
the lines I suggested elsewhere in this thread (i.e., having a
separate -nat.c file and other files as needed)?  If you will, and if
that support is consistent with the GPL, then I think we can have
everybody happy.
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Eli Zaretskii
In reply to this post by Daniel Jacobowitz-2
> Date: Fri, 3 Feb 2006 16:54:55 -0500
> From: Daniel Jacobowitz <[hidden email]>
>
> This is an improved version of a patch Mark Mitchell submitted last
> year.  If you give strerror() anything above 42 (sys_nerr) on Windows,
> it gives you back "Unknown error" - particularly unfortunate since
> WSAECONNREFUSED is way above there, so connecting to a closed socket
> will give you a generic error message.  This patch lets us try an
> OS-specific interface to fetch an error string.
>
> [Actually you need my next patch too to get the connection refused message;
> right now you'll get a timeout.]
>
> Any comments on this patch?
>
> --
> Daniel Jacobowitz
> CodeSourcery
>
> 2006-02-03  Daniel Jacobowitz  <[hidden email]>
>
> * utils.c (safe_strerror): Try to use FormatMessage for otherwise
> unknown messages on Windows.

How about if you put this in some function on win32-nat.c, and then
leave only the conditional call to that function in utils.c?  Actualy,
perhaps we don't need any ifdef at all, since I think there's no way
the argument can be greater than sys_nerr on other platforms, right?

Otherwise, I'm okay with this patch.
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Mark Kettenis
In reply to this post by jimb (Bugzilla)
> Date: Fri, 3 Feb 2006 17:06:11 -0800
> From: Jim Blandy <[hidden email]>
>
> On 2/3/06, Mark Kettenis <[hidden email]> wrote:
> > GDB is written for POSIX systems.  It's clear that Windows isn't even
> > remotely POSIX compliant.
>
> Technically, Stallman would say that GDB is written for GNU systems,
> and *all* non-GNU support is a distraction.  Iffy.  So I'm not sure
> you really want to push that argument too hard.

Guess I'l have to start GNU/OpenBSD ;-).

Mark
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Mark Kettenis
In reply to this post by Eli Zaretskii
> Date: Sat, 04 Feb 2006 12:29:22 +0200
> From: Eli Zaretskii <[hidden email]>
>
> > Cc: Jim Blandy <[hidden email]>, Mark Kettenis <[hidden email]>,   [hidden email]
> > From: Ian Lance Taylor <[hidden email]>
> > Date: 03 Feb 2006 22:22:10 -0800
> >
> > It's the only non-Unix-like host which gdb runs on today.
>
> That's not true: there's the DJGPP (a.k.a. MS-DOS) port of GDB, where
> GDB still runs.  It just needs less DOS-specific code because it has a
> Posix-compliant library (which includes `select' emulation).  But you
> can still see an occasional "#ifdef __MSDOS__" or "#ifdef __DJGPP__"
> or "#ifdef __GO32__" in the sources.

But DJGPP at least takes the trouble of providing that POSIX
compatible library.  And there is a Free (as in Freedom) MS-DOS
available (don't know if DJGPP runs on it though).

That said, I'd probably object if someone would contribute a DJGPP
port with all its #ifdef's today.  But we've had DJGPP support in the
tree for ages, and as long as there's someone actively working on
DJGPP support I feel that I can't ask for its removal.

Mark
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Mark Kettenis
In reply to this post by Daniel Jacobowitz-2
> Date: Fri, 3 Feb 2006 22:27:30 -0500
> From: Daniel Jacobowitz <[hidden email]>
>
> I have some general responses to this thread so far, which
> unfortunately hasn't addressed the actual patch at all but the overall
> goal of working on MinGW32 i.e. Windows-without-Cygwin.
>
> On Fri, Feb 03, 2006 at 06:39:35PM -0500, Christopher Faylor wrote:
> > On Sat, Feb 04, 2006 at 12:25:19AM +0100, Mark Kettenis wrote:
> > >I think this is ugly.  When the win32 support was added, we were told
> > >that only minimal changes were necessary.  But people keep pushing
> > >#ifdef EVIL_CLOSED_SOURCE_PLATFORM_FROM_REDMOND patches.
> > >
> > >GDB is written for POSIX systems.  It's clear that Windows isn't even
> > >remotely POSIX compliant.
>
> I'm sorry you feel the need to use terms like "evil" to deal with a
> real operating system that real people use.

Perhaps I should have said

#ifdef CLOSED_SOURCE_PLATFORM_FROM_EVIL_COMPANY_FROM_REDMOND

You're right an operating system can't be evil.  (But this is probably
not the point you wanted to make ;-)).

> I don't know who said "only minimal changes were necessary" but I'm
> sure they were making their best guess at the time.

In my recollection, Mark Mitchell, did say that.  I grudgingly agreed
to having the MinGW32 supprt in and actively worked together with him
to reduce the amount of clutter from #ifdef's and such.  It now turns
out even more #ifdef's are needed.  Will this ever stop?

> 3.  Relying on Cygwin to support Windows is awkward for a whole lot
> of reasons, which are in many cases accepted as good ones, and I hope
> that I don't need to rehash right now.  But I will if I have to.  Just
> ask.
>
> That's why some people do it with Cygwin and some people do it without.
> CodeSourcery has both decided on our own (based on the technical
> merits) and heard unequivocally from our customers that relying on
> Cygwin just isn't going to cut it.

You may have to refresh my mind.  I can see that depending on a third
party library makes life a bit more difficult since you have to
distribute it together with your project, but doesn't MinGW require
you to do something similar?

> It might be possible to create a minimalist set of POSIX wrapper
> functions for Windows which were nowhere near as complete as Cygwin,
> were built on top of mingw32, and were moderately more transparent to
> GDB.  But I don't think they'd be of much general use besides for GDB,
> because there's real limits to how good an emulation you can manage
> without - surprise! - reinventing Cygwin!  See #1 above, please.

So why aren't you using Cygwin then?  It really seems that this was a
bussiness decision rather than a decision made on purely technical
grounds.

> I'm sorry a lot of you find the changes either morally or aesthetically
> objectionable.  I'm not entirely sure which it is.

My objections are mostly techincal, or easthetical if you want to call
it that.  Having two different versions of support code for what's in
the end the same platform is silly.  But I admot morality plays a role
here.  I'm much more inclined to accept #ifdef's for a Free (as in
Freedom) system than I am for a non-free system.

Mark

Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Daniel Jacobowitz-2
On Sat, Feb 04, 2006 at 03:35:06PM +0100, Mark Kettenis wrote:
> > I don't know who said "only minimal changes were necessary" but I'm
> > sure they were making their best guess at the time.
>
> In my recollection, Mark Mitchell, did say that.  I grudgingly agreed
> to having the MinGW32 supprt in and actively worked together with him
> to reduce the amount of clutter from #ifdef's and such.  It now turns
> out even more #ifdef's are needed.  Will this ever stop?

Mark's an optimist.  What can I say?  :-)

Honestly, I don't think there's much more - this was the big missing
feature for cross hosts, any more would be native support and that
is more easily compartmentalizable.  But the port is still very
young, so I do not know.  My crystal ball's in the shop.

> > 3.  Relying on Cygwin to support Windows is awkward for a whole lot
> > of reasons, which are in many cases accepted as good ones, and I hope
> > that I don't need to rehash right now.  But I will if I have to.  Just
> > ask.
> >
> > That's why some people do it with Cygwin and some people do it without.
> > CodeSourcery has both decided on our own (based on the technical
> > merits) and heard unequivocally from our customers that relying on
> > Cygwin just isn't going to cut it.
>
> You may have to refresh my mind.  I can see that depending on a third
> party library makes life a bit more difficult since you have to
> distribute it together with your project, but doesn't MinGW require
> you to do something similar?

No.  MinGW is primarily header files and import stubs for the standard
Microsoft DLLs, which are already present on just about any Windows
system.  I'm not sure if they're all always installed or just most of
them are always installed and the others usually installed.

A GDB linked to MinGW runs on a clean Windows install; gdb.exe is all
you need.  It uses kernel32.dll, msvcrt.dll, and ws2_32.dll.

> > It might be possible to create a minimalist set of POSIX wrapper
> > functions for Windows which were nowhere near as complete as Cygwin,
> > were built on top of mingw32, and were moderately more transparent to
> > GDB.  But I don't think they'd be of much general use besides for GDB,
> > because there's real limits to how good an emulation you can manage
> > without - surprise! - reinventing Cygwin!  See #1 above, please.
>
> So why aren't you using Cygwin then?  It really seems that this was a
> bussiness decision rather than a decision made on purely technical
> grounds.

Sorry, Mark, but did you not read the bit you quoted above?  "on or own
(based on the technical merits)".  It was also a business decision, but
there are compelling technical reasons for us not to use Cygwin.

For instance, the Cygwin DLL is a sort of "consensual reality", if
you'll forgive the analogy.  The emulation involves communication
between Cygwin processes in some non-obvious ways (to me anyway).
One of the consequences is that Cygwin apps get real unhappy
when there's multiple copies of Cygwin installed, and there are folks
who already use Cygwin (obviously), so installing one's own
copy is fragile.  And there's vendors of third-party software
who ship copies of Cygwin in private directories, or heavily
modified, so you can't always rely on the installed copy.

Another reason is performance.  Not a big issue for GDB, but Cygwin
makes a pretty measurable dent in GCC compile times, or at least
it did the last time we did measurements.  That's another reason
we really needed to ship a MinGW toolchain, and having done so
there could be even more interoperability problems using it with
a Cygwin GDB.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: RFA: Support Windows extended error numbers in safe_strerror

Daniel Jacobowitz-2
In reply to this post by Eli Zaretskii
On Sat, Feb 04, 2006 at 01:58:45PM +0200, Eli Zaretskii wrote:
> How about if you put this in some function on win32-nat.c, and then
> leave only the conditional call to that function in utils.c?  Actualy,
> perhaps we don't need any ifdef at all, since I think there's no way
> the argument can be greater than sys_nerr on other platforms, right?

Well, it can't be in win32-nat.c - it's for Windows hosting rather
than Windows native.  But I could move the code to a new
Windows-specific file, like ser-windows.o introduced in my other
patch, and call it there.  I've no objection to that.

--
Daniel Jacobowitz
CodeSourcery
12345