From: "Eli Zaretskii" <eliz@gnu.org>
To: Mark Mitchell <mark@codesourcery.com>
Cc: paul@codesourcery.com, gdb@sourceware.org
Subject: Re: Windows support in GDB
Date: Sun, 01 May 2005 20:13:00 -0000 [thread overview]
Message-ID: <01c54e89$Blat.v2.4$e3534b20@zahav.net.il> (raw)
In-Reply-To: <20050429165148.GD12864@trixie.casa.cgf.cx> (message from Christopher Faylor on Fri, 29 Apr 2005 12:51:48 -0400)
> Date: Fri, 29 Apr 2005 12:51:48 -0400
> From: Christopher Faylor <me@cgf.cx>
>
> >What's the failure mode going to be? If a POSIX person adds a use of
> >non-Windows function, without appropriate #ifdef, then the Windows side
> >of things will break. At that point, assuming that people are noticing
> >(which we will!), we'll fix that.
>
> I guess the failure mode will be roughly similar to DJGPP. Every time
> someone decides that it would be nice to use signal(), select(), fifos,
> inodes, unix-domain sockets, or some other non-msdos construct there
> will have to be a discussion about how to make things work. But, I
> guess we'd already be having this discussion to with DJGPP so maybe it
> won't be a big deal.
DJGPP has less problems than MinGW because DJGPP is more Posix
compliant. E.g., out of the non-msdos constructs you mentioned, DJGPP
has `signal', `select', and inodes.
But yes, quite a few of Unixish assumptions already bit the dust since
the DJGPP port is part of GDB. IS_ABSOLUTE_PATH and similar
abstractions come to mind, as does DIRNAME_SEPARATOR. Undoubtedly,
this is one reason why the MinGW port additions were relatively minor.
next prev parent reply other threads:[~2005-05-01 20:13 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-29 15:32 Mark Kettenis
2005-04-29 15:32 ` Daniel Jacobowitz
2005-04-29 16:08 ` Christopher Faylor
2005-04-29 16:31 ` Mark Mitchell
2005-04-29 16:36 ` Christopher Faylor
2005-04-29 16:47 ` Mark Mitchell
2005-04-29 16:56 ` Christopher Faylor
2005-04-29 17:05 ` Mark Mitchell
2005-04-29 17:16 ` Christopher Faylor
2005-05-01 20:13 ` Eli Zaretskii [this message]
2005-05-01 19:50 ` Eli Zaretskii
2005-04-29 16:52 ` Dave Korn
2005-04-29 16:57 ` Mark Mitchell
2005-04-29 17:00 ` Dave Korn
2005-04-30 16:18 ` Mark Kettenis
2005-04-30 20:37 ` Christopher Faylor
2005-05-01 20:05 ` Eli Zaretskii
2005-05-01 20:06 ` Mark Mitchell
2005-05-01 20:24 ` Eli Zaretskii
2005-04-29 16:32 ` Kris Warkentin
2005-04-29 16:40 ` Christopher Faylor
2005-04-29 17:00 ` Kris Warkentin
2005-05-01 19:55 ` Eli Zaretskii
2005-05-01 21:41 ` Christopher Faylor
2005-05-02 19:03 ` Eli Zaretskii
2005-05-02 19:56 ` Christopher Faylor
2005-04-29 16:48 ` Daniel Jacobowitz
2005-04-29 17:33 ` Christopher Faylor
2005-04-29 17:58 ` Daniel Jacobowitz
2005-04-29 19:08 ` Christopher Faylor
2005-04-29 19:36 ` Daniel Jacobowitz
2005-04-29 22:01 ` Christopher Faylor
2005-05-02 15:41 ` Andrew Cagney
2005-05-02 15:45 ` Daniel Jacobowitz
2005-04-29 16:04 ` Kris Warkentin
2005-04-29 16:23 ` Mark Mitchell
2005-04-29 16:46 ` Christopher Faylor
2005-04-29 16:50 ` Mark Mitchell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='01c54e89$Blat.v2.4$e3534b20@zahav.net.il' \
--to=eliz@gnu.org \
--cc=gdb@sourceware.org \
--cc=mark@codesourcery.com \
--cc=paul@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox