Windows support in GDB

Windows support in GDB

[Mark Kettenis]

Guys, I'm getting a bit of an uneasy feeling here.  It may be that I'm
getting the wrong impression here, but I've seen quite a bit more
Windows-related patches than I had in mind when Mark started submitted
his first patches and said they were fairly limited and mostly some
configure bits.  The problem here is that they mostly concern the
non-POSIX nature of Windows, which sets its quit far apart from the
traditional Unix-like systems that have been converging towards POSIX
for quite some time now.  This means that we really need to have some
commitment from the Windows user community for maintaining this stuff.
Otherwise this will become another MetroWerks disaster.

It's fairly obvious that this development is coming from CodeSourcery.
There's nothing wrong with that, but I'd like to ask CodeSourcery what
their commitment to maintaining this new code is.  In the past we have
seen quite a few contributions from embedded sofware companies.  In
many cases these contributions were apparently done as contract work,
and after the work was completed the code was never touched again.
Can CodeSourcery gives some clarification on this matter?

Mark

Re: Windows support in GDB

[Daniel Jacobowitz]

Hi Mark,

On Fri, Apr 29, 2005 at 05:13:43PM +0200, Mark Kettenis wrote:
> Guys, I'm getting a bit of an uneasy feeling here.  It may be that I'm
> getting the wrong impression here, but I've seen quite a bit more
> Windows-related patches than I had in mind when Mark started submitted
> his first patches and said they were fairly limited and mostly some
> configure bits.  The problem here is that they mostly concern the

Paul's new patches are issues that we didn't encounter when we built
our first generation of Windows toolchains.  I apologize for our
failures to be perfect and predict the future.  What more can you ask
of us?

By the way, I'd still characterize these patches as fairly limited and
mostly configure-related.  All the readline patches certainly are, for
instance.

The SIGTRAP patch makes me a little uncomfortable - and it makes Paul
a bit nervous too.  That's why it wasn't submitted for mainline.  The
right fix is to not use host signal numbers in the simulator interface.

> non-POSIX nature of Windows, which sets its quit far apart from the
> traditional Unix-like systems that have been converging towards POSIX
> for quite some time now.  This means that we really need to have some
> commitment from the Windows user community for maintaining this stuff.
> Otherwise this will become another MetroWerks disaster.

I don't know what you're referring to.  Are you thinking of the HP
merge?

> It's fairly obvious that this development is coming from CodeSourcery.
> There's nothing wrong with that, but I'd like to ask CodeSourcery what
> their commitment to maintaining this new code is.  In the past we have
> seen quite a few contributions from embedded sofware companies.  In
> many cases these contributions were apparently done as contract work,
> and after the work was completed the code was never touched again.
> Can CodeSourcery gives some clarification on this matter?

We have a strong push from our customers - not just any one customer -
for these features.  These are ongoing maintenance contracts and we
will be continuing to support it for the foreseeable future.  Also, I
imagine that once GDB starts to build out of the box on Windows, more
and more people will begin to use it there.  There's a staggering
demand for native Windows-hosted tools.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Windows support in GDB

[Christopher Faylor]

On Fri, Apr 29, 2005 at 11:31:46AM -0400, Daniel Jacobowitz wrote:
>Hi Mark,
>
>On Fri, Apr 29, 2005 at 05:13:43PM +0200, Mark Kettenis wrote:
>> Guys, I'm getting a bit of an uneasy feeling here.  It may be that I'm
>> getting the wrong impression here, but I've seen quite a bit more
>> Windows-related patches than I had in mind when Mark started submitted
>> his first patches and said they were fairly limited and mostly some
>> configure bits.  The problem here is that they mostly concern the
>
>Paul's new patches are issues that we didn't encounter when we built
>our first generation of Windows toolchains.  I apologize for our
>failures to be perfect and predict the future.  What more can you ask
>of us?
>
>By the way, I'd still characterize these patches as fairly limited and
>mostly configure-related.  All the readline patches certainly are, for
>instance.
>
>The SIGTRAP patch makes me a little uncomfortable - and it makes Paul
>a bit nervous too.  That's why it wasn't submitted for mainline.  The
>right fix is to not use host signal numbers in the simulator interface.
>
>> non-POSIX nature of Windows, which sets its quit far apart from the
>> traditional Unix-like systems that have been converging towards POSIX
>> for quite some time now.  This means that we really need to have some
>> commitment from the Windows user community for maintaining this stuff.
>> Otherwise this will become another MetroWerks disaster.
>
>I don't know what you're referring to.  Are you thinking of the HP
>merge?
>
>>It's fairly obvious that this development is coming from CodeSourcery.
>>There's nothing wrong with that, but I'd like to ask CodeSourcery what
>>their commitment to maintaining this new code is.  In the past we have
>>seen quite a few contributions from embedded sofware companies.  In
>>many cases these contributions were apparently done as contract work,
>>and after the work was completed the code was never touched again.  Can
>>CodeSourcery gives some clarification on this matter?
>
>We have a strong push from our customers - not just any one customer -
>for these features.  These are ongoing maintenance contracts and we
>will be continuing to support it for the foreseeable future.  Also, I
>imagine that once GDB starts to build out of the box on Windows, more
>and more people will begin to use it there.  There's a staggering
>demand for native Windows-hosted tools.

Of course it does build "out of the box" on Windows right now if you
have cygwin.

While I am the Windows maintainer for gdb, I have been thinking that
maybe I might have to step down if it means that I'll have to support a
Windows configuration for which I have little interest.

I haven't asked what the problem is with just using cygwin with gdb.
I suspect that the standard two problems are:

1) cygwin is "slow" (which really only is an issue for configure/make)

and

2) You can't trivially include your own version of cygwin1.dll with
a distribution since it could conflict with a version already on
the system.

I can't do much to address 1 but 2 is not an insurmountable problem.

cgf

Re: Windows support in GDB

