Ove Kaaven ovehk@ping.uio.no writes:
I assume Alexandre isn't going to like some of the stuff in here, but I suppose it's up to him whether to take it or leave it...
How did you guess I wouldn't like it? ;-)
Actually I think it's a neat hack, but it doesn't belong in the server at all. You should be able to do the same thing as a client-side process using the Win32 debugging API. It could be either a stand-alone Winelib app, or a special mode inside winedbg so that you can reuse some of the code in there.
On 9 May 2001, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
I assume Alexandre isn't going to like some of the stuff in here, but I suppose it's up to him whether to take it or leave it...
How did you guess I wouldn't like it? ;-)
Actually I think it's a neat hack, but it doesn't belong in the server at all. You should be able to do the same thing as a client-side process using the Win32 debugging API. It could be either a stand-alone Winelib app, or a special mode inside winedbg so that you can reuse some of the code in there.
One big problem is that when GDB is attached, it must immediately be known exactly which process to attach to. If the server allocates one socket per process and prints out its port when the process starts, it's easy for the user to choose one, but it's harder for a client process to know. I can also attach and detach gdb at will (if I detach gdb in some exception, winedbg even launches as normal)... winedbg can't, at least nobody knows how to attach winedbg to a running process.
Anyone is free to migrate my code to winedbg or whatever if they think they can get around these issues, of course, but I don't plan to spend more time on this (that's why I submitted it).
Might be a good (and very useful) job for a new developer, though. Any takers?
winedbg can't, at least nobody knows how to attach winedbg to a running process.
well, winedbg can... and now everybody *SHOULD* know
start winedbg without any argument on commande line then, use command walk process
you'll get a list of running processes using the command attach <pid>
really attaches to the running process
the only drawback of the method (compared to gdb interface) is that the Win32 API doesn't allow to detach the debugger from a running process the only issue is to kill the debuggee (or the debugger)
Anyone is free to migrate my code to winedbg or whatever if they think they can get around these issues, of course, but I don't plan to spend more time on this (that's why I submitted it).
me neither for the time being
A+
-
Alexandre Julliard -
eric pouech -
Ove Kaaven