Original commit message from CVS:
Changes made to the DEBUG system. New header file gstdebug.h holds the
stuff to keep it out of gst.h's hair. DEBUG prints out the process id,
cothread id, source filename and line number. Two new macros DEBUG_ENTER
and DEBUG_LEAVE are used to show the entry and exit of a given function.
This eventually might be used to construct call trace graphs, even taking
cothreads into account. This would be quite useful in visualizing the
scheduling mechanism.
Minor changes to various debug messages.
Also sitting in gstdebug.h is a prototypical DEBUG_ENTER that's capable of
performing DEBUG_LEAVE automatically. It does this by utilizing a
little-known GCC extension that allows one to call a function with the
same parameters as the current function. The macro uses this to basically
call itself. A boolean is used to ensure that when it calls itself it
actually runs the body of the function. In the meantime it prints stuff
out before and after the real function, as well as constructing a
debugging string. This can be used eventually to provide call-wide data
on the DEBUG lines, instead of having to replicate data on each call to
DEBUG. More research is needed into how this would most cleanly be fit
into some other chunk of code, like GStreamer (I think of this DEBUG trick
as a separate project, sorta).
Unfortunately, the aforementioned DEBUG trick interacts quite poorly with
cothreads. Almost any time it's used in a function that has anything
remotely to do with a cothread context (as in, it runs in one), a segfault
results from the __builtin_apply call, which is the heart of the whole
thing. If someone who really knows assembly could analyze the resulting
code to see what's really going on, we might find a way to fix either the
macro or the cothreads (I'm thinking that there's something we missed in
constructing the cothreads themselves) so this works in all cases.
In the meantime, please insert both DEBUG_ENTER and DEBUG_LEAVE in your
functions. Be sure to put DEBUG_ENTER after your variable declarations
and before any functional code, not to put the function name in any DEBUG
strings (it's already there, trust me), and put a DEBUG_LEAVE if you care
enough.
Changes are going to happen in the way DEBUGs and other printouts occur,
so stay tuned.
29d567ba23