[Mark Mitchell]

Christopher Faylor wrote:

> While I am the Windows maintainer for gdb, I have been thinking that
> maybe I might have to step down if it means that I'll have to support a
> Windows configuration for which I have little interest.

I think that would be a shame.

> I haven't asked what the problem is with just using cygwin with gdb.
> I suspect that the standard two problems are:

You might ask the MinGW community why they exist. :-)

One reason to use MinGW is that you're using other tools that rely on 
Windows paths, and don't understand Cygwin mount points.  Or you 
yourself don't understand Cygwin mount points. :-)

The fundamental reason for us to use it is that our customers say -- 
strongly -- that they do not want to use Cygwin.  (In contrast, I use 
Cygwin every day.)  There are a lot of possible reasons for the customer 
desire, and it doesn't really seem all that useful to debate the 
reasons, as our debate won't change their minds.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Windows support in GDB

[Christopher Faylor]

On Fri, Apr 29, 2005 at 09:14:34AM -0700, Mark Mitchell wrote:
>Christopher Faylor wrote:
>>While I am the Windows maintainer for gdb, I have been thinking that
>>maybe I might have to step down if it means that I'll have to support a
>>Windows configuration for which I have little interest.
>
>I think that would be a shame.
>
>>I haven't asked what the problem is with just using cygwin with gdb.  I
>>suspect that the standard two problems are:
>
>You might ask the MinGW community why they exist.  :-)

I'm a member of the MinGW community and admirer of MinGW but,
unfortunately, that doesn't necessarily translate into my wanting to
support gdb-on-windows-sans-cygwin.

So far, I've had no problems with the patches being applied.  I've
been asking people in the MinGW community to submit patches for
a long time.

However, now that the patches are finally here, I have to say that I
sort of share Mark K's concerns.  I'm wondering if we are on a slippery
slope and (to mix a metaphor) will be subjecting gdb to a
death-by-inches as we slowly add ifdefs throughout the configury and
code.

>One reason to use MinGW is that you're using other tools that rely on 
>Windows paths, and don't understand Cygwin mount points.  Or you 
>yourself don't understand Cygwin mount points. :-)

You don't have to use windows mount points if you don't want to.  AFAIK,
normal windows paths have been working in gdb for a while.  I'm not talking
about requiring a complete cygwin environment to run gdb.  In theory,
all that you really need is "gdb.exe + cygwin1.dll".

But, as you said, this discussion probably isn't worthwhile.  Customers
want what they want.

cgf

Re: Windows support in GDB

[Mark Mitchell]

Christopher Faylor wrote:

> However, now that the patches are finally here, I have to say that I
> sort of share Mark K's concerns.  I'm wondering if we are on a slippery
> slope and (to mix a metaphor) will be subjecting gdb to a
> death-by-inches as we slowly add ifdefs throughout the configury and
> code.

I think it's a funny time to get concerned -- we're done. :-)  There are 
no more cuts coming, so as long as we're not bleeding to death yet, 
we're not going to die.  Plenty of GNU software has similar patches to 
support running on MinGW.  GDB itself already has 2500 lines of code in 
win32-nat.c, some of which I would imagine is rather more opaque to 
POSIX programmers than anything we've added.

We made these changes with no algorithmic modifications to GDB, no 
perversions of its core design, etc.

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 certainly don't think the entire codebase will be littered with 
HANDLEs and ReadFileEx, or transformed into a multi-threaded application 
with a Windows event loop in the middle of it, or anything like that.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Windows support in GDB

[Christopher Faylor]

On Fri, Apr 29, 2005 at 09:43:35AM -0700, Mark Mitchell wrote:
>Christopher Faylor wrote:
>>However, now that the patches are finally here, I have to say that I
>>sort of share Mark K's concerns.  I'm wondering if we are on a slippery
>>slope and (to mix a metaphor) will be subjecting gdb to a
>>death-by-inches as we slowly add ifdefs throughout the configury and
>>code.
>
>I think it's a funny time to get concerned -- we're done.

For now.  Didn't you just theorize more involvement from the MinGW
community now that your patch is in?

I have to admit that I've got incredibly mixed feelings about this.
After years of asking for patches, I'm happy that they are finally in.
Now I find myself mildly dreading the support aspect.

But, I guess we can see how it goes.

>There are no more cuts coming, so as long as we're not bleeding to
>death yet, we're not going to die.  Plenty of GNU software has similar
>patches to support running on MinGW.  GDB itself already has 2500 lines
>of code in win32-nat.c, some of which I would imagine is rather more
>opaque to POSIX programmers than anything we've added.
>
>We made these changes with no algorithmic modifications to GDB, no
>perversions of its core design, etc.
>
>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.

>I certainly don't think the entire codebase will be littered with 
>HANDLEs and ReadFileEx, or transformed into a multi-threaded application 
>with a Windows event loop in the middle of it, or anything like that.

No, but maybe we should rewrite gdb in c++.  That sounds like it would
solve everything.  :-)

cgf

Re: Windows support in GDB

[Mark Mitchell]

Christopher Faylor wrote:
> On Fri, Apr 29, 2005 at 09:43:35AM -0700, Mark Mitchell wrote:
> 
>>Christopher Faylor wrote:
>>
>>>However, now that the patches are finally here, I have to say that I
>>>sort of share Mark K's concerns.  I'm wondering if we are on a slippery
>>>slope and (to mix a metaphor) will be subjecting gdb to a
>>>death-by-inches as we slowly add ifdefs throughout the configury and
>>>code.
>>
>>I think it's a funny time to get concerned -- we're done.
> 
> 
> For now.  Didn't you just theorize more involvement from the MinGW
> community now that your patch is in?

Possibly -- but I'd expect that to be more in the area of adding 
features for debugging Windows applications, if that were to be needed.

> 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.

I agree with both your assessment of the potential problem and the 
impact.  (Even Cygwin doesn't provide complete emulation for absolutely 
everything, so I'd imagine that some of that discussion would need to be 
had anyhow.)

