Re: RFA: Support Windows extended error numbers in safe_strerror

Daniel Jacobowitz
2006-02-04T03:27:38Z

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