Support of gdb for Windows 64 native systems

[Pedro Alves]

Joel Brobecker write:
>>>> I will double-check this when I get a chance, but I think the current
>>>> patches should provide relatively complete support. From what I could
>>>> tell, the "attach" feature might not be working (apparently, we need
>>>> to define the "ATTACH_NO_WAIT" macro), and we have to implement IO
>>>> redirection / process creation through a shell. I think these are
>>>> the only two major features that we should be missing.
>> Attaching already works nicelly.
> 
> Since you've played with the resulting debugger, how would you
> categorize the current support? I think it's good enough for
> a NEWS entry already.
> 

Admitelly, I didn't didn't do anything with it besides playing with
it, no serious debugging.
I didn't notice anything lacking, so for me it's good enough.
I quickly tried running the testsuite on it, but for some reason
it refused to work.  So I tried unload.exp manually, and confirmed
that I could step into a dll.

> Do you know of anything else that's missing ...

No, my itch is gone for now :) (but it may come back).

> ... except using a shell
> to do the process creation (which will also allow us to do IO
> redirection)?
> 

I don't think talking about a (unix) shell in a native
Windows gdb makes sense, and I don't know if running through
'cmd /c' has the wanted effect.

There's these 'HANDLE hStdInput, hStdOutput, hStdError' in
STARTUPINFO which may be passed into the CreateProcess call to
redirect io.  Yet another way is to use GetStdHandle/SetStdHandle
much like one uses dup2 on unix.  In both these alternatives
we'll have to do args processing (<,>, etc) ourselves.

But, is this considered a basic feature?  I seldom use it myself.
I don't think it is a show stopper.

Cheers,
Pedro Alves