>>I certainly don't think the entire codebase will be littered with 
>>HANDLEs and ReadFileEx, or transformed into a multi-threaded application 
>>with a Windows event loop in the middle of it, or anything like that.
> 
> No, but maybe we should rewrite gdb in c++.  That sounds like it would
> solve everything.  :-)

Then Windows support would just be a specialization of some class 
template. :-)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Windows support in GDB

[Christopher Faylor]

On Fri, Apr 29, 2005 at 10:00:32AM -0700, Mark Mitchell wrote:
>>>I certainly don't think the entire codebase will be littered with 
>>>HANDLEs and ReadFileEx, or transformed into a multi-threaded application 
>>>with a Windows event loop in the middle of it, or anything like that.
>>
>>No, but maybe we should rewrite gdb in c++.  That sounds like it would
>>solve everything.  :-)
>
>Then Windows support would just be a specialization of some class 
>template. :-)

Now we're onto something!

cgf

Re: Windows support in GDB

[Eli Zaretskii]

> 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.

Re: Windows support in GDB

[Eli Zaretskii]

> Date: Fri, 29 Apr 2005 09:43:35 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> CC: paul@codesourcery.com,  gdb@sourceware.org
> 
> Christopher Faylor wrote:
> 
> > However, now that the patches are finally here, I have to say that I
> > sort of share Mark K's concerns.  I'm wondering if we are on a slippery
> > slope and (to mix a metaphor) will be subjecting gdb to a
> > death-by-inches as we slowly add ifdefs throughout the configury and
> > code.
> 
> I think it's a funny time to get concerned -- we're done. :-)  There are 
> no more cuts coming, so as long as we're not bleeding to death yet, 
> we're not going to die.  Plenty of GNU software has similar patches to 
> support running on MinGW.  GDB itself already has 2500 lines of code in 
> win32-nat.c, some of which I would imagine is rather more opaque to 
> POSIX programmers than anything we've added.
> 
> We made these changes with no algorithmic modifications to GDB, no 
> perversions of its core design, etc.

FWIW, I agree with Mark M. here: the changes added to support MinGW
were minimal, almost unnoticed in the sources.

> I certainly don't think the entire codebase will be littered with 
> HANDLEs and ReadFileEx, or transformed into a multi-threaded application 
> with a Windows event loop in the middle of it, or anything like that.

Perhaps we should have a mingw.c file to hide any such code, should
there be a need in the future.  Not that I see a need for that now,
except maybe to put there the gdb_select emulation.

RE: Windows support in GDB

[Dave Korn]

----Original Message----
>From: Mark Mitchell
>Sent: 29 April 2005 17:15

> The fundamental reason for us to use it is that our customers say --
> strongly -- that they do not want to use Cygwin.  (In contrast, I use
> Cygwin every day.)  There are a lot of possible reasons for the customer
> desire, and it doesn't really seem all that useful to debate the
> reasons, as our debate won't change their minds.

 :)  The customer is always right, even if they're a complete idiot!

  Also, "find out what your customers want and give it to them" is good
business practice, whereas "find out what you've got and try to make your
customers want it" is <blech> marketing.

  Have a good weekend everyone!

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Windows support in GDB

[Mark Mitchell]

Dave Korn wrote:
> ----Original Message----
> 
>>From: Mark Mitchell
>>Sent: 29 April 2005 17:15
> 
> 
>>The fundamental reason for us to use it is that our customers say --
>>strongly -- that they do not want to use Cygwin.  (In contrast, I use
>>Cygwin every day.)  There are a lot of possible reasons for the customer
>>desire, and it doesn't really seem all that useful to debate the
>>reasons, as our debate won't change their minds.
> 
> 
>  :)  The customer is always right, even if they're a complete idiot!

Hardly -- and we consider it part of our job to educate our customers on 
what's appropriate and what's not.  But we also know enough to realize 
that sometimes we're not going to change their minds.  And sometimes 
they have good reasons for seeing things differently than us.

GDB certainly contains more autoconf #ifdefs to support various versions 
of UNIX than have been added through our recent Windows patches.  I'm 
genuinely perplexed as to where the concerns are originating.  I'd 
understand concerns about hacking up the DWARF reader, or the symbol 
table interface, or even adding support for the Visual C debug format 
(we have no such plans!).  But here we've added things like #ifdef 
HAVE_SIGPIPE around uses of SIGPIPE, where the code already contained 
very similar #ifdefs.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

RE: Windows support in GDB

[Dave Korn]

----Original Message----
>From: Mark Mitchell
>Sent: 29 April 2005 17:56

> Dave Korn wrote:
>> ----Original Message----
>> 
>>> From: Mark Mitchell
>>> Sent: 29 April 2005 17:15
>> 
>> 
>>> The fundamental reason for us to use it is that our customers say --
>>> strongly -- that they do not want to use Cygwin.  (In contrast, I use
>>> Cygwin every day.)  There are a lot of possible reasons for the customer
>>> desire, and it doesn't really seem all that useful to debate the
>>> reasons, as our debate won't change their minds.
>> 
>> 
>>  :)  The customer is always right, even if they're a complete idiot!
> 
> Hardly -- and we consider it part of our job to educate our customers on
> what's appropriate and what's not.


  Actually, yes, you do have a point there.  I am reminded of the story
about the customer who *insisted* most forcefully to his contractor that the
windows kernel-mode deviced driver he was contracted to develop absolutely
*had* to be written in MFC..... :-O


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Windows support in GDB

[Mark Kettenis]

   Date: Fri, 29 Apr 2005 09:56:08 -0700
   From: Mark Mitchell <mark@codesourcery.com>

"Oh my god.  What did I do!"

