Re: Support of gdb for Windows 64 native systems

Pedro Alves
2007-10-17T22:00:44Z

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