[PATCH] deferred trace

Alexandre Julliard julliard at winehq.com
Wed Mar 14 17:20:39 CST 2001


"Rob Farnum" <rfarnum at mindspring.com> writes:

> I am not exactly sure what you mean by this.  Do you mean to put the
> code that would be in the dll, into the debugger, or to extend the
> debugger in such a way that it can load dll's to enhance its
> functionality, or something else?

I mean that the code that would have been in the dll and loaded into
Wine should be in the debugger instead. So for instance, instead of
having a magic key (or X message) to switch tracing on, you'd have a
debugger command 'set tracing on' that would poke into the Wine
address space to do it. Since you can read/write memory, call
functions (I think it's broken now but should be easy to fix),
etc. from the debugger you can do everything from here and avoid the
need to have any debugging code running inside the Wine process.

> This would bypass the objection of intercepting a key, like F12, and
> using it to generate a window list dump, and replace it with a
> mechanism that uses the debugger own builtin functions to do that.

Yes, exactly.

> I think it is desirable to use as much of the existing debugger
> functionality as possible, and to add an "elaborate mechanism in the
> debugger" that allows it to be dynamically extended in
> functionality.

It would certainly be possible to load dlls inside the debugger itself
to extend it; though maybe simply loading a batch file containing
debugger commands may allow to do a lot of things already without
requiring compiling new code.

-- 
Alexandre Julliard
julliard at winehq.com




More information about the wine-devel mailing list