Anyway, I want to thank Mark and Daniel for explaining a bit of the
background.  The key point is that there will be people tracking gdb
on MinGW systems fixing any accidental breakage, and willing to answer
questions about MinGW-specific questions.  That seems to be the case.
It'd be great if this could somehow be formalized by having a MinGW
host maintainer (then we could clarify Christophers role as Cygwin
host & native).

Mark

Re: Windows support in GDB

[Christopher Faylor]

On Sat, Apr 30, 2005 at 04:29:49PM +0200, Mark Kettenis wrote:
>   Date: Fri, 29 Apr 2005 09:56:08 -0700
>   From: Mark Mitchell <mark@codesourcery.com>
>
>"Oh my god.  What did I do!"
>
>Anyway, I want to thank Mark and Daniel for explaining a bit of the
>background.  The key point is that there will be people tracking gdb
>on MinGW systems fixing any accidental breakage, and willing to answer
>questions about MinGW-specific questions.  That seems to be the case.
>It'd be great if this could somehow be formalized by having a MinGW
>host maintainer (then we could clarify Christophers role as Cygwin
>host & native).

I am willing to continue to be the Windows maintainer.  Most of the
issues that I deal with in gdb are Windows related, not cygwin related.
It wouldn't make sense to have someone else worrying about Windows.

cgf

Re: Windows support in GDB

[Eli Zaretskii]

> Date: Fri, 29 Apr 2005 09:14:34 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> CC: paul@codesourcery.com,  gdb@sourceware.org
> 
> The fundamental reason for us to use it is that our customers say -- 
> strongly -- that they do not want to use Cygwin.  (In contrast, I use 
> Cygwin every day.)

I hope you use the MinGW ports at least as much as you use Cygwin.
Because if those who work on porting tools don't put their own ports
to some serious use, those tolls will remain, well, less ported.

Re: Windows support in GDB

[Mark Mitchell]

Eli Zaretskii wrote:
>>Date: Fri, 29 Apr 2005 09:14:34 -0700
>>From: Mark Mitchell <mark@codesourcery.com>
>>CC: paul@codesourcery.com,  gdb@sourceware.org
>>
>>The fundamental reason for us to use it is that our customers say -- 
>>strongly -- that they do not want to use Cygwin.  (In contrast, I use 
>>Cygwin every day.)
> 
> 
> I hope you use the MinGW ports at least as much as you use Cygwin.
> Because if those who work on porting tools don't put their own ports
> to some serious use, those tolls will remain, well, less ported.

I do.  In fact, I'm almost always using MinGW hosted toolchains -- but I 
use Cygwin for things like emacs, bash, and all those other familiar GNU 
tools. :-)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Windows support in GDB

[Eli Zaretskii]

> Date: Sun, 01 May 2005 13:06:39 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> CC: me@cgf.cx,  paul@codesourcery.com,  gdb@sourceware.org
> 
> I use Cygwin for things like emacs, bash, and all those other
> familiar GNU tools. :-)

There's a native Windows port of Emacs, FWIW.  It works fine with
MinGW ports of GNU software.

Bash is another matter (although I don't quite understand why there's
no MinGW port of it, since there's an excellent DJGPP port which could
be used as a starting point).  I use an old port of zsh when I really
need a Unixy shell on Windows.

Re: Windows support in GDB

[Kris Warkentin]

Christopher Faylor wrote:

>I haven't asked what the problem is with just using cygwin with gdb.
>I suspect that the standard two problems are:
>
>1) cygwin is "slow" (which really only is an issue for configure/make)
>  
>

Actually, my preliminary compilation benchmarks show a 15-20% increase 
in compilation speed on MinGW versus Cygwin.

>and
>
>2) You can't trivially include your own version of cygwin1.dll with
>a distribution since it could conflict with a version already on
>the system.
>

3) Paths.  This is a HUGE problem because you can't assume that your 
Windows customers are interested in using a Unix style of work flow.  
MinGW supports regular Windows paths without the whole /cygdrive/ 
system.  If you have a pure Windows app interacting with Cygwin tools 
(take Eclipse for example) you wind up putting an awful lot of cruft in 
to deal with pathname conversion.  You can even get problems when your 
debug information in your binary has either Cygwin or Windows paths.

cheers,

Kris

Re: Windows support in GDB

[Christopher Faylor]

On Fri, Apr 29, 2005 at 12:27:13PM -0400, Kris Warkentin wrote:
>Christopher Faylor wrote:
>
>>I haven't asked what the problem is with just using cygwin with gdb.
>>I suspect that the standard two problems are:
>>
>>1) cygwin is "slow" (which really only is an issue for configure/make)
>> 
>Actually, my preliminary compilation benchmarks show a 15-20% increase 
>in compilation speed on MinGW versus Cygwin.

Right!  That's what I meant by "cygwin is slow".

>>2) You can't trivially include your own version of cygwin1.dll with
>>a distribution since it could conflict with a version already on
>>the system.
>>
>
>3) Paths.  This is a HUGE problem because you can't assume that your 
>Windows customers are interested in using a Unix style of work flow.  
>MinGW supports regular Windows paths without the whole /cygdrive/ 
>system.  If you have a pure Windows app interacting with Cygwin tools 
>(take Eclipse for example) you wind up putting an awful lot of cruft in 
>to deal with pathname conversion.  You can even get problems when your 
>debug information in your binary has either Cygwin or Windows paths.

Again, AFAIK, gdb works with native paths.  If it doesn't then getting
it to work with windows paths seems like a lot less pain that getting
it to be 100% functional in native windows.

cgf

Re: Windows support in GDB

[Kris Warkentin]

Christopher Faylor wrote:

>>3) Paths.  This is a HUGE problem because you can't assume that your 
>>Windows customers are interested in using a Unix style of work flow.  
>>MinGW supports regular Windows paths without the whole /cygdrive/ 
>>system.  If you have a pure Windows app interacting with Cygwin tools 
>>(take Eclipse for example) you wind up putting an awful lot of cruft in 
>>to deal with pathname conversion.  You can even get problems when your 
>>debug information in your binary has either Cygwin or Windows paths.
>>    
>>
>
>Again, AFAIK, gdb works with native paths.  If it doesn't then getting
>it to work with windows paths seems like a lot less pain that getting
>it to be 100% functional in native windows.
>

