[CVS ci] PackFile-15: print warning location
Leopold Toetsch
source file name and line number information.
When now parrot is run with the slow core and warnings are enabled, the
location of the warnings is printed.
$ parrot -bw h.pasm #[1]
Use of uninitialized value in string context at h.pasm line 7.
Use of uninitialized value in string context at h.pasm line 10.
Question is: Should -w automatically select the slow core?
(This is currently the only core which tracks interpreter->cur_pc)
Further:
The C<setline> and C<setfile> opcodes are suboptimal, they impose
runtime penalty on each run core, so they will go finally. The
C<getline> and C<getfile> can map to the functionality used in warnings.c.
And finally: Parrot will (again[2]) track HLL source line info like:
#line 17 "sourcefile.p6"
So that warnings and errors can be located in HLL source too.
Have fun
leo
[1]
$ cat h.pasm
new P1, .PerlHash
# new P3, .PerlString
# set P3, "yyy\n"
# set P1["a"], P3
set P0, P1["a"]
print P0
set P0, "xxx\n"
set P2, P1["a"]
print P2
end
[2] IIRC was that one of my first patches to imcc.
Juergen Boemmels
> Further:
> The C<setline> and C<setfile> opcodes are suboptimal, they impose
> runtime penalty on each run core, so they will go finally. The
> C<getline> and C<getfile> can map to the functionality used in
> warnings.c.
Normal processors also don't have setline and setfile operations. They
use an extra segment in the *.o file, which is only used by the
debugger. This could also be done in parrot. We just need to settle on
a format for the line-info bytecode segement. The only question is
reinvent the wheel, or use an already establiched format (stabs or
DWARF).
> And finally: Parrot will (again[2]) track HLL source line info like:
>
> #line 17 "sourcefile.p6"
>
> So that warnings and errors can be located in HLL source too.
It might be nice to have column information to. This would make
debugging of Befunge programs a lot more easy. Also it would be nice
to have blocks of code (many pasm-lines) with just one linenumber, and
otherwise have a possiblity to increase the source-line with each line
of pasmcode.
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Nicholas Clark
> a format for the line-info bytecode segement. The only question is
> reinvent the wheel, or use an already establiched format (stabs or
> DWARF).
can they do the things below?
> It might be nice to have column information to. This would make
> debugging of Befunge programs a lot more easy. Also it would be nice
I think that it has practical uses for other, dimensionally inferior
languages. It would often be nice to know which bit of this line:
} elsif ($host =~ /([^.]+\.[^.]{3}$)/ || $host =~ /([^.]{4,}\.[^.]{2}$)/ ) {
generated the undefined warning
Also, to be general we should do arbitrary dimensions, else the trifunge
hackers will feel left out.
> to have blocks of code (many pasm-lines) with just one linenumber, and
> otherwise have a possiblity to increase the source-line with each line
> of pasmcode.
Also it would be nice to be able to record debugging lines at several levels,
so that a macro invocation can be stepped through as one line, or as each
line of the macro definition. (recursively)
It's a right pain trying to follow the perl5 C source in a C debugger, or
C++ inline code in gdb. I think that we can learn from those pain sources.
Nicholas Clark
Juergen Boemmels
> On Fri, Aug 22, 2003 at 02:30:13PM +0200, Juergen Boemmels wrote:
>
> > a format for the line-info bytecode segement. The only question is
> > reinvent the wheel, or use an already established format (stabs or
> > DWARF).
>
> can they do the things below?
DWARF has column numbers.
> > It might be nice to have column information to. This would make
> > debugging of Befunge programs a lot more easy. Also it would be nice
>
> I think that it has practical uses for other, dimensionally inferior
> languages. It would often be nice to know which bit of this line:
>
> } elsif ($host =~ /([^.]+\.[^.]{3}$)/ || $host =~ /([^.]{4,}\.[^.]{2}$)/ ) {
>
> generated the undefined warning
Even in C this things happen.
> Also, to be general we should do arbitrary dimensions, else the trifunge
> hackers will feel left out.
But what file-format do they use? Definitifly no plain text file,
because these are normaly 2-dimensional. One can abuse the linenumber
(or the columnnumber) to create an offset in their special file.
If they use text-files there exsits already a mapping from planes to
line/columns, and we can use that.
> > to have blocks of code (many pasm-lines) with just one linenumber, and
> > otherwise have a possiblity to increase the source-line with each line
> > of pasmcode.
>
> Also it would be nice to be able to record debugging lines at several levels,
> so that a macro invocation can be stepped through as one line, or as each
> line of the macro definition. (recursively)
This associates many source-lines to one instruction: The unexpanded
source-line, the first level of expansion, ...
Problem how to create and read out this multi-level
instruction->source-line mapping. A simple #line isn't sufficent any
more.
> It's a right pain trying to follow the perl5 C source in a C debugger, or
> C++ inline code in gdb. I think that we can learn from those pain sources.
Don't repeat errors; make your own errors.
Gordon Henriksen
> Nicholas Clark <ni...@ccl4.org> writes:
>
> > I think that it has practical uses for other, dimensionally inferior
> > languages. It would often be nice to know which bit of this line:
> >
> > } elsif ($host =~ /([^.]+\.[^.]{3}$)/ || $host =~
> /([^.]{4,}\.[^.]{2}$)/ ) {
> >
> > generated the undefined warning
>
> Even in C this things happen.
Could we get expression-level tagging by *character range* rather than
just line? Could be sweet for visual debuggers--hilight the expression
that's about to execute, even if the expression spans lines.
e.g., stepping through $x = 1 + f($y{z} + 3):
$x = 1 + f(%y{z} + 2)
^---^
^-------^
^----------^
^--------------^
^-------------------^
Using just columns would get you this...
$x = 1 + f(%y{z} + 2)
^
^
^
^
^
And the question, "Why'd the step button do nothing that first time?"
Or maybe this...
$x = 1 + f(%y{z} + 2)
^
^
^
^
^
And the question, "Huh?"
Also good for setting breakpoints inside of behemoth Perl statements--I
have some function calls which are quite legitimately several pages
long--interpolations inside of heredocs, lots of parameters, etc. (I
consider it good style; the parameter "comb" much is clearer and more
succinct than building the equivalent parameter hash with multiple
statements. And it'll only get more attractive when P6's yummy new $()
makes interpolation even more convenient and powerful.) Not that a
debugger's ever worked worth snot with Perl 5, so anything's better than
what's going on now.
Speaking from some experience as a user: .NET does expression-level
hilighting, and it's WONDERFUL when it works. However, it seems to use
simple character offsets, which leads to it frequently going awry when I
make a change to the file. It's always seemingly either FABULOUS or
completely broken. Maybe character offsets from beginning of line would
be a less fragile. Or maybe stuff the whole of the source files into the
debugger segment--there's the fragility problem completely solved,
regardless of the use of line offset or file offset. (Of course, PIR
can't do that when just fed an IMCC assembly file...)
Seems straightforward for the compiler to emit character ranges as it
visits AST nodes. Would wind up with lots of line directives--but
there's no way around there, and it's not so hard.
$x = 1 + f(%y{z} + 3);
01234567890123456789012
0 1 2
TREE OP PIR
%y "z"
\ / #file -
{ } 2 { } #line 1[11] 1[16]
\ / set P3 = P2["z"]
+ + #line 1[11] 1[20]
| new P4, .PerlInt
| add P4, P3, 3
1 f() f() #line 1[9] 1[21]
\ / ... P5 <- f(P4) ...
x + + #line 1[5] 1[21]
\ / new P5, .PerlInt
\ / add P5, 1, P5
= = #line 1[0] 1[22]
set P6, P5
This also gracefully degrades to simple line numbers, because #line n
would be trivially equivalent to #line n[0] (n+1)[0]. Good for lazy
compiler authors, or for distributing pbc files with debugging segments
someplace between NONE and 20-bytes per expression + source code.
(That's 20 bytes: { int bytecodeOffset, begLine, begChar, endLine,
endChar; }.)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
gor...@iclub.com
P.S. - On column numbers, could we try to avoid having compilers be
aware of tab width settings?
Benjamin Goldberg
Juergen Boemmels wrote:
>
> Leopold Toetsch <l.to...@nextra.at> writes:
>
> > Further:
> > The C<setline> and C<setfile> opcodes are suboptimal, they impose
> > runtime penalty on each run core, so they will go finally. The
> > C<getline> and C<getfile> can map to the functionality used in
> > warnings.c.
>
> Normal processors also don't have setline and setfile operations. They
> use an extra segment in the *.o file, which is only used by the
> debugger. This could also be done in parrot.
In other words, setline and setfile ops in source don't translate to
actual ops in the bytecode, but instead translate to additions/changes
to the debugging segment?
> We just need to settle on a format for the line-info bytecode segement.
> The only question is reinvent the wheel, or use an already establiched
> format (stabs or DWARF).
>
> > And finally: Parrot will (again[2]) track HLL source line info like:
> >
> > #line 17 "sourcefile.p6"
> >
> > So that warnings and errors can be located in HLL source too.
I don't like this syntax -- it sounds too easy for someone to write a
comment like:
#When this was in the original foobar language, it was on
#line 17
And have it interpreted as a directive, when the author meant for it to
be just a comment.
There's no reason not to have the directives look like ops (setline,
setfile).
Oh, and you could have get{line,file} directives, which end up
translated as being simple "set" ops, using the info generated by the
set{line,file} directives.
> It might be nice to have column information to. This would make
> debugging of Befunge programs a lot more easy. Also it would be nice
> to have blocks of code (many pasm-lines) with just one linenumber, and
> otherwise have a possiblity to increase the source-line with each line
> of pasmcode.
I like the ideas of a range of characters, and of variable amount of
information. So, how about multiple setline variants?
setline Ix # all code from here to the next set{line,file} op is line
x
setline Ix, Iy # set line,col number from here to next set* op.
setline_i Ix # the next line is x, each succeeding line increases.
setlinerange Ix, Iy # the following represents lines x..y of hll
code.
setlinerange Ix, Iy, Iz, Iw # line x, col y .. line z, col w.
setfile Sx # sets filename from here to next setfile op.
There'd be a corresponding get* function for each of these except for
setline_i (for which it wouldn't make sense), which would get translated
at compile time to "set Ix, 12" or whatever. There should be a C-code
level interface to go (at runtime) from a pointer to bytecode (or from a
bytecode offset) to a file, line, or range of lines, or ... with
columns; this would be useful for debuggers.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Chip Salzenberg
> > > #line 17 "sourcefile.p6"
>
> I don't like this syntax -- it sounds too easy for someone to write a
> comment like:
> #When this was in the original foobar language, it was on
> #line 17
Do you worry about Perl too? Because Perl already has this.
Funny how we don't get complaints.
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Brent Dax
# And finally: Parrot will (again[2]) track HLL source line info like:
#
# #line 17 "sourcefile.p6"
Why create a new directive syntax when we already have one?
.line 17 "sourcefile.p6"
--Brent Dax <br...@brentdax.com>
Perl and Parrot hacker
"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."
Leopold Toetsch
> In other words, setline and setfile ops in source don't translate to
> actual ops in the bytecode, but instead translate to additions/changes
> to the debugging segment?
Exactly. (+ C<setpackage>, which isn't done yet)
> I like the ideas of a range of characters, and of variable amount of
> information. So, how about multiple setline variants?
setline \d+
setline \d+ '[' \d+ (',' \d+)* ']'
The brackets have the char (range) info, the first one is used to count
dimensions.
> setline_i Ix # the next line is x, each succeeding line increases.
The HLL doesn't know, how many ops one source line will need.
> There'd be a corresponding get* function for each of these except for
> setline_i (for which it wouldn't make sense), which would get translated
> at compile time to "set Ix, 12" or whatever. There should be a C-code
> level interface to go (at runtime) from a pointer to bytecode (or from a
> bytecode offset) to a file, line, or range of lines, or ... with
> columns; this would be useful for debuggers.
Yep.
leo
Juergen Boemmels
> > Normal processors also don't have setline and setfile operations. They
> > use an extra segment in the *.o file, which is only used by the
> > debugger. This could also be done in parrot.
>
> In other words, setline and setfile ops in source don't translate to
> actual ops in the bytecode, but instead translate to additions/changes
> to the debugging segment?
In principle yes. But as they are no opcodes any more they should not
look like ones. They should be written .setline or #setline
>>> #line 17 "sourcefile.p6"
> I don't like this syntax -- it sounds too easy for someone to write a
> comment like:
>
> #When this was in the original foobar language, it was on
> #line 17
>
> And have it interpreted as a directive, when the author meant for it to
> be just a comment.
from the point of the bytecode this is just a comment. No different
bytecode is generated with or without this line. Only for the
debugsegment gets other information.
> There's no reason not to have the directives look like ops (setline,
> setfile).
No they should not look like ops. They are no ops.
They might look like macros .setfile, macros can evaluate to nothing.
> Oh, and you could have get{line,file} directives, which end up
> translated as being simple "set" ops, using the info generated by the
> set{line,file} directives.
Same here. Use .getline macros which are expanded to a set
operation. Or better use a .currentline macro which expands to the
current line. Much like the __LINE__ macro in C.
Benjamin Goldberg
Leopold Toetsch wrote:
>
> Benjamin Goldberg <ben.go...@hotpop.com> wrote:
>
> > In other words, setline and setfile ops in source don't translate to
> > actual ops in the bytecode, but instead translate to additions/changes
> > to the debugging segment?
>
> Exactly. (+ C<setpackage>, which isn't done yet)
>
> > I like the ideas of a range of characters, and of variable amount of
> > information. So, how about multiple setline variants?
>
> setline \d+
> setline \d+ '[' \d+ (',' \d+)* ']'
>
> The brackets have the char (range) info, the first one is used to count
> dimensions.
Ok.
> > setline_i Ix # the next line is x, each succeeding line increases.
>
> The HLL doesn't know, how many ops one source line will need.
Not *normally*, but if it's including code which is already literal
assembler, it does: Imagine a version of lex/yacc wherein the the blocks
of code you give are imcc or pasm (instead of C). Clearly, there's one
op per line of source.
> > There'd be a corresponding get* function for each of these except for
> > setline_i (for which it wouldn't make sense), which would get
> > translated at compile time to "set Ix, 12" or whatever. There should
> > be a C-code level interface to go (at runtime) from a pointer to
> > bytecode (or from a bytecode offset) to a file, line, or range of
> > lines, or ... with columns; this would be useful for debuggers.
>
> Yep.
>
> leo
--
Benjamin Goldberg
Juergen Boemmels wrote:
>
> Benjamin Goldberg <ben.go...@hotpop.com> writes:
>
> > > Normal processors also don't have setline and setfile operations. They
> > > use an extra segment in the *.o file, which is only used by the
> > > debugger. This could also be done in parrot.
> >
> > In other words, setline and setfile ops in source don't translate to
> > actual ops in the bytecode, but instead translate to additions/changes
> > to the debugging segment?
>
> In principle yes. But as they are no opcodes any more they should not
> look like ones. They should be written .setline or #setline
Ok.
> >>> #line 17 "sourcefile.p6"
>
> > I don't like this syntax -- it sounds too easy for someone to write a
> > comment like:
> >
> > #When this was in the original foobar language, it was on
> > #line 17
> >
> > And have it interpreted as a directive, when the author meant for it
> > to be just a comment.
>
> from the point of the bytecode this is just a comment. No different
> bytecode is generated with or without this line. Only for the
> debugsegment gets other information.
I wasn't suggesting that it might produce different bytecode, but it
could concievable produce incorrect debugging info.
> > There's no reason not to have the directives look like ops (setline,
> > setfile).
>
> No they should not look like ops. They are no ops.
>
> They might look like macros .setfile, macros can evaluate to nothing.
Ok.
> > Oh, and you could have get{line,file} directives, which end up
> > translated as being simple "set" ops, using the info generated by the
> > set{line,file} directives.
>
> Same here. Use .getline macros which are expanded to a set
> operation. Or better use a .currentline macro which expands to the
> current line. Much like the __LINE__ macro in C.
Hmm. Definitely better. Then it can be used as an argument to any op,
not just to set.
So, what values does .currentline have inside of another macro?
Do macros have their own line number context, or do they get the context
from the code they're being called from?
Is this a whole bucket of worms, or just a small can of worms?
Robert Spier
>
> Not *normally*, but if it's including code which is already literal
> assembler, it does: Imagine a version of lex/yacc wherein the the blocks
> of code you give are imcc or pasm (instead of C). Clearly, there's one
> op per line of source.
Insert optimizer here.
-R
Benjamin Goldberg
Blech.
For that matter, won't the optomizer wreak havoc with other all of the
various other uses of .setline?
Anyway, how about this semantic: .setline_i would associate an
increasing series of line numbers to the ops which follow it, as if each
one had been preceded by it's own individiual .setline.
Thus, whatever solution we come up with for the optomizer's interactions
with regular .setline automagically applies to .setline_i, too.
Robert Spier
> For that matter, won't the optomizer wreak havoc with other all of the
> various other uses of .setline?
One would hope.
> Anyway, how about this semantic: .setline_i would associate an
> ...
Before making up semantics, it might be useful to look at what other
systems do, like STABS and DWARF2. They're designed to encapsulate a
little more (out of band) information then we probably need, because
we have more in-band information... but they do seem to work pretty
well.
-R
Gordon Henriksen
> Leopold Toetsch wrote:
>
>> Benjamin Goldberg <ben.go...@hotpop.com> wrote:
>>
>>> setline_i Ix # the next line is x, each succeeding line increases.
>>
>> The HLL doesn't know, how many ops one source line will need.
>
> Not *normally*, but if it's including code which is already literal
> assembler, it does: Imagine a version of lex/yacc wherein the the
> blocks of code you give are imcc or pasm (instead of C). Clearly,
> there's one op per line of source.
p6.pl 1: my $var is int;
p6.pl 2: $var = ($var * $var + 1) * 2 + 3;
p6.imc 1: .local int var
p6.imc 2: setfile "p6.pl"
p6.imc 3: setline 1
p6.imc 4: var = 0 # So far, so good.
p6.imc 5: var = var * var # Line 2 begins here. Yet what's on
the next line?
p6.imc 6: setline 2 # Inhibit auto-increment.
p6.imc 7: var = var + 1
p6.imc 8: setline 2 # Inhibit auto-increment AGAIN.
p6.imc 9: var = var * 2
p6.imc 10: setline 2 # Getting annoying...
p6.imc 11: var = var + 3
And what to do if the HLL is emitting expression-level detail as
character ranges?
—
Gordon Henriksen
mali...@mac.com
Leopold Toetsch
> Insert optimizer here.
The optimizer isn't run for .emit/.eom (PASM) compilation units.
> -R
leo
Leopold Toetsch
> Do macros have their own line number context, or do they get the context
> from the code they're being called from?
Macros have their own line numbers. Tracking filenames (from .include)
isn't done yet.
Debugging PASM with JIT/i386 inside ddd[1] follows embedded macros
> Is this a whole bucket of worms, or just a small can of worms?
We have two kinds of file/line information: Parrot source and HLL
source. So the C<.currentline> macro needs duplication or an argument
specifying, which source it should denote.
leo
[1]
docs/jit.pod
/Debugging
docs/debug.pod
/stabs
Michal Wallace
> We have two kinds of file/line information: Parrot source and HLL
> source. So the C<.currentline> macro needs duplication or an argument
> specifying, which source it should denote.
And when parrot throws an error and complains about line 5,
which one will it mean? :)
Seems like normally you'd want the high-level source line,
unless you're debugging the compiler, in which case you
want the low level one. Maybe this should be a command
line argument to parrot?
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------
Brent Dax
# p6.pl 1: my $var is int;
# p6.pl 2: $var = ($var * $var + 1) * 2 + 3;
#
# p6.imc 1: .local int var
# p6.imc 2: setfile "p6.pl"
# p6.imc 3: setline 1
# p6.imc 4: var = 0 # So far, so good.
# p6.imc 5: var = var * var # Line 2 begins here. Yet what's on
# the next line?
# p6.imc 6: setline 2 # Inhibit auto-increment.
# p6.imc 7: var = var + 1
# p6.imc 8: setline 2 # Inhibit auto-increment AGAIN.
# p6.imc 9: var = var * 2
# p6.imc 10: setline 2 # Getting annoying...
# p6.imc 11: var = var + 3
I believe that what's being proposed is a *special version* of the op
that turns on autoincrement.
.local int var
.setfile "p6.pl"
.setline 1
var = 0
.setline 2
var = var * var
var = var + 1
var = var + 2
var = var + 3
vs.
.local int var
.setfile "p6.pl"
.setline_i 1
var = 0
var = var * var
.setline_i 2
var = var + 1
.setline_i 2
var = var + 2
.setline_i 2
var = var + 3
I'd like to point out, however, that setline_i conflicts cognatively
with the long name of the normal setline op. Perhaps this is the source
of your confusion.
Brent Dax
# On Sun, 24 Aug 2003, Leopold Toetsch wrote:
# > We have two kinds of file/line information: Parrot source and HLL
# > source. So the C<.currentline> macro needs duplication or an
argument
# > specifying, which source it should denote.
#
# And when parrot throws an error and complains about line 5,
# which one will it mean? :)
#
# Seems like normally you'd want the high-level source line,
# unless you're debugging the compiler, in which case you
# want the low level one. Maybe this should be a command
# line argument to parrot?
Have IMCC generate an assembler-based line number table by default,
until it's overridden by a .setline, and have a command-line flag that
disables .setline and friends. Basically, each program would start with
an implicit .setfile and .setline_i.