<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 12, 2015 at 12:59 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><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>> 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 breakpoint at line 2, they don’t generally expect line 3 and 4 to already have executed. It sounds like a solution would be to associate call expressions with the location of the closing parenthesis instead, so the breakpoint could fall through to line 3 and single-stepping behaves as expected.<br>
><br>
> The downside would be that this might break some existing debuggers’ stepping expectations.<br>
><br>
> What do you think?<br>
><br>
> This generalizes over any line table entry - currently we associate instruction any operation with the preferred source location of the 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 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 - you have to figure out the precedence to know which '+' operator call you were actually in. By using the preferred location we get line 2 or 4 and it's obvious which plus the program is executing.<br>
><br>
> Chandler & I talked about this (offline, unfortunately) when I was making major improvements to locations a few months ago & settled on preferred location being the least ambiguous thing for users. Maybe there are other perspectives we hadn't considered, though.<br>
<br>
</div></div>I really like the improvements in the lines tables and think they are really great. And from a debugger engineer perspective they make total sense to me.<br>
<br>
I am more worried about what issues users will run into as they debug and 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 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.</blockquote><div><br>Yep - pretty much all options have oddities that're going to confuse users. Though it's useful to have the examples, like this, in all directions.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This is partly because the const C string doesn't end up believing it has any code associated with it (the PC relative load of the C string into a register) and it gets attributed to the previous source line -- which seems like a bug we would love to see fixed BTW </blockquote><div><br>I assume that's the constant stuff we have, which is annoying & problematic, yes - essentially loads of constants get coalesced at the start of the basic block they're referenced in, instead of attributed to (at least) the first place they're used.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-- so the line table entries look like:<br>
<br>
0x09f0: main.c:15 // code for the loading of "var1 = %i, var2 = %i" in incorrectly associated with the previous source line<br>
0x1000: main.c:23 // var1 into register<br>
0x1010: main.c:24 // var2 into register<br>
0x1020: main.c:22 // call to printf<br></blockquote><div><br>*nod*<br> </div></div><br></div></div>