Sometimes yes, sometimes no.  It isn't just an issue of gdb not working 
with native paths because, as you say, it _usually_ does.  It's a 
question of consistency.  If the rest of your toolchain is built with 
MinGW, it makes sense to build everything that way.  At the moment, 
since we're having trouble with gdb on MinGW, we're actually considering 
what you said, making gdb the exception and just shipping it with a 
cygwin1.dll until we can get all the kinks ironed out.  Another 
potential gotcha is that it may not work when run under the MinGW 
environment (as from a bash shell).  I haven't checked this for sure but 
I understand there can be conflicts between msys and cygwin.

One other thing I forgot to mention is memory allocation.  Cygwin 
refuses to allocate the maximum memory available so extremely large 
projects sometimes have trouble, particularily at the link stage.  This 
isn't a problem on MinGW.

cheers,

Kris

Re: Windows support in GDB

[Eli Zaretskii]

> Date: Fri, 29 Apr 2005 12:58:31 -0400
> From: Kris Warkentin <kewarken@qnx.com>
> CC: mark@codesourcery.com,  paul@codesourcery.com,  gdb@sourceware.org
> 
> It isn't just an issue of gdb not working with native paths because,
> as you say, it _usually_ does.  It's a question of consistency.

Indeed.

In fact, any serious use of GDB will almost instantly bump into such a
consistency (or lack thereof) issue.  For example, will the `edit' and
`shell' commands work if I don't have a Cygwin Bash installed and GDB
is configured to invoke that Bash as the shell?

Re: Windows support in GDB

[Christopher Faylor]

On Sun, May 01, 2005 at 10:51:02PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 29 Apr 2005 12:58:31 -0400
>> From: Kris Warkentin <kewarken@qnx.com>
>> CC: mark@codesourcery.com,  paul@codesourcery.com,  gdb@sourceware.org
>> 
>> It isn't just an issue of gdb not working with native paths because,
>> as you say, it _usually_ does.  It's a question of consistency.
>
>Indeed.
>
>In fact, any serious use of GDB will almost instantly bump into such a
>consistency (or lack thereof) issue.  For example, will the `edit' and
>`shell' commands work if I don't have a Cygwin Bash installed and GDB
>is configured to invoke that Bash as the shell?

And, if they don't, what's the solution?  You fix it so they will work.
Presumably, if there is no /bin/sh.exe available, you'd use a fallback.
You could even implement a switch to force cygwin's gdb into "windows
path mode".

Problems like "what happens when there is no cygwin shell available?"
are fixable.  They are likely to be fixable without the necessity of
sprinkling ifdefs all over gdb or even making changes to the configury.
I don't think that they can be used as a justification for a windows
port.

No matter how you slice it, changes to get gdb working on native windows
are at least mildly intrusive.  Maybe compatibility changes to make a
cygwin-based gdb work better would be equally intrusive or time
consuming.  I *suspect* however, that fixing cygwin's gdb to better
handle windows paths is probably a lot less work than what Mark did.  I
think I can say with some assurance that there would be no need to
modify readline at all, for instance.

So, I don't think that any observations about the way that gdb currently
works under cygwin should be considered fodder for why a native windows
port is required.  Mark expended some effort to produce a native windows
port rather than fix any problems that cropped up with cygwin gdb.
That's fine and dandy.  He gave his valid reasons for doing this and it
is solely his perogative.  I don't think we need to search for (fixable)
limitations in cygwin's gdb as a rationale for why a windows port is
needed.

cgf

Re: Windows support in GDB

[Eli Zaretskii]

> Date: Sun, 1 May 2005 17:41:28 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> >In fact, any serious use of GDB will almost instantly bump into such a
> >consistency (or lack thereof) issue.  For example, will the `edit' and
> >`shell' commands work if I don't have a Cygwin Bash installed and GDB
> >is configured to invoke that Bash as the shell?
> 
> And, if they don't, what's the solution?  You fix it so they will work.
> Presumably, if there is no /bin/sh.exe available, you'd use a fallback.
> You could even implement a switch to force cygwin's gdb into "windows
> path mode".

You could do all that and more, but AFAIK that'd be against the
``spirit of Cygwin'', which is to solve all incompatibilities in the
runtime, and leave the application sources more or less intact.  If
you leave the application sources intact, the Unixy shell assumptions,
like the -c switch and redirection syntax, will be hard to solve
inside the library that implements fork/exec or whatever.

> I *suspect* however, that fixing cygwin's gdb to better handle
> windows paths is probably a lot less work than what Mark did.

I actually think the other way around.  But I certainly don't want to
start a Cygwin-yaye-o-nay dispute.

Re: Windows support in GDB

[Christopher Faylor]

On Mon, May 02, 2005 at 10:00:39PM +0300, Eli Zaretskii wrote:
>>Date: Sun, 1 May 2005 17:41:28 -0400
>>From: Christopher Faylor <me@cgf.cx>
>>
>>>In fact, any serious use of GDB will almost instantly bump into such a
>>>consistency (or lack thereof) issue.  For example, will the `edit' and
>>>`shell' commands work if I don't have a Cygwin Bash installed and GDB
>>>is configured to invoke that Bash as the shell?
>>
>>And, if they don't, what's the solution?  You fix it so they will work.
>>Presumably, if there is no /bin/sh.exe available, you'd use a fallback.
>>You could even implement a switch to force cygwin's gdb into "windows
>>path mode".
>
>You could do all that and more, but AFAIK that'd be against the
>``spirit of Cygwin'', which is to solve all incompatibilities in the
>runtime, and leave the application sources more or less intact.

