Jonathan,
My highest priority requests (for use by the Amber compiler
and toolset) are:
1. To store away, for each part of the compiled program:
- the name of the HLL source filename
- the line and column numbers
2. For PIR error messages to be presented using the HLL source
location rather than the PIR source location.
3. To be able to retrieve the information programatically, e.g.
whilst walking the call chain, so that Amber can provide useful
information when handling an exception.
At a lower priority is:
1. To be able to store and retrieve additional pieces of
information associated with any source location. These
should be extendible, not hardwired. There are two pieces
of information that I am currently interested in:
- The HLL language name (so that the HLL Amber debugger
would not try to handle pieces of the program that are
written in e.g. Python). As a fallback, I could look at
the suffix of the HLL source file, but that's not so
robust.
- The HLL compile options (because Amber scripts can be
compiled with or without runtime monitoring of preconditions
and postconditions, and debugging/exception-handling might
need to work differently in these cases.
No doubt over time, HLL authors will find many useful
and imaginative ways to store and use additional data.
Finally, the following would be "nice to have":
1. To be able to embed the entire HLL source code. Source code
compresses really well, and I think we should compress it.
If we can't find a suitably library, it would take only a
few lines of code to compress and decompress repeated blanks.
The zlib license looks unproblematic, if licensing
rather than dependency is the issue:
http://www.gzip.org/zlib/zlib_license.html
Compression could be made optional, but let's put the hooks
in for it, anyway.
Jonathan wrote:
> Here are my current thoughts.
>
> * We shouldn't restrict this info to a fixed set of fields.
Agree.
> ... Having to specify the file and line every time you want
> to specify a column will bloat generated code massively
Yep. That's clearly out of the question.
> * I'm thinking of a PIR syntax along the lines of this:-
>
> .hll_debug file "something.pl"
I don't mind what syntax is used, provided it's compact. There are
going to be a LOT of hll debug lines generated.
> A special entry ...
> to indicate that all currently inherited data should be
> dispensed with, so it is possible to merge bytecode sanely.
> ... * Maybe there is a need for some PIR syntax...
I don't see the need for special syntax. Just reset everything
to defaults at the start of each new file. Within a file, the
usual syntax can be used (e.g. you could just set filename to "").
Thanks for your work on this.
Regards,
Roger Browne
