[Lldb-commits] New feature suggestion: Tacking variable update

[Jim Ingham via lldb-commits]

From what I can tell, you are suggesting using instruction single stepping and printing out the variable value if it has changed.  Is that right?  

That seems much more expensive than watchpoints, and it isn't clear to me what the benefits would be.  I would be interested to hear more about the problems you had with watchpoints that lead you away from using them.  You just say "it breaks at every update" but I'm not sure what that means.  Watchpoints seem the natural way to do the job you are suggesting, so it seems the first task should be fixing whatever is rendering them unfit for one of their main purposes...

If you are planning on using single stepping, how were you planning to also track modifications of the variable on other threads?  If you don't also observe them step by step you will miss one of the hardest to find source of modifications, the very ones a facility like this should help to uncover.

Anyway, if your strategy was to use single-stepping on only one of the threads with an "is changed" check & subsequent printing, that does not require a separate command.  You can do that pretty easily with a scripted thread plan.  The SimpleStep in the scripted_step.py example is half way there, you would just have to remove the range check and add the printing.  We don't currently ship any of the scripted thread plans with lldb by default, but if we come up with some useful ones we can certainly start doing so.

I think your command model is a little confused as well.  From the way you were suggesting using it, your "track a" is an operation that sets the target running.  What in your model would happen if the program hit a breakpoint and stopped? Am I expected to say "track a" again to set it going in track mode, or would "step" continue the tracking?  If the latter, then "track a" is both a mode setting command and a continue command, which is confusing.  If you were going to do it as a mode command, then there should be:

(lldb) track add variable "a"
1: Tracking variable a
(lldb) track add variable "b"
2: Tracking variable b
(lldb) track list
1: Tracking variable a
2: Tracking variable b
(lldb) track disable 1
Disabling tracking of variable a
(lldb) continue

Address    Filename  Value  ...

If you were going to do it as a variant of "continue" then you don't need enable and disable.

And I'm not sure that writing this out as a table with header & entries will end up being very workable either.  In a real debugging session you would be using this feature in consort with hitting breakpoints, stepping, etc.  So you'll either have to reprint the header at every restart or the table entries and header will quickly get separated.

Anyway, if you can indeed do what you contemplate with a straightforward scripted step plan, I'm not in favor of adding this as a dedicated command.  The approach seems likely to be so slow as not to be terribly useable in complex programs.  If you are only tracking one thread, you aren't going to catch all modifications of the value at the point where they are modified, leading to more confusion.  And if you try single-stepping all threads you are even more likely to have a feature that isn't really useable in practice.  This seems like the sort of experimental feature that is better added using lldb's extension mechanisms, than as a built-in command.

Jim




> On Aug 24, 2021, at 11:53 PM, Jyothi Krishna V S via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> 
> Hi All,
> We would like to propose a variable tracking for LLDB. The objective and definition of the project are updated in this document. We would like to know id this a project that the community would like to support and may be down the line add to LLDB mainline
> 
> -- A brief of what we are proposing
> 
> What are we trying to do?
> A lot of bugs are introduced by the wrong/unexpected update of a variable. Programmers often track the changes in the value of variables to identify the error in their program. However the point of detection (of the error) is much later than the point of occurrence (the actual error point)  and the user often relies on multiple debug runs or new techniques such as reverse debugging to make the process faster. The user can also rely on watchpoints but it breaks at every update, which can sometimes become very irritating.
> 
> Our aim is to reduce the user effort by providing an opportunity to track the changes to the variables of interest at the point of detection.  This would save a lot of time and effort from the user. 
> For this, we record the variable changes after each instruction, under the LLDB Client. 
> 
> What would it look like in LLDB?
> 
> We are trying to  introduce a new LLDB command called as track  which along with a variable name would print the values and source code instruction at which the variable is executed. 
> 
> For example here we are trying to track the variable a.
> 
> 
> 
> Track details will contain the file name, the new  value, the line number and the source line.
> 
> We understand that this has a substantial overhead so we would like to introduce an enable and disable 
>  Commands:
> The commands that will be introduced in LLDB is as follows,
> enable track
> This command will set or enable the tracking mechanism to start tracking the variable changes.
> 
> 
> disable track
> This command will unset or disable the tracking mechanism to stop tracking the variable changes.
> track variable_name
> The user command track variable name will list the variable value, corresponding source code line number along with address of instruction and file name.
> 
> 
> 
> -- 
> Thanks and Regards,
> Jyothi Krishna V S
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits