Eric Pouech eric.pouech@wanadoo.fr writes:
but we also need to force console creation on jit debugging...
Why would you want to force it? Why not let the user decide? Users who want a new console can specify the debugger as "wineconsole winedbg" in their registry.
"Alexandre" == Alexandre Julliard julliard@winehq.com writes:
Alexandre> Eric Pouech eric.pouech@wanadoo.fr writes: >> but we also need to force console creation on jit debugging...
Alexandre> Why would you want to force it? Why not let the user decide? Alexandre> Users who want a new console can specify the debugger as Alexandre> "wineconsole winedbg" in their registry.
What happens in this context?
User starts Program A. Program A starts Program B Program A terminates normal Program B crashes.
On my setup, the debugger starts in that circumstance, loads all dlls and then immediate terminates, as the there is no xterm connected to Program B any more.
Bye
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de writes:
What happens in this context?
User starts Program A. Program A starts Program B Program A terminates normal Program B crashes.
On my setup, the debugger starts in that circumstance, loads all dlls and then immediate terminates, as the there is no xterm connected to Program B any more.
Well in that case you have to use a separate console. It would be nice to have the possibility to detect that the Unix tty is not available and automatically pop up a console in that case; but unconditionally creating a console is wrong, there are many cases where you don't want that.
Well in that case you have to use a separate console. It would be nice to have the possibility to detect that the Unix tty is not available and automatically pop up a console in that case; but unconditionally creating a console is wrong, there are many cases where you don't want that.
well, if you really want to do that, you have to decide on what you want winedbg to use as input / output streams : 1/ the unix stdin / stdout that winedbg will get upon startup => those would be inherited from the offending app (of course those streams could be redirected to something else than the controlling console) 2/ the current windows-console (if any) of the offending process
note that of course 1/ and 2/ could happen at the same time
the nasty thing, for example, for implementing one would be to do something like (whithout error handling): if in jit mode { if (!isatty(0) || !isatty(1)) { /* restart debugger so that it'll get the right console hooked to 0/1 */ the steps here are: create a new event relaunch dbg with something like * wineconsole -- %argv[0] --pid=<cur_pid> --evt=<new event> wait on <new event> signal old event terminate this process, now that the child has attached } }
which I find particulary ugly
A+
-
Alexandre Julliard -
Eric Pouech -
Uwe Bonnes