> On Jul 24, 2018, at 9:05 PM, Ramana via lldb-dev <lldb-dev@lists.llvm.org> 
> wrote:
> 
> On the subject line, the ToT lldb (see code around 
> CommandObjectThread.cpp:1230) sets the breakpoint on the first exact matching 
> line of 'line-number' or the closest line number > 'line-number' i.e. the 
> best match.
> 
> And along with that, starting from the above exact/best matching line number 
> index in the line table, the breakpoints are also being set on every other 
> line number available in the line table in the current function scope. This 
> latter part, I believe, is incorrect.

Why do you think this is incorrect?  

The requirements for "thread until <line number>" are:

a) If any code contributed by <line number> is executed before leaving the 
function, stop
b) If you end up leaving the function w/o triggering (a), then stop

Correct or incorrect should be determined by how well the implementation fits 
those requirements.

There isn't currently a reliable indication from the debug information or line 
tables that "line N will always be entered starting with the block at 0x123".  
So you can't tell without doing control flow analysis, which if any of the 
separate entries in the line table for the same line will get hit in the course 
of executing the function.  So the safest thing to do is to set breakpoints on 
them all.  

Besides setting a few more breakpoints - which should be pretty cheap - I don't 
see much downside to the way it is currently implemented.

Anyway, why did this bother you?

Jim


> 
> What, I think, should happen is we just set only one breakpoint on the first 
> exact/best match for the given 'line-number' and another on the return 
> address from the current frame. And this leaves us with one special case 
> where the machine code for one single source line is scattered across (aka 
> scheduled across) and I do not know what is the expected behaviour in this 
> case.
> 
> If I my above understanding is correct and after discussing here on how to 
> handle the scattered code scenario, I will submit a patch.
> 
> Regards,
> Venkata Ramanaiah
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to