[Sorry if this doesn't thread in your reader]
Jonathan Worthington wrote:
> I'm looking to work
> on enabling Parrot to store away HLL debug info - that is, the file name,
> line number, columns etc in the high level language source code. This data
> can then be used to emit useful error messages that relate to the HLL source
> code rather than the generated PIR/PASM/whatever.
Does it make sense to have nestable the structures?
e.g.
@push HLL "perl"
@push file "something.pl"
@push line 1
@push column 17
...
@pop column
@pop line
@push line 2
...
@push file "inlined.pl"
@push line 34
...
@pop line
@pop file
...
@pop line
@push line 4
@push pragma xyz
...
@pop pragma
@pop line
@pop file
@pop HLL
Ok, ok, the syntax itself isn't important. I'm just doing nesting.
Then for any point in the pbc file there would be a set of active
attributes/values which could be retrieved as a hash. Note that you
can express bytecode ranges where there isn't valid line number
information available (e.g. where extra PIR runtime glue is inserted
which doesn't come from the HLL). You can also push the language at
the top at bottom.
The representation in the debug section would then just be something like:
1: push HLL "perl"
1: push file "something.pl"
1: push line 1
1: push column 17
5: pop column
5: pop line
5: push line 2
etc.
where the number is the bytecode offset. [Obviously there are
efficient ways to store this by using bit fields and sharing data]
To get the active attributes corresponding to the bytecode you'd need
to start at the beginning and push/pop attributes until you get to the
correct offset, but you wouldn't need to do this too often and so I
believe the extra processing to be worthwhile.
Cheers,
Nick