You don't need to worry about the spirit of cygwin.  I am one of the
project leaders for Cygwin and I'm implying that patches to make gdb
more pure "windows-friendly" would be accepted.

gdb already has massive windows-specific accommodations due to the fact
that cygwin doesn't try to emulate a UNIX-like debugger interface.  gdb
already allows 'x:\y' style paths.  I can see why people might want to
use cygwin's gdb as a windows debugger without requiring a full cygwin
installation (if for no other reason than it might be useful for
debugging cygwin itself) so I am saying that I would support the
inclusion of these types of patches.

Perhaps this seems inconsistent for the Cygwin project lead but as the
gdb windows maintainer, I think it makes good sense.

cgf

Re: Windows support in GDB

[Daniel Jacobowitz]

On Fri, Apr 29, 2005 at 12:00:40PM -0400, Christopher Faylor wrote:
> Of course it does build "out of the box" on Windows right now if you
> have cygwin.

Sorry, very bad choice of wording on my part.

> While I am the Windows maintainer for gdb, I have been thinking that
> maybe I might have to step down if it means that I'll have to support a
> Windows configuration for which I have little interest.

That would definitely suck!  If you are uninterested in MinGW support
(perfectly reasonable) then I'd prefer that you clarify your
maintenance to just cover Cygwin.  You do a great job for Cygwin, and
the big reason we've been bugging you about Windows patches is that you
seem to know more about it than we do :-)

> I haven't asked what the problem is with just using cygwin with gdb.
> I suspect that the standard two problems are:
> 
> 1) cygwin is "slow" (which really only is an issue for configure/make)

Our customers have found, I think, that this is true for more than just
shell/fork-heavy loads; it was also true for GCC.  Treat this as
hearsay, though.  I've never measured it myself.

> and
> 
> 2) You can't trivially include your own version of cygwin1.dll with
> a distribution since it could conflict with a version already on
> the system.
> 
> I can't do much to address 1 but 2 is not an insurmountable problem.

Sure.  But I somewhat approve of mingw-only installations because of
the number of times I've installed a vendor's carelessly packaged
cygwin tools and had them trash my existing Cygwin installation.  I do
use Cygwin, so that ticks me off :-)  It's not an insurmountable
problem but people seem to have a great deal of trouble surmounting it.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Windows support in GDB

[Christopher Faylor]

On Fri, Apr 29, 2005 at 12:45:08PM -0400, Daniel Jacobowitz wrote:
>On Fri, Apr 29, 2005 at 12:00:40PM -0400, Christopher Faylor wrote:
>> Of course it does build "out of the box" on Windows right now if you
>> have cygwin.
>
>Sorry, very bad choice of wording on my part.
>
>> While I am the Windows maintainer for gdb, I have been thinking that
>> maybe I might have to step down if it means that I'll have to support a
>> Windows configuration for which I have little interest.
>
>That would definitely suck!  If you are uninterested in MinGW support
>(perfectly reasonable) then I'd prefer that you clarify your
>maintenance to just cover Cygwin.  You do a great job for Cygwin, and
>the big reason we've been bugging you about Windows patches is that you
>seem to know more about it than we do :-)

Hopefully, I do know a lot about Windows programming (unfortunately).
Maintaining cygwin means knowing a lot about Windows and UNIX.

I guess the thought of coming up with a solution in cygwin that has to
be dealt with in a different fashion in gdb/mingw is a little daunting.
However, I'm not going anywhere.  I'm calmed down now.  :-)

>> I haven't asked what the problem is with just using cygwin with gdb.
>> I suspect that the standard two problems are:
>> 
>> 1) cygwin is "slow" (which really only is an issue for configure/make)
>
>Our customers have found, I think, that this is true for more than just
>shell/fork-heavy loads; it was also true for GCC.  Treat this as
>hearsay, though.  I've never measured it myself.

It seems like my point wasn't clear here.  I know that cygwin is slow.

I'm talking about just using gdb for debugging.  If your customers are
routinely rebuilding gdb, then the slowness would be an issue.  If they
are not, then unless cygwin was adding some kind of 10x slowdown to
debugging, I don't see why it would be an issue.

>> 2) You can't trivially include your own version of cygwin1.dll with
>> a distribution since it could conflict with a version already on
>> the system.
>> 
>> I can't do much to address 1 but 2 is not an insurmountable problem.
>
>Sure.  But I somewhat approve of mingw-only installations because of
>the number of times I've installed a vendor's carelessly packaged
>cygwin tools and had them trash my existing Cygwin installation.  I do
>use Cygwin, so that ticks me off :-)  It's not an insurmountable
>problem but people seem to have a great deal of trouble surmounting it.

No argument there.  It is a continual source of frustration.

cgf

Re: Windows support in GDB

[Daniel Jacobowitz]

On Fri, Apr 29, 2005 at 01:16:31PM -0400, Christopher Faylor wrote:
> It seems like my point wasn't clear here.  I know that cygwin is slow.
> 
> I'm talking about just using gdb for debugging.  If your customers are
> routinely rebuilding gdb, then the slowness would be an issue.  If they
> are not, then unless cygwin was adding some kind of 10x slowdown to
> debugging, I don't see why it would be an issue.

OK, I see your point.  I think we're talking past each other, though -
this comes back to Kris's point about consistency.  Shipping a mingw
GCC and a cygwin GDB is error-prone, especially if we otherwise do not
need the cygwin DLL.

Actually, there are a number of places where GDB's performance does
matter.  It's just not as constant and browbeaten an issue as for GCC
:-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Windows support in GDB

[Christopher Faylor]

