This is the mail archive of the
mailing list for the GDB project.
RE: [RFC 0/9] Unify windows specifics into common/windows-hdep files
- From: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- To: <gdb-patches at sourceware dot org>
- Date: Mon, 4 Apr 2011 09:04:47 +0200
- Subject: RE: [RFC 0/9] Unify windows specifics into common/windows-hdep files
- References: <009f01cbeed2$9bf0bf20$d3d23d60$@email@example.com> <20110402211414.GA6371@ednor.casa.cgf.cx>
> -----Message d'origine-----
> De?: firstname.lastname@example.org [mailto:gdb-patches-
> email@example.com] De la part de Christopher Faylor
> I don't see the above as compelling reasons for this major change.
> You're introducing a large patch set for what I'd consider a fairly
> minor goal. I don't consider the current #ifdefs in windows-nat.c that
This first series of patches is indeed pretty minor concerning
features, the new features are to be delivered in later patch series.
I have patches for:
- Support for environment variables for Cygwin/Ming
- Multiple inferior support for Windows
- 32-bit support within the 64-bit mingw64 debugger.
You can see large parts of those patches in the branch I created in
Branch name is: archer-muller-windows-multi
(warning, current state of the branch does not have all features
See ebcaa14a commit for a global view).
To avoid having to put those change both for Cygwin and for Mingw,
I tried hard to removed most #ifdef's fro windows-nat.c
and this patch series is the result of this work.
Thus I understand that you do not see compelling reasons
for the change as they do not appear here.
> As the maintainer for the Windows version of GDB and one of the
> maintainers of Cygwin I'd like to officially just decree that we no
> longer support Cygwin 1.5 in newer versions of GDB. This is related
> to my reluctance to do hoop jumping in gdb to support things in native
> Windows that we have worked around in Cygwin.
This is of course a choice that I understand
and I have no problems with dropping Cygwin 1.5 if you want to.
The main goal for me is more to enable compilation of mingw (both 32 and 64
to be able to use ASCII and Unicode version of the Windows API.
> Again, I'm not interested in spending any time accommodating Cygwin 1.5.
> It is unsupported. Working hard to keep it supported is going in the
> wrong direction.
OK, I can certainly remove the Cygwin 1.5 support part of my patch.
but aain, this is not at all the main goal of my patch series.
> If we really do want to spend time gaining the advantages of longer
> pathnames and internationalization then, once we no longer support
> Cygwin 1.5, the decision should be fairly clear: Just use wide
> characters throughout. Keeping an "ascii" version around doesn't make
> much sense to me.
But it does to me, I submitted a few patches to ensure that recent
mingw GDB would be able to run on a plain old Windows 95 machine.
I know that you have absolutely no interest in such old systems,
but I am an old-timer and would love to have my multi-inferior patch
also usable on such old systems.
> Oh, wrt accommodating the msys shell, I'm vetoing the idea right now.
> I'm not interested in adding gdb support for another barely-supported
> version of Cygwin. Again, I like to confine my head-standing to Cygwin
I can understand your position, you are mainly interested
in Cygwin support as this is your main work,
but shouldn't that mean that we should
separate out cygwin and mingw specific differences
into different sources so that you would not need to care about
what is changed inside those mingw specific source files as
it would not affect Cygwin port?
the common/windows-hdep.c could be split into
common/hdep-cygwin.c and common/hdep-mingw.c
(I put hdep in front because there already is a mingw-hdep.c present
in gdb directory).
This would allow to share most code inside windows-nat.c
and handle differences (like directory handling)
inside those sub-files.
GDB pascal language support maintainer