[llvm-commits] JIT: Emitting a debug location after an instruction

[Jeffrey Yasskin]

On Mon, Aug 23, 2010 at 1:23 PM, nicolas geoffray
<nicolas.geoffray at gmail.com> wrote:
> Sorry for not being clear: when JIT compiling I attach line information to
> calls. At runtime, when walking the stack, I have the return addresses and
> hence the instruction *after* the call. So currently, I do some computation
> magic to find the line number, but I would like the line information to be
> attached to the next machine instruction after the call.

Do you _only_ attach line information to calls, or also to each other
instruction? If it's only to the calls, do you just not provide line
numbers for the leaf frame? If you do provide line numbers for the
leaf frame, are you worried about providing the wrong number just
after returning from a call?

The line number debug information is generally compressed into a table
of (address, line) pairs, sorted by the address. Then you search the
leaf frame using "std::upper_bound(table, PC)-1". This lets you
transform (a1, 15), (a2, 15), (a3, 15), (a4, 16) into (a1, 15), (a4
16) because looking up a3 using upper_bound will still find line 15,
and JITEmitter::processDebugLoc does this for you with the "PrevDL !=
DL" check. For non-leaf frames, you'd search with
"std::upper_bound(table, PC-1)-1" instead. Using "PC-1" for non-leaf
frames doesn't seem terribly magic to me. Am I still misunderstanding?

> If I attach the line number information to another LLVM instruction (say the
> one next to the call), who knows where that instruction may end up after
> LLVM optimizations. So this is not an option.

Yes, putting an incorrect line number on IR-level instructions
wouldn't work reliably.

> On Mon, Aug 23, 2010 at 2:13 PM, Jeffrey Yasskin <jyasskin at google.com>
> wrote:
>>
>> On Mon, Aug 23, 2010 at 12:51 PM, nicolas geoffray
>> <nicolas.geoffray at gmail.com> wrote:
>> > On Mon, Aug 23, 2010 at 1:46 PM, Jeffrey Yasskin <jyasskin at google.com>
>> > wrote:
>> >>
>> >> What problem are you trying to solve here? This patch looks like it'll
>> >> assign the wrong line number to first instruction of any line, except
>> >> when doing a backtrace.
>> >
>> > The backtrace is exactly what I want to solve here :). Don't think
>> > lines,
>> > but PC.
>>
>> processDebugLoc() matches a line to a PC, so I'm not sure how to avoid
>> thinking about lines. What bad behavior are you seeing? The wrong line
>> assigned to a backtrace frame? Or something else?
>>
>> >> I'm not sure how existing debuggers assign
>> >> line numbers to backtrace frames, but one simple fix might be to look
>> >> up the line of the address before the one stored as the return
>> >> address.
>> >
>> > This does not work if I want precise information: I don't want the PC
>> > before
>> > or after and then do some kind of magic computation, but the exact one.
>>
>> A line number always applies to a range (or several ranges) of
>> addresses. You can look up any address in that range, and get the
>> precise line number. I guess I'm missing what information you need to
>> be precise.
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>