On Fri, Apr 29, 2005 at 01:57:45PM -0400, Daniel Jacobowitz wrote:
>On Fri, Apr 29, 2005 at 01:16:31PM -0400, Christopher Faylor wrote:
>>It seems like my point wasn't clear here.  I know that cygwin is slow.
>>
>>I'm talking about just using gdb for debugging.  If your customers are
>>routinely rebuilding gdb, then the slowness would be an issue.  If they
>>are not, then unless cygwin was adding some kind of 10x slowdown to
>>debugging, I don't see why it would be an issue.
>
>OK, I see your point.  I think we're talking past each other, though -
>this comes back to Kris's point about consistency.  Shipping a mingw
>GCC and a cygwin GDB is error-prone, especially if we otherwise do not
>need the cygwin DLL.

I don't see why this is an issue.  It would take a little bit of work to
make sure you didn't stomp on an existing cygwin installation but
putting a cygwin1.dll in the same directory as gdb.exe is a pretty
time-tested way of releasing packages on Windows.  Many packages release
executables + dlls.

Cygwin is problematic because it is constantly evolving and adding new
features and, so, there will be issues if you try to use an old DLL with
a newer binary but, again, this is not an insurmountable problem.

cgf

Re: Windows support in GDB

[Daniel Jacobowitz]

On Fri, Apr 29, 2005 at 02:59:56PM -0400, Christopher Faylor wrote:
> On Fri, Apr 29, 2005 at 01:57:45PM -0400, Daniel Jacobowitz wrote:
> >On Fri, Apr 29, 2005 at 01:16:31PM -0400, Christopher Faylor wrote:
> >>It seems like my point wasn't clear here.  I know that cygwin is slow.
> >>
> >>I'm talking about just using gdb for debugging.  If your customers are
> >>routinely rebuilding gdb, then the slowness would be an issue.  If they
> >>are not, then unless cygwin was adding some kind of 10x slowdown to
> >>debugging, I don't see why it would be an issue.
> >
> >OK, I see your point.  I think we're talking past each other, though -
> >this comes back to Kris's point about consistency.  Shipping a mingw
> >GCC and a cygwin GDB is error-prone, especially if we otherwise do not
> >need the cygwin DLL.
> 
> I don't see why this is an issue.  It would take a little bit of work to
> make sure you didn't stomp on an existing cygwin installation but
> putting a cygwin1.dll in the same directory as gdb.exe is a pretty
> time-tested way of releasing packages on Windows.  Many packages release
> executables + dlls.
> 
> Cygwin is problematic because it is constantly evolving and adding new
> features and, so, there will be issues if you try to use an old DLL with
> a newer binary but, again, this is not an insurmountable problem.

I'm afraid I don't know any more about it than I've already said.  I
don't have a lot of experience with Cygwin.  One problem I seem to
recall is that you can't put the new binary in your $PATH and use it
from Cygwin without removing the second copy of the DLL.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Windows support in GDB

[Christopher Faylor]

On Fri, Apr 29, 2005 at 03:07:55PM -0400, Daniel Jacobowitz wrote:
>On Fri, Apr 29, 2005 at 02:59:56PM -0400, Christopher Faylor wrote:
>>On Fri, Apr 29, 2005 at 01:57:45PM -0400, Daniel Jacobowitz wrote:
>>>On Fri, Apr 29, 2005 at 01:16:31PM -0400, Christopher Faylor wrote:
>>>>It seems like my point wasn't clear here.  I know that cygwin is slow.
>>>>
>>>>I'm talking about just using gdb for debugging.  If your customers are
>>>>routinely rebuilding gdb, then the slowness would be an issue.  If they
>>>>are not, then unless cygwin was adding some kind of 10x slowdown to
>>>>debugging, I don't see why it would be an issue.
>>>
>>>OK, I see your point.  I think we're talking past each other, though -
>>>this comes back to Kris's point about consistency.  Shipping a mingw
>>>GCC and a cygwin GDB is error-prone, especially if we otherwise do not
>>>need the cygwin DLL.
>>
>>I don't see why this is an issue.  It would take a little bit of work
>>to make sure you didn't stomp on an existing cygwin installation but
>>putting a cygwin1.dll in the same directory as gdb.exe is a pretty
>>time-tested way of releasing packages on Windows.  Many packages
>>release executables + dlls.
>>
>>Cygwin is problematic because it is constantly evolving and adding new
>>features and, so, there will be issues if you try to use an old DLL
>>with a newer binary but, again, this is not an insurmountable problem.
>
>I'm afraid I don't know any more about it than I've already said.  I
>don't have a lot of experience with Cygwin.  One problem I seem to
>recall is that you can't put the new binary in your $PATH and use it
>from Cygwin without removing the second copy of the DLL.

Yes.  You're right.  There are issues there.  You'd need to add some
intelligence into an installer to guard against the dreaded multiple
DLL problem.

However, I guess what I'm winnowing out here is that there may be some
decisions that are partly based on (and I really don't use this term as
a pejorative) ignorance of the way things work rather than a need for a
windows port.

That does not mean that a windows port is not desirable or useful or
wonderful so I'll shut up now.  It's just an academic point and
obviously people can spend their time however they want.  If anyone
wants to talk about cygwin DLL issues they are welcome to send me
personal email or to use the cygwin list.

cgf

Re: Windows support in GDB

[Andrew Cagney]

> 
>>non-POSIX nature of Windows, which sets its quit far apart from the
>>traditional Unix-like systems that have been converging towards POSIX
>>for quite some time now.  This means that we really need to have some
>>commitment from the Windows user community for maintaining this stuff.
>>Otherwise this will become another MetroWerks disaster.
> 
> 
> I don't know what you're referring to.  Are you thinking of the HP
> merge?

