Re: Show line numbers in diagnostics for a scripting language - how can this be done?

"Johannes Schaub (litb)" <schaub-johannes@web.de> wrote in message
> Hello all.
>
> I'm using LLVM, and I'm writing a backend for a closed-source compiler of
> a
> language. Now, suppose I have for example generated roughly the following
> code with LLVM (the runtime library that "rtEmitAdd" is defined in is
> written in C++):
>
> ; allocate three values. Two for the operands and one for the result.
> ; all three are of type "myvalue".
> %num1 = alloca %myvalue
> %num2 = alloca %myvalue
> %result = alloca %myvalue
> ; evaluates 42 + 33. first store the values into the stack
> store %myvalue { %type* @inttype, i32 42 }, %myvalue* %num1
> store %myvalue { %type* @inttype, i32 33 }, %myvalue* %num2
> ; then let the runtime lib calculate it
> call void @rtEmitAdd(%myvalue* %num1,
> %myvalue* %num2,
> %myvalue* %result)
>
> The runtime library will check whether both passed values could be added
> (for example a string and an int can be added, by converting the int to a
> string first). If the values can't be added, it will emit a diagnostic.
>
> My problem is now - in the AST, I know what nodes correspond to what
> source
> lines and even what source columns. But I want to display that information
> (or at least the line-number information) in the diagnostic too.


> What are the usual ways to solve this? I have thought abou this, and
> one way could be to pass the line number along to the runtime
> functions like the following


Is this scripting language interpreted? (I don't know llvm.)


In one interpreter, I added linenumber information by the use of 3 extra
bytecodes, which I called lbreak, ebreak (entry to a function) and rbreak
(return from a function).


All 'lbreak' did was update a 'current source linenumber' variable whenever
it changed. While ebreak/rbreak had to try and maintain a stack of these.


Total overheads were about 5% (in slower execution). I suppose this could be
done in your llvm code by just adding a few special global variables, and
interspersing extra instructions.


In another interpreter, I dispensed with the break opcodes, and instead,
when the was an error, the program counter of the bytecode was searched in a
table of file/linenumbers, and bytecode addresses.


> call void @rtEmitAdd(i32 3, ; appeared in line 3
> %myvalue* %num1,
> %myvalue* %num2,
> %myvalue* %result)
>
> But this is not satisfactory, because I want to not pay the cost of pushin
> the integer along, just for the few cases where I would need to diagnose an
> error. Then I thought about letting the runtime library's direct entry point
> (i.e in the above case, it would be the function "rtEmitAdd") using the
> built-in (GCC has this one) __builtin_return_adress to get the PC of the
> call instruction, and then search debug-information for the corresponding
> line number. This seems like a bit of work to realize.
>
> I wonder now - how is this generally solved for such languages? Thanks in
> advance!


For native code, I'm currently trying a similar method of maintaining tables
of addresses and file/linenumbers. The problem here is the error can occur
outside my code, so it is necessary to trace back (perhaps by the
call-stack) to the last call my code has made. This is workable provided the
program hasn't gone haywire and wiped out the stack or something.


--
Bartc

Return to the comp.compilers page.
Search the comp.compilers archives again.