<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Thu, Mar 12, 2015 at 12:59 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
<br>
><br>
> > On Mar 12, 2015, at 11:58 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Thu, Mar 12, 2015 at 11:51 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>><br>
> wrote:<br>
> > Currently the following example:<br>
> ><br>
> > 1 {<br>
> > 2   foo(<br>
> > 3     bar(),<br>
> > 4     baz());<br>
> > 5 }<br>
> ><br>
> > will get codegen?d into something like (in pseudo-IR):<br>
> ><br>
> > %arg0 = call @bar, !dbg (line: 3)<br>
> > %arg1 = call @baz, !dbg (line: 4)<br>
> > call @foo(%arg0, %arg1), !dbg(line: 2)<br>
> ><br>
> > which leads to a weird debugging experience. When developers set a<br>
> breakpoint at line 2, they don?t generally expect line 3 and 4 to already<br>
> have executed. It sounds like a solution would be to associate call<br>
> expressions with the location of the closing parenthesis instead, so the<br>
> breakpoint could fall through to line 3 and single-stepping behaves as<br>
> expected.<br>
> ><br>
> > The downside would be that this might break some existing debuggers?<br>
> stepping expectations.<br>
> ><br>
> > What do you think?<br>
> ><br>
> > This generalizes over any line table entry - currently we associate<br>
> instruction any operation with the preferred source location of the<br>
> instruction. This means something like:<br>
> ><br>
> > x()<br>
> > +<br>
> > y()<br>
> ><br>
> > goes 1, 3, 2 - similar oddity for the user, but it's about the most<br>
> accurate thing we can do, if a bit surprising.<br>
> ><br>
> > Using the end is probably /fairly/ reliable, but also confusing:<br>
> ><br>
> > x<br>
> > +<br>
> > y<br>
> > +<br>
> > z<br>
> ><br>
> > if + is overloaded and you're in a backtrace which points to line 3 or 5<br>
> - you have to figure out the precedence to know which '+' operator call you<br>
> were actually in. By using the preferred location we get line 2 or 4 and<br>
> it's obvious which plus the program is executing.<br>
> ><br>
> > Chandler & I talked about this (offline, unfortunately) when I was<br>
> making major improvements to locations a few months ago & settled on<br>
> preferred location being the least ambiguous thing for users. Maybe there<br>
> are other perspectives we hadn't considered, though.<br>
><br>
> I really like the improvements in the lines tables and think they are<br>
> really great. And from a debugger engineer perspective they make total<br>
> sense to me.<br>
><br>
> I am more worried about what issues users will run into as they debug and<br>
> wonder why things are how they are.<br>
><br>
> The bug that we ran into that spawned this conversation was code like this:<br>
><br>
> 22: printf("var1 = %i, var2 = %i",<br>
> 23:        var1,<br>
> 24:        var2);<br>
><br>
> If you set a breakpoint on line 22 it will stop _after_ var1 and var2 have<br>
> been loaded into registers for the function call to printf and if you say:<br>
><br>
> (lldb) expr var1 = 123<br>
> (lldB) next<br>
><br>
> And step over the printf, you will get the old "var1" value.<br>
<br>
<br>
Yep - pretty much all options have oddities that're going to confuse users.<br>
Though it's useful to have the examples, like this, in all directions.<br></blockquote><div><br></div><div>(I don't need a response; I just wanted to comment)</div><div>This is a very complex issue, no doubt.  To throw in one from the other side...</div><div><br></div><div>Besides for debugging, I use clang's debug info when building program analysis tools that interact with source/debug info from other software.  Thus, for me, any jumping around that causes weird debugging experience is actually a *good* thing if it's more faithful to real execution :)</div><div><br></div><div>For other examples where things get hairy, see clang bug report #15076.</div></div></div></div>