This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [RFC 0/9] Unify windows specifics into common/windows-hdep files


> -----Message d'origine-----
> De?: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] 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
> onerous.

  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
Archer-Git
http://sourceware.org/gdb/wiki/ArcherBranchManagement
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
bits)
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
> itself.
  
  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.


  Pierre Muller
GDB pascal language support maintainer




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]