[cfe-dev] Setting breakpoints before assignments or calls

[David Blaikie via cfe-dev]

+all the usual debugger folks

I reckon adding nops would be a pretty unfortunate way to go in terms of
code size, etc, if we could help it. One alternative that might work and
we've tossed it around a bit - is emitting more accurate "is_stmt" flags.
In your first example, the is_stmt flag could be set on the bar() call
instruction - and any breakpoint set on an instruction that isn't "is_stmt"
could instead set a breakpoint on the statement that covers that
instruction (the nearest previous is_stmt instruction*)

The inlining case seems to me like something that could be fixed without
changes to the DWARF, purely in the consumer - the consumer has the info
that the call occurs on a certain line and when I ask to break on that line
it could break on that first instruction in the inlined subroutine
(potentially giving me an artificial view that makes it look like I'm at
the call site and leting me 'step' (though a no-op) into the inlined
function).

* This is a bit problematic when a statement gets interleaved/mixed up with
other statements - DWARF has no equivalent of "ranges" for describing a
statement. Likely not a problem at -O0 anyway, though (because little
interleaving occurs there).

On Wed, Aug 22, 2018 at 2:01 PM Vedant Kumar via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hello,
>
> I'd like to improve the situation with setting breakpoints on lines with
> assignments or inlinable calls. This email outlines problem areas, possible
> solutions, and why I think emitting extra nops at -O0 might be the best
> solution.
>
> # Problem 1: Assignments
>
> Counter to user expectation, a breakpoint on a line containing an
> assignment is reached when the assignment happens, not before the r.h.s is
> evaluated.
>
> ## Example: Can't step into bar()
>
>   1| foo = // Set a breakpoint here. Note that it's not possible to step
> into bar().
>   2|   bar();
>
> One solution is to set the location of the assignment to the location of
> the r.h.s (line 2). The problem with this approach is that it becomes
> impossible to set a breakpoint on line 1.
>
> Another solution is to emit a nop (on line 1) prior to emitting the r.h.s,
> and to emit an artificial location on the assignment's store instruction.
> This makes it possible to step to line 1 before line 2, and prevents users
> from stepping back to line 1 after line 2.
>
> # Problem 2: Inlinable calls
>
> Instructions from an inlined function don't have debug locations within
> the caller. This can make it impossible to set a breakpoint on a line that
> contains a call to an inlined function.
>
> ## Example: Can't set a breakpoint on a call
>
> It's easier to see the bug via Godbolt: https://godbolt.org/z/scwF20.
> Note that it's not possible to set a breakpoint on line 9 (on "inline_me").
> At the IR-level, we do emit an unconditional branch with a location that's
> on line 9, but we have to drop that branch during ISel.
>
> The only solution to this problem (afaik) is to insert a nop before
> inlinable calls. In this example the nop would be on line 9.
>
> One alternative I've heard is to make the first inlined instruction look
> like it's located within the caller, but that actually introduces a bug.
> You wouldn't be able to set a breakpoint on the relevant location in the
> inlined callee.
>
> # Proposal
>
> As outlined above, I think the best way to address issues with setting
> breakpoints on assignments and calls is to insert nops with suitable
> locations at -O0. These nops would lower to a target-specific nop at -O0,
> and lower to nothing at -O1 or greater (like @llvm.donothing).
>
> The tentative plan is to introduce an intrinsic (say, @llvm.dbg.nop) to
> accomplish this.
>
> I don't anticipate there being a substantial compile-time impact, but
> haven't actually measured this yet. I'd like to get some feedback before
> going forward. Let me know what you think!
>
> thanks,
> vedant
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180823/1654eed8/attachment.html>