Re: [PATCH] deferred trace

[Alexandre Julliard]

"Rob Farnum"  writes:
> My current design is to have yet another dll that would register
> itself as the handler for this XClientMessage, so that on reciept of
> the XClientMessage, it is simply passed to this new dll.  This dll
> would implement whatever application specific debugging tools I
> need, with only the bare minimum of support from wine needed.  Since
> the wine debugger already has quite a bit of the functionality that
> is needed, it might be interesting if this method could be used to
> effectively open a pipe and drive the wine debugger externally.

What you should rather do IMO is to put your dll inside the debugger,
and have the debugger drive Wine instead of the other way around. Then
you can add all kinds of elaborate mechanisms in the debugger, and do
anything you want without needing any cooperation from the running
Wine process.

[PATCH] deferred trace

[Rob Farnum]

Alexandre Julliard  wrote...
> What you should rather do IMO is to put your dll inside the debugger,

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?
> and have the debugger drive Wine instead of the other way around. Then

My intention was not to have wine drive the debugger, but to allow the
debugger
to be driven by effectively hooking into yylex and feeding it externally by
a
separate application.  I am not interested in driving wine, I am interested
in
getting state information from wine in as least an invasive way as possible.

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.
> you can add all kinds of elaborate mechanisms in the debugger, and do
> anything you want without needing any cooperation from the running
> Wine process.

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.

If I have built debugging instrumentation into a dll, I would prefer not to
be required to
have the debugger and wine be linked to it at compile time, but be able to
bind to it at
run time.  The idea is to be able to extend the language of the debugger to
dynamically
handle application specific instrumentation.  Basically, I need the ability
of gdb to 'call'
an external function that the wine debugger does not have prior knowledge
of.

With these two capabilities, externally feeding the debugger commands by a
separate
application to a currently running wine application and being able to call
any function
that the wine debugger can resolve, it is possible to meet the needs that
have been expressed.