<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 12, 2015 at 1:36 PM, Peter Ohmann <span dir="ltr"><<a href="mailto:ohmann@cs.wisc.edu" target="_blank">ohmann@cs.wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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"><span class="">On Thu, Mar 12, 2015 at 12:59 PM, Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
<br>
><br>
> > On Mar 12, 2015, at 11:58 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">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" target="_blank">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></span>
> > will get codegen?d into something like (in pseudo-IR):<span class=""><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></span>
> breakpoint at line 2, they don?t generally expect line 3 and 4 to already<span class=""><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></span>
> > The downside would be that this might break some existing debuggers?<div><div class="h5"><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></div></div></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></div></div></blockquote><div><br>Hard to tell from that description what locations would work best for you. Start, end, or preferred location are all valid strategies that do reflect the real execution, in one way or another... <br><br>The examples on this thread should give you some idea of the different strategies - you might be able to take a guess at how they might impact your tools & which sequences might work best for you.<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>For other examples where things get hairy, see clang bug report #15076.</div></div></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>