Mark is correct (and kudos for remembering it, its one of those things 
I'd rather forget).  Look for files named *mpw*, and macros named MPW, 
in old sources (oh and also the bitter complaints that ensued as I went 
through the slow careful process of removing it).

Re: Windows support in GDB

[Daniel Jacobowitz]

On Mon, May 02, 2005 at 11:39:31AM -0400, Andrew Cagney wrote:
> >
> >>non-POSIX nature of Windows, which sets its quit far apart from the
> >>traditional Unix-like systems that have been converging towards POSIX
> >>for quite some time now.  This means that we really need to have some
> >>commitment from the Windows user community for maintaining this stuff.
> >>Otherwise this will become another MetroWerks disaster.
> >
> >
> >I don't know what you're referring to.  Are you thinking of the HP
> >merge?
> 
> Mark is correct (and kudos for remembering it, its one of those things 
> I'd rather forget).  Look for files named *mpw*, and macros named MPW, 
> in old sources (oh and also the bitter complaints that ensued as I went 
> through the slow careful process of removing it).

OK, now I'm really curious!  Could you explain the connection to
MetroWerks?  I've used MPW; it stood for Macintosh Programmer's Workshop
at the time, and according to Apple's web pages it still does.

MPW does make a lot more sense in this context, though.  Thanks for the
pointer.  It was certainly a ... unique environment.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Windows support in GDB

[Kris Warkentin]

At QNX we're transitioning our Windows SDK from Cygwin to MinGW so these 
patches are very useful for us.  I would expect that in the long term it 
will be in our best interest to make sure that this stuff continues 
working.  Of course, I'm just a developer and don't make policy but at 
least there's one other company that will want to keep this stuff going.

cheers,

Kris

Mark Kettenis wrote:

>Guys, I'm getting a bit of an uneasy feeling here.  It may be that I'm
>getting the wrong impression here, but I've seen quite a bit more
>Windows-related patches than I had in mind when Mark started submitted
>his first patches and said they were fairly limited and mostly some
>configure bits.  The problem here is that they mostly concern the
>non-POSIX nature of Windows, which sets its quit far apart from the
>traditional Unix-like systems that have been converging towards POSIX
>for quite some time now.  This means that we really need to have some
>commitment from the Windows user community for maintaining this stuff.
>Otherwise this will become another MetroWerks disaster.
>
>It's fairly obvious that this development is coming from CodeSourcery.
>There's nothing wrong with that, but I'd like to ask CodeSourcery what
>their commitment to maintaining this new code is.  In the past we have
>seen quite a few contributions from embedded sofware companies.  In
>many cases these contributions were apparently done as contract work,
>and after the work was completed the code was never touched again.
>Can CodeSourcery gives some clarification on this matter?
>
>Mark
>  
>

Re: Windows support in GDB

[Mark Mitchell]

Mark Kettenis wrote:
> Guys, I'm getting a bit of an uneasy feeling here.  It may be that I'm
> getting the wrong impression here, but I've seen quite a bit more
> Windows-related patches than I had in mind when Mark started submitted
> his first patches and said they were fairly limited and mostly some
> configure bits. 

I think that characterization was pretty accurate: most of the changes 
have been to configure bits -- I've littered #ifdef HAVE_FOO around the 
sources in more places, for the most part.  I think that's a pretty 
minimal intrusion; realistically, there's a lot of that anyhow in GDB, 
as even the various UNIX variants don't all define the same set of 
signals, etc.  In a couple of cases, stuff has gone into libiberty.

The other changes in GDB were the cleanup of ser-unix.c to create 
ser-base.c (which I think actually made the code cleaner), and the 
gdb_select function, which has the same API as POSIX.

I have no more changes for GDB proper, except a change to safe_strerror 
that's been rejected.  I'll either clean that up in some acceptable way, 
or abandon it.  All I've got left are readline patches.

> The problem here is that they mostly concern the
> non-POSIX nature of Windows

GCC (and the GNU project in general, I think) have taken the attitude 
that while free operating systems are definitely the primary target, 
it's OK to support other systems, including Windows, so that people who 
uses those systems have the benefit of GNU software, and so that they 
can see that it might be worthwhile switching to a GNU system.

Of course, it takes some work to support Windows, but -- thanks to your 
careful reviews -- the amount of impact on POSIX programmers from my 
patches is pretty nearly zero.  They might break Windows support, but 
they're not likely to get confused by the Windows bits, becuase they're 
so clearly segregated.

> It's fairly obvious that this development is coming from CodeSourcery.
> There's nothing wrong with that, but I'd like to ask CodeSourcery what
> their commitment to maintaining this new code is. 

We have customers that want this functionality.  We didn't do this work 
on spec from a single company; we did it because we have multiple 
customers who wanted it.  We distribute toolchains that use it, and have 
ongoing contracts to continue delivering such toolchains. We will be 
including this functionality in our nightly builds, once the FSF version 
works.

I'd also note that there's a very active MinGW community out there. 
Part of the reason that their GDB support is complete separate is that 
they've found it hard to get their patches contributed and accepted. 
I'd expect that once basic support is available, you'd see activity from 
that direction as well.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Windows support in GDB

[Christopher Faylor]

On Fri, Apr 29, 2005 at 09:05:05AM -0700, Mark Mitchell wrote:
>I'd also note that there's a very active MinGW community out there. 
>Part of the reason that their GDB support is complete separate is that 
>they've found it hard to get their patches contributed and accepted. 

I've been suggesting to the MinGW community that they submit patches for
some time.  I don't recall anyone actually trying to do so.

cgf

Re: Windows support in GDB

[Mark Mitchell]

Christopher Faylor wrote:
> On Fri, Apr 29, 2005 at 09:05:05AM -0700, Mark Mitchell wrote:
> 
>>I'd also note that there's a very active MinGW community out there. 
>>Part of the reason that their GDB support is complete separate is that 
>>they've found it hard to get their patches contributed and accepted. 
> 
> 
> I've been suggesting to the MinGW community that they submit patches for
> some time.  I don't recall anyone actually trying to do so.

I didn't mean to imply that; sorry.  My conversations with a (small, 
possibly non-representative) subset, just indicated that they would have 
liked to submit patches, but didn't think they would be accepted, didn't 
know how to submit them appropriately, etc.  I have gotten some mail 
from people indicating that they're happy to see the patches going in.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304