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

[nicolas geoffray]

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.

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.

Nicolas

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100823/b1fdd865/attachment.html>