[p-dev] Tracing facilities...

[Paul Bone]

I read this at the time but forgot to reply properly on-list until now.
Sorry.


On Fri, Jul 28, 2017 at 01:15:30PM +0800, Michael Richter wrote:
> There was a halcyon age when high level languages had tracing facilities.
> Dating as far back as 1962 (SNOBOL4) languages offered the ability to trace
> execution as a (sometimes optional) part of the runtime.  Here are some
> examples:
> 
>    - http://www.snobol4.org/docs/burks/tutorial/ch8.htm  (SNOBOL4's
>    debugging and tracing facilities)
>    - http://www.kilowattsoftware.com/tutorial/rexx/trace.htm  (Rexx's
>    debugging and tracing facilities: doesn't cover the TRACE() BIF but that's
>    a minor enhancement)
>    - Erlang has a bewilderingly powerful set of tracing facilities that you
>    can nose around in beginning here:
>    http://erlang.org/doc/man/erlang.html#trace-3  But this is only the tip
>    of the proverbial iceberg.  There's a whole lot more going on there that
>    you can use including sequential traces (that can follow a message around),
>    etc.

These kinds of tracing is often what developers would want, but not know how
to ask for / not know that they want it until they see it demonstrated.

> In brief what I'd propose for Plasma's runtime is this:
> 
>    1. An *optional* trace facility; perhaps only available in the
>    interpreted bytecode machine but not in the final AOT/JIT-compiled code.
>    If you use it, you pay the price for its overhead but if you don't use it
>    there's no runtime cost.

That has an interesting implication.  A bytecode procedure wont necessarily
map 1-to-1 with a Plasma function (they do right now, but optimisations will
break that).  Therefore tracing should not necessarily be bound to the
normal call/return instructions but special instructions inserted in order
to delimit the context as seen in the source code itself.

Regular debugging / stack dumps will need similar information.

>    2. At the very least the trace facility should be able to tell you when
>    each function in your code is called.  This is something you should be able
>    to turn on and off while running so that you can focus on only those parts
>    of the code that are of interest instead of every line in your whole
>    project.
>    3. Better would be the ability to inform the user at each expression
>    being evaluated: at the very least each top-level expression, but perhaps
>    even nested expressions.

I have a weird idea for how to change how code is represented within a block
(of a procedure).  I'd like to develop that idea further before I think
about whether this will be possible.

>    4. Conditional expressions should ideally state which path they chose.

Yes. I like that the Mercury debugger stops at these kinds of things, it's
obvious now that I've seen it.

>    5. Interim values generated in complex expressions should be something
>    you can request (like Rexx's "Intermediate" trace option).

Printing values of abstract types will require extra information to be
passed in, that will probably require a totally seperate version of the
program to be built, such as a debugging version (not just a .pz file with
debugging info available).  It's probably something I'd want anyway, in the
long run.  Maybe tracing a not-build-for-debugging program would just fail
to print values of abstract types (without the right interface also
present).

I have considered that for 32/64 bit compatibility building multiple
versions of the code and putting them both on the .pz file, the same could
be done with a debug/tracing option.  It should be able to be stripped for
anyone who wants smaller files or to make reverse-engineering more
difficult.

>    6. All I/O should state explicitly what came in or out in the trace
>    message (truncated for reasonable sizing, of course).

I'll leave that as a library problem.

>    7. Queries like Erlang's trace queries to narrow down to precise details
>    which things you want to trace: Trace iff the function foo was called with
>    parameter 1 being "seventeen" and if it was called directly or indirectly
>    via function bar.
>    8. In an absolutely perfect world, the hook points used by the above
>    features should be available to the end-user to extend tracing capacities.

These last two are kinda related.  I like the idea of them, but that's
getting to be a big deal to implement.  Not impossible though, and it
seems easy enough to allow for this expansion in the future.

> Obviously not all of these (indeed not most of these!) can be included in
> Plasma 1.0, but when designing the run-time opportunities for hooking these
> in should be considered.

Yep.

Cheers.


-- 
Paul Bone
http://paul.bone.id.au