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

Thu Sep 2 00:07:27 PDT 2021

Thanks a lot Jim.

Our motivation was from the idea that the user might not be knowing which
variable might be causing the issue and might need multiple runs to finally
zero upon the problem. Another one is if the variable in question is
updated inside a loop. here we need not track all updates, just the last
iteration. However the overhead and multithreading are going to be a
challenge and we are looking at viable solutions.

On the command model we are tracking variable "a" , we are trying to track
and list all the updates to variable a up until that point in the
code(possibly a breakpoint).

Thank you for pointing out the thread plan tracer. Our model is also
similar to this. We will definitely take a deeper look into it and see if
we can suppress some of the undesirable features/effects. :)

On Tue, Aug 31, 2021 at 11:41 PM Jim Ingham <jingham at apple.com> wrote:

> BTW, if you do want to follow this approach, then you should look at the
> "thread plan tracer" bits built into lldb, if you haven't already seen
> them.  The idea is that you can inject an automatic tracer into the
> machinery that governs how the program is executed.  The tracer can either
> follow the normal execution of thread plans or it can override the "step
> mode" so that it will force all "continues" to be a series of instruction
> single steps.  Your proposal is just adding a tracer that forces single
> step and does some printing.  So a more general version of your proposed
> feature would allow the user to set the tracer on, and register a tracer
> callback.  Running programs in single step mode is both very slow and
> fragile (some instructions don't behave quite right in single step mode) so
> we never extended this feature to the user level.  But if you want this as
> a pervasive feature, that would be the way to implement it.
>
> Jim
>
>
> > On Aug 31, 2021, at 10:50 AM, Jim Ingham via lldb-commits <
> lldb-commits at lists.llvm.org> wrote:
> >
> > 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
> >
> > _______________________________________________
> > lldb-commits mailing list
> > lldb-commits at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>

-- 
Thanks and Regards,
Jyothi Krishna V S <https://sites.google.com/site/jkrishnavs>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20210902/60d31c36/attachment-0001.html>