Debug ops?
Dan Sugalski
help debug parrot code, but before I did I figured I'd better throw
it out to the list for some debugging. (This seems like something
which could be of good general use, and as such I'd like to hash it
out, do it once, and do it right)
As I've been writing library code in pir, I'm finding I've got a
*lot* of commented-out printerr sections, as well as a fair amount of
intermediate code to generate the data to be printed. What would be
useful would be a relatively fast and simple way to leave these in
and just skip over them, or have them not execute. As such I'm
thinking we could use:
dprinterr [PISN]x - Like printerr, but only when running in debug mode
ifdebug label - If debug's on, branch to label
unlessdebug label - branch to label unless debugging's on
debugbsr label - do a bsr to the label if debugging's on
As well as making the current debug status part of the interpreter
info section which can be queried and branched on as needed. I can
certainly see skipping the if/unlessdebug stuff, though the print
only if debugging would make the code a lot cleaner, such as it is.
(I'm also thinking that a conditional bsr would be useful, but I'm
not sure it'd be useful *enough*) If it'd make the JIT unhappy to
have more branching ops they can be left out.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Kj
> I'm considering adding in some new ops and a command-line switch to
> help debug parrot code, but before I did I figured I'd better throw it
> out to the list for some debugging. (This seems like something which
> could be of good general use, and as such I'd like to hash it out, do
> it once, and do it right)
>
> As I've been writing library code in pir, I'm finding I've got a *lot*
> of commented-out printerr sections, as well as a fair amount of
> intermediate code to generate the data to be printed. What would be
> useful would be a relatively fast and simple way to leave these in and
> just skip over them, or have them not execute. As such I'm thinking we
> could use:
>
> dprinterr [PISN]x - Like printerr, but only when running in debug mode
> ifdebug label - If debug's on, branch to label
> unlessdebug label - branch to label unless debugging's on
> debugbsr label - do a bsr to the label if debugging's on
>
> As well as making the current debug status part of the interpreter
> info section which can be queried and branched on as needed. I can
> certainly see skipping the if/unlessdebug stuff, though the print only
> if debugging would make the code a lot cleaner, such as it is. (I'm
> also thinking that a conditional bsr would be useful, but I'm not sure
> it'd be useful *enough*) If it'd make the JIT unhappy to have more
> branching ops they can be left out.
Maybe a bit off-topic (as it concerns pir syntax), but wouldn't it be
usefull if we had multi-line comments?
I find myself commenting out line after line quite some time, so if that
could
be done by only inserting 2 tokens (start/end comment), that would be great.
Just an idea.
Klaas-Jan
Timm Murray
> Dan Sugalski wrote:
> > I'm considering adding in some new ops and a command-line switch to help
> > debug parrot code, but before I did I figured I'd better throw it out to
> > the list for some debugging. (This seems like something which could be
> > of good general use, and as such I'd like to hash it out, do it once,
> > and do it right)
>
<snip>
There is a Perl-based version of log4j, which would fit into Parrot much
better than Java would:
http://search.cpan.org/~mschilli/Log-Log4perl-0.48/lib/Log/Log4perl.pm
Leopold Toetsch
> Maybe a bit off-topic (as it concerns pir syntax), but wouldn't it be
> usefull if we had multi-line comments?
=for comment
=cut
leo
Leopold Toetsch
> dprinterr [PISN]x - Like printerr, but only when running in debug mode
> ifdebug label - If debug's on, branch to label
> unlessdebug label - branch to label unless debugging's on
> debugbsr label - do a bsr to the label if debugging's on
Ok.
> (I'm also thinking that a conditional bsr would be useful, but I'm
> not sure it'd be useful *enough*) If it'd make the JIT unhappy to
> have more branching ops they can be left out.
C<ifdebug label> and C<unlessdebug label> are JITtable with not much
effort. The conditional bsr needs a bit more. What about:
.macro debugbsr(bsr_sub)
.local label skip
unlessdebug .skip
bsr .bsr_sub
.skip:
.endm
Usage is then
.debugbsr(the_sub)
(Untested)
By redefining the macro you can get rid of it too.
leo
Dan Sugalski
We could, certainly. I'd not given it a whole lot of thought -- I'm
used to assembly languages having only single-line comments. (And, I
admit, I tend to use emacs' comment-region feature to make life
easier) I'm not sure it's worth much effort, but on the other hand
I've nothing against it either.
Uri Guttman
DS> dprinterr [PISN]x - Like printerr, but only when running in debug mode
DS> ifdebug label - If debug's on, branch to label
DS> unlessdebug label - branch to label unless debugging's on
DS> debugbsr label - do a bsr to the label if debugging's on
DS> As well as making the current debug status part of the interpreter
DS> info section which can be queried and branched on as needed. I can
DS> certainly see skipping the if/unlessdebug stuff, though the print
DS> only if debugging would make the code a lot cleaner, such as it
DS> is. (I'm also thinking that a conditional bsr would be useful, but
DS> I'm not sure it'd be useful *enough*) If it'd make the JIT unhappy
DS> to have more branching ops they can be left out.
some random comments:
it looks like you have only one debug flag/level. would multiple
flags/levels be useful or hard to add? it would mean adding another arg
to the debug ops. if given no arg, it would default to level 1/flag 1 or
something like that.
what about a compile time (byte code generation? JIT?) option to
optimize out debug code so it doesn't even get run if not enabled?
do we need JIT support for debugging? you can debug in bytecode and then
JIT for speed. this assumes, of course, that the JITing is correct.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Dan Sugalski
> >>>>> "DS" == Dan Sugalski <d...@sidhe.org> writes:
>
> DS> dprinterr [PISN]x - Like printerr, but only when running in debug mode
> DS> ifdebug label - If debug's on, branch to label
> DS> unlessdebug label - branch to label unless debugging's on
> DS> debugbsr label - do a bsr to the label if debugging's on
>
> DS> As well as making the current debug status part of the interpreter
> DS> info section which can be queried and branched on as needed. I can
> DS> certainly see skipping the if/unlessdebug stuff, though the print
> DS> only if debugging would make the code a lot cleaner, such as it
> DS> is. (I'm also thinking that a conditional bsr would be useful, but
> DS> I'm not sure it'd be useful *enough*) If it'd make the JIT unhappy
> DS> to have more branching ops they can be left out.
>
>some random comments:
>
>it looks like you have only one debug flag/level. would multiple
>flags/levels be useful or hard to add? it would mean adding another arg
>to the debug ops. if given no arg, it would default to level 1/flag 1 or
>something like that.
Dunno. I generally either want it on or off. The logging stuff that
Sam noted looks interesting, though.
>what about a compile time (byte code generation? JIT?) option to
>optimize out debug code so it doesn't even get run if not enabled?
That's not what I'm looking for, in part because at compile time I
don't know if I need the debug stuff executed. Most of the code's in
library modules which are precompiled and hanging around. I want
their debug code in there, but only enabled when I need it.
(Basically I run through a bunch of programs and when one or more
fail I want to rerun and kick in debugging)
>do we need JIT support for debugging? you can debug in bytecode and then
>JIT for speed. this assumes, of course, that the JITing is correct.
Leo says no problem, so that's fine. This stuff's not really for
debugging parrot, more for debugging pasm/pir code.
Matt Fowles
My work has a really useful macro trace that expands as followed
#define trace(name_str, format_str, ...); \
{ \
static bool traceMe = DO_WE_TRACE_THIS(name_str); \
if(traceMe) { \
DO_THE_TRACING(name_str, format_str, __VA_ARGS__); \
} \
}
Where DO_WE_TRACE_THIS can use whatever heirachical naming
convenctions one wants and DO_THE_TRACING can be anything from printf
to kernel logging depending on what one wants.
We actually leave these in the release versions of our product, but
one could easily filter them out with a different macro. I know that
it doesn't allow you to change dynamically, but it does provide a fair
amount of speed for the not tracing case, as the condition is only
checked once.
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
Dan Sugalski
>Dan Sugalski wrote:
>
>>help debug parrot code, but before I did I figured I'd better throw
>>it out to the list for some debugging. (This seems like something
>>which could be of good general use, and as such I'd like to hash it
>>out, do it once, and do it right)
>
>debugging output placed deep inside parrot is likely to drown out
>any application level debugging output.
Fair enough. I've got to admit I tend to use really primitive tools
-- gdb's nice, and DEC^WCompaq^WHP has a really nice GUI debugger...
and I do most of my work with scattered print statements. :)
>[Snipped description]
>If all this seems too abstract or complicated, remember that it can
>be implemented incrementally, and as needed.
But, but, but... consider all the bikesheds that will remain
unpainted if we do this?
Which, I suppose, is an *excellent* reason to do it, so lets. This
also means we should hash out module building, installation paths,
versioning, and generic module loading, which sounds like fun.
>If logger methods map to a vtable, performance when logging is
>disabled should not be a significant concern.
>
>I'm willing to help.
Cool.
Dan Sugalski
>On 04/11/01 11:17 -0500, Sam Ruby wrote:
>> But either at startup or dynamically, individual loggers can be
>> enabled to start (or stop) outputing messages that exceed a given
>> threshhold (debug, info, warn, error, fatal).
>
>One thing that I really miss in this kind of logging framework is to
>switch *at any time* (ie, not only when creating the logging stuff) the
>threshold.
>
>This allows for example to run all your code with fatal threshold and
>then, when running into sub-that-is-supposed-to-be-all-bugged, you just
>activate debug level, and return to fatal after leaving it. This way you
>only get the traces you wanted - instead of getting lost in your debug
>traces.
Sounds like a job for pre and post handlers for subs and methods....
Leopold Toetsch
>>This allows for example to run all your code with fatal threshold and
>>then, when running into sub-that-is-supposed-to-be-all-bugged, you just
>>activate debug level, and return to fatal after leaving it. This way you
>>only get the traces you wanted - instead of getting lost in your debug
>>traces.
> Sounds like a job for pre and post handlers for subs and methods....
Pah. Sounds like a debug variable in the interpreter context (what we
already have for errors and warnings - we might need a few more bits for
level, though) and a bit more cleverness for the C<debug> opcode (which
we have too).
Said buggy sub starts with:
debug 0 # turn off or - debug -1 ... reduce level
Returning from the sub restores automagically the old debug level,
because it's in the interpreter context.
More advanced debugging stuff is library code IMHO, we should have all
necessary hooks like asserts and tracebacks, though.
Ah and the Parrot debugger needs a lot of work still.
leo
Nicholas Clark
> Dan Sugalski <d...@sidhe.org> wrote:
> > Sounds like a job for pre and post handlers for subs and methods....
>
> Pah. Sounds like a debug variable in the interpreter context (what we
> already have for errors and warnings - we might need a few more bits for
> level, though) and a bit more cleverness for the C<debug> opcode (which
> we have too).
>
> Said buggy sub starts with:
>
> debug 0 # turn off or - debug -1 ... reduce level
Faffing with $^D in Perl 5 can be really useful.
> Returning from the sub restores automagically the old debug level,
> because it's in the interpreter context.
local $^D in Perl 5, which is also useful.
But we don't have pre and post handers in Perl 5, so I don't know if they'd
make the job easier.
Nicholas Clark