This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

OutputDebugString()


Hello, I am just trying to understand how GDB is able to receice
messages sent with the windows API call OutputDebugString() while
another application on the system is already registered for these
messages and running and capturing messages.

>From what I have read here:
http://unixwiz.net/techtips/outputdebugstring.html there are some
system-wide global resources involved that can be held by only one one
application at a time. From what I understand if DebugView or any
other such application is already running on the system then any
attempts by GDB to create this shared memory segment and register for
the events should fail because all this is a system-wide. If I
understand this correctly then GDB should not even try to register for
debug messages if another application is already holding these
objects.

What I don't understand is how GDB can capture the debug messages even
if DebugView is already running on this system, capture only the
messages that belong to the debugged application and let DebugView
continue to capture anything else. At least with my limited knowledge
about how OutputDebugString() works I could only explain this by
assuming that GDB will either:

* silently replace and eat the whole api function call and never let
windows even see the message
* use some other hook in the windows API that allows to capture debug messages.

the reason I am trying to understand this is I have been using
OutputDebugString() successfully for debugging all kinds of
applications, I basically use it whenever I cannot or am not allowed
to print to stdout. Now I'm developing something with Lazarus/FPC and
it uses GDB as the debugger and the IDE by default runs the
application through GDB. This is fine for single-stepping the
application and having watch expressions but the drawdown is that my
debug messages are now buried under *tons* of other GDB output.

If my above assumptions are true then GDB must do some serious
trickery to even be able to catch these messages, but then it
basically treats them like garbage by labeling them as "warning" and
then throwing them away without letting them reach their initial
destination, so the IDE has no chance to separately filter and display
these messages.

It would be nice to have a command line switch that will disable the
catching of these messages and just let them go through or at least
re-insert them unmodified into the global windows message queue where
they initially belong by letting GDB *itself* call OutputDebugString()
with every intercepted message. Also it would be nice if they would
not labeled as "warning" but as something different so one could
easily grep these messages out of the GDB output

Bernd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]