Re: What debugger breakpoint features would you like?

[Rob Browning]

Neil Jerram <address@hidden> writes:

> I don't think there's any problem per se in using traps.  The
> practical difficulty is that the raw evaluator-traps interface doesn't
> give any support for different applications (debugger, profiler, trace
> etc.) sharing those traps.  Part of what I'm trying to work out with
> the debugger work is what a sensible shareable traps interface might
> look like.  I'd definitely like/need to throw the needs of the
> profiler into that mix at some point.

I think that's the problem I was remembering.  In general, for
profiling, you'd like really quick responses, and you *need* to be
able to minimize any skew the time spent in the infrastructure might
introduce, though as long as you can successfully grab the time
appropriately, you can subtract it out.

> Not sure what you mean here; can you explain further?  Tail recursion
> certainly complicates the use of traps, but I think they give you just
> enough information to work everything out.

I mean that if you want to write a profiler that uses function
entry/exit traps to gather precise information (like gprof?), it seems
like you might have a hard time doing that from the scheme level in
guile, at least for tail recursive functions, without terribly skewing
the results.  Though there may be a clever way around this, it seems
like the naive way of grabbing the time when you enter the function,
and then again when you exit it and subtracting, immediately turns a
tail recursive function into one that grows the stack on every call.

Though perhaps /me is missing something obvious :>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD