[Lldb-commits] [lldb] r296814 - Added a list of outstanding projects that would benefit lldb.
Zachary Turner via lldb-commits
lldb-commits at lists.llvm.org
Thu Mar 2 13:54:47 PST 2017
Nice list, thanks!
On Thu, Mar 2, 2017 at 1:51 PM Jim Ingham via lldb-commits <
lldb-commits at lists.llvm.org> wrote:
> Author: jingham
> Date: Thu Mar 2 15:39:27 2017
> New Revision: 296814
>
> URL: http://llvm.org/viewvc/llvm-project?rev=296814&view=rev
> Log:
> Added a list of outstanding projects that would benefit lldb.
>
> This was a list that I've had kicking around for a while, and would
> add to whenever some hallway conversation would bring up another good
> idea. It's not doing any good on my desktop, but it might generate
> some inspiration here. Please add to this if you have any other
> good ideas.
>
> I apologize for the formatting, but if I wait to get it looking
> nice it would probably stay on my desktop.
>
> Added:
> lldb/trunk/www/projects.html (with props)
> Modified:
> lldb/trunk/www/sidebar.incl
>
> Added: lldb/trunk/www/projects.html
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/www/projects.html?rev=296814&view=auto
>
> ==============================================================================
> --- lldb/trunk/www/projects.html (added)
> +++ lldb/trunk/www/projects.html Thu Mar 2 15:39:27 2017
> @@ -0,0 +1,379 @@
> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> +<html xmlns="http://www.w3.org/1999/xhtml">
> +<head>
> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
> +<link href="style.css" rel="stylesheet" type="text/css" />
> +<title>LLDB Projects</title>
> +</head>
> +
> +<body>
> + <div class="www_title">
> + Project ideas for the <strong>LLDB</strong> Debugger
> + </div>
> +
> +<div id="container">
> + <div id="content">
> + <!--#include virtual="sidebar.incl"-->
> + <div id="middle">
> + <div class="post">
> + <h1 class ="postheader">Goals</h1>
> + <div class="postcontent">
> +
> + <p>The following is a mostly
> unordered set of the ideas for improvements
> + to the LLDB debugger. Some
> are fairly deep, some would require less
> + effort.
> + </p>
> +
> + <ol>
> + <li>
> + Speed up type realization
> in lldb.
> + <p>
> + The type of problem I'm
> addressing here is the situation where you are
> + debugging a large program
> (lldb built with debug clang/swift will do)
> + and you go to print a
> simple expression, and lldb goes away for 30 seconds.
> + When you sample it, it is
> always busily churning through all the CU's in the
> + world looking for
> something. The problem isn't that looking for something in
> + particular is slow, but
> rather that we somehow turned an bounded search
> + (maybe a subtype of
> "std::string" into an unbounded search (all things with the
> + name of that subtype.)
> Or didn't stop when we got a reasonable answer
> + proximate to the context
> of the search, but let the search leak out globally.
> + And quite likely there
> are other issues that I haven't guessed yet.
> + But if you end up
> churning though 3 or 4 Gig of debug info, that's going to be slow
> + no matter how well
> written your debug reader is...
> + </p>
> + <p>
> + My guess is the work will
> be more in the general symbol lookup than in the DWARF
> + parser in particular, but
> it may be a combination of both.
> + </p>
> + <p>
> + As a user debugging a
> largish program, this is the most obvious lameness of lldb.
> + </p>
> + </li>
> +
> + <li>
> + Symbol name completion in
> the expression parser.
> + <p>
> + This is the other obvious
> lameness of lldb. You can do:
> + </p>
> +<code><pre><tt>
> +(lldb) frame var foo.b<TAB>
> +</tt></pre></code>
> + <p>
> + and we will tell you it
> is "foo.bar". But you can't do that in the expression parser.
> + This will require
> collaboration with the clang/swift folks to get the right extension
> + points in the compiler.
> And whatever they are, lldb will need use them to tell the
> + compiler about what names
> are available. It will be important to avoid the pitfalls
> + of #1 where we wander
> into the entire DWARF world.
> + </p>
> +
> + </li>
> + <li>
> + Make a high speed
> asynchronous communication channel to replace the gdb-remote protocol.
> + <p>
> + All lldb debugging
> nowadays is done by talking to a debug agent. We used the
> + gdb-remote protocol
> because that is universal, and good enough, and you have
> + to support it anyway
> since so many little devices & JTAG's and VM's etc
> + support it. But it is
> really old, not terribly high performance, and
> + can't really handle
> sending or receiving messages while the process is
> + supposedly running. It
> should have compression built in, remove the hand-built
> + checksums and rely on the
> robust communication protocols we always have nowadays,
> + allow for out-of-order
> requests/replies, allow for reconnecting to a temporarily
> + disconnected debug
> session, regularize all of the packet formatting into JSON or
> + BSON or whatever while
> including a way to do large binary transfers. It must be
> + possible to come up with
> something faster, and better tunable for the many
> + communications pathways
> we end up supporting.
> + </p>
> + </li>
> +
> + <li>
> + Fix the event
> handling/process control machinery to support calling SB & Commands
> + everywhere, and to support
> non-stop debugging
> + <p>
> + There is a fairly ad-hoc
> system to handle when it is safe to run SB API's and
> + command line commands.
> This is actually a bit of a tricky problem, since we
> + allow access to the
> command line and SB API from some funky places in lldb.
> + The Operating System
> plugins are the most obvious instance, since they get
> + run right after lldb is
> told by debugserver that the process has stopped, but
> + before it has finished
> collating the information from the stop for presentation
> + to the higher levels.
> But breakpoint callbacks have some of the same problems,
> + and other things like the
> scripted stepping operations and any fancier extension
> + points we want to add to
> the debugger are going to be hard to implement robustly
> + till we work on a
> finer-grained and more explicit control over who gets to control
> + the process state.
> + <p>
> + We also won't have any
> chance of supporting non-stop debugging - which is a useful
> + mode for programs that
> have a lot of high-priority or real-time worker threads -
> + until we get this sorted
> out.
> + </p>
> + </li>
> +
> + <li>
> + Finish the language
> abstraction and remove all the unnecessary C++/clang-based API's
> + <p>
> + An important part of
> making lldb a more useful "debugger toolkit" as opposed to a
> + C/C++/ObjC/Swift debugger
> is to have a clean abstraction for language support.
> + We did most, but not all,
> of the physical separation. We need to finish that.
> + And then by force of
> necessity the API's really look like the interface to a C++
> + type system with a few
> swift bits added on. How you would go about adding a new
> + language is unclear and
> much more trouble than it is worth at present. But if
> + we made this nice, we
> could add a lot of value to other language projects.
> + </p>
> + </li>
> +
> + <li>
> + Add some syntax to generate
> data formatters from type definitions
> + <p>
> + Uses of the data
> formatters fall into two types. There are data formatters for
> + types where the structure
> elements pretty much tell you how to present the data,
> + you just need a little
> expression language to express how to turn them into what
> + the user expects to see.
> Then there are the ones (like pretty much all our
> + Foundation/AppKit/UIKit
> formatters) that use deep magic to figure out how the type
> + is actually laid out.
> The latter are pretty much always going to have to be done by hand.
> + </p>
> + <p>
> + But for the ones where
> the information is expressed in the fields, it would be great
> + to have a way to express
> the instructions to produce summaries and children in some
> + form you could embed next
> to the types and have the compiler produce a byte code
> + form of the instructions
> and then make that available to lldb along with the library.
> + This isn't as simple as
> having clang run over the headers and produce something from the
> + types directly. After
> all, clang has no way of knowing that the interesting thing about
> + a std::vector is the
> elements that you get by calling size (for the summary) and [] for
> + the elements. But it
> shouldn't be hard to come up with a generic markup to express this.
> + </p>
> + </li>
> +
> + <li>
> + Allow the expression parser
> to access dynamic type/data formatter information
> + <p>
> + This seems like a smaller
> one. The symptom is your object is Foo child of Bar, and in
> + the Locals view you see
> all the fields of Foo, but because the static type of the object
> + is Bar, you can't see any
> of the fields of Foo. But if you could get this working,
> + you could hijack the
> mechanism to make the results of the value object summaries/synthetic
> + children available to
> expressions. And if you can do that, you could add other properties
> + to an object externally
> (through Python or some other extension point) and then have
> + these also available in
> the expression parser. You could use this to express invariants
> + for data structures, or
> other more advanced uses of types in the debugger.
> + </p>
> + <p>
> + Another version of this
> is to allow access to synthetic children in the expression
> + parser. Otherwise you
> end up in situations like:
> + </p>
> +<code><pre><tt>
> +(lldb) print return_a_foo()
> +(SomeVectorLikeType) $1 = {
> + [0] = 0
> + [1] = 1
> + [2] = 2
> + [3] = 3
> + [4] = 4
> +}
> +</tt></pre></code>
> +
> + <p>
> + That's good but:
> + </p>
> +<code><pre><tt>
> +(lldb) print return_a_foo()[2]
> +</tt></pre></code>
> + <p>
> + fails because the
> expression parser doesn't know anything about the array-like nature of
> + SomeVectorLikeType that it
> gets from the synthetic children.
> + </p>
> + </li>
> +
> + <li>
> + Add an extension point in
> the breakpoint search machinery.
> + <p>
> + This would allow highly
> customizable, algorithmic breakpoint types, like "break on every
> + use of some particular
> instruction, or instruction pattern, etc."
> + </p>
> + </li>
> +
> + <li>
> + Documentation and better
> examples
> +
> + <p>
> + We need to put the lldb
> syntax docs in the tutorial somewhere that is more easily accessible.
> + On suggestion is to add
> non-command based help to the help system, and then have a "help lldb"
> + or "help syntax" type
> command with this info. Be nice if the non-command based help could
> + be hierarchical so you
> could make topics.
> + </p>
> +
> + <p>
> + There's a fair bit of
> docs about the SB API's, but it is spotty. Some classes are
> + well documented in the
> Python "help (lldb.SBWhatever)" and some are not.
> + </p>
> +
> +
> + <p>
> + We need more conceptual
> docs. And we need more examples. And we could provide a
> + clean pluggable example
> for using LLDB standalone from Python. The process_events.py
> + is a start of this, but
> it just handles process events, and it is really a quick sketch
> + not a polished expandable
> proto-tool.
> + </p>
> +
> + </li>
> +
> + <li>
> + Make a more accessible
> plugin architecture for lldb.
> +
> + <p>
> + Right now, you can only
> use the Python or SB API's to extend an extant lldb. You can't
> + implement any of the
> actual lldb Plugins as plugins. That means anybody that wants to
> + add new Object
> file/Process/Language etc support has to build and distribute their own
> + lldb. This is tricky
> because the API's the plugins use are currently not stable (and
> + recently have been
> changing quite a lot.) We would have to define a subset of lldb_private
> + that you could use, and
> some way of telling whether the plugins were compatible with
> + the lldb. But long-term,
> making this sort of extension possible will make lldb more
> + appealing for research
> and 3rd party uses.
> + </p>
> + </li>
> +
> + <li>
> + Use instruction emulation
> to avoid the overhead of swapping trap and instruction for breakpoints
> +
> + <p>
> + At present, breakpoints
> are implemented by inserting a trap instruction, then when the trap
> + is hit, replace the trap
> with the actual instruction and single step. Then swap back and
> + continue. This causes
> problems for read only text, and also means that no-stop debugging
> + ust either stop all
> threads briefly to handle this two-step or risk missing some
> + breakpoint hits. If you
> emulated the instruction and wrote back the results, you wouldn't
> + have these problems, and
> it would also save a stop per breakpoint hit. Since we use breakpoints
> + to implement stepping,
> this savings could be significant on slow connections.
> + </p>
> + </li>
> + <li>
> + Use the JIT to speed up
> conditional breakpoint evaluation
> +
> + <p>
> + We already JIT and cache
> the conditional expressions for breakpoints for the C family of
> + languages, so we aren't
> re-compiling every time you hit the breakpoint. And if we couldn't
> + IR interpret the
> expression, we leave the JIT'ed code in place for reuse. But it would
> + be even better if we
> could also insert the "stop or not" decision into the code at the
> + breakpoint, so you would
> only actually stop the process when the condition was true.
> + Greg's idea was that if
> you had a conditional breakpoint set when you started the
> + debug session, Xcode
> could rebuild and insert enough no-ops that we could instrument
> + the breakpoint site and
> call the conditional expression, and only trap if the conditional was true.
> + </p>
> + </li>
> +
> + <li>
> + Broaden the idea in "target
> stop-hook" to cover more events in the debugger
> +
> + <p>
> + Shared library loads,
> command execution, User directed memory/register reads and writes
> + are all places where you
> would reasonably want to hook into the debugger.
> + </p>
> + </li>
> +
> + <li>
> + Mock classes for testing
> + <p>
> + We need "ProcessMock"
> and "ObjectFileMock" and the like. These would be real
> + plugin implementations
> for their underlying lldb classes, with the addition
> + that you can prime them
> from some sort of text based input files. For classes
> + that manage changes over
> time (like process) you would need to program the state
> + at StopPoint 0, StopPoint
> 1, etc. These could then be used for testing reactions
> + to complex threading
> + problems & the like, and
> also for simulating hard-to-test environments (like bare
> + board debugging).
> + </p>
> + </li>
> +
> + <li>
> + A Bug-Trapper infrastructure
> + <p>
> + We very often have bugs
> that can't be reproduced locally. So having a bug-report-trapper
> + that can gather enough
> information from the
> + surroundings of a bug so
> that we can replay the session locally would be a big help
> + tracking down issues in
> this situation. This is tricky because you
> + can't necessarily require
> folks to leak information about their code in order to
> + file bug reports. So not
> only will you have to figure out what state to gather,
> + you're also going to have
> to anonymize it somehow. But we very often have bugs
> + from people that can't
> reduce the problem to a simple test case and can't give us
> + our code, and we often
> just can't help them as things stand now. Note that adding
> + the ProcessMock would be
> a good first stage towards this, since you could make a ProcessMock
> + creator/serializer from
> the current lldb state.
> + </p>
> + </li>
> +
> + <li>
> + Expression parser needs
> syntax for "{symbol,type} A in CU B.cpp" etc.
> +
> + <p>
> + Sometimes you need to
> specify non-visible or ambiguous types to the expression parser.
> + We were planning to do
> $b_dot_cpp$A or something like. You might want to specify a
> + static in a function, in
> a source file, or in a shared library. So the syntax should
> + support all these.
> + </p>
> + </li>
> +
> + <li>
> + Add a "testButDontAbort"
> style test to the UnitTest framework.
> +
> + <p>
> + The way we use unittest
> now (maybe this is the only way it can work, I don't know)
> + you can't report a real
> failure and continue with the test. That is appropriate
> + in some cases: if I'm
> supposed to hit breakpoint A before I evaluate an expression,
> + and don't hit breakpoint
> A, the test should fail. But it means that if I want to
> + test five different
> expressions, I can either do it in one test, which is good
> + because it means I only
> have to fire up one process, attach to it, and get it to
> + a certain point. But it
> also means if the first test fails, the other four don't
> + even get run. So though
> at first we wrote a bunch of test like this, as time went
> + on we switched more to
> writing "one at a time" tests because they were more robust
> + against a single
> failure. That makes the test suite run much more slowly. It
> + would be great to add a
> "test_but_dont_abort" variant of the tests, then we could
> + gang tests that all drive
> to the same place and do similar things. As an added
> + benefit, it would allow
> us to be more thorough in writing tests, since each
> + test would have lower
> costs.
> + </p>
> + </li>
> +
> + <li>
> + Unify Watchpoint's &
> Breakpoints.
> + <p>
> + Option handling isn't
> shared, and more importantly the PerformAction's have a lot
> + of duplicated common
> code, most of which works less well on the Watchpoint side.
> + </p>
> + </li>
> +
> + <li>
> + Reverse debugging.
> + <p>
> + This is kind of a holy
> grail, it's hard to support for complex apps (many
> + threads, shared memory,
> etc.) But it would be SO nice to have...
> + </p>
> + </li>
> +
> + <li>
> + Non-stop debugging.
> +
> + <p>
> + By this I mean allowing
> some threads in the target program to run while stopping
> + other threads. This is
> supported in name in lldb at present, but lldb makes the
> + assumption "If I get a
> stop, I won't get another stop unless I actually run the
> + program." in a bunch of
> places so getting it to work reliably will be some a
> + good bit of work. And
> figuring out how to present this in the UI will also be tricky.
> + </p>
> + </li>
> +
> + <li>
> + Fix and continue.
> + <p>
> + We did this in gdb
> without a real JIT. The implementation shouldn't be that hard,
> + especially if you can
> build the executable for fix and continue. The tricky part is
> + how to verify that the
> user can only do the kinds of fixes that are safe to do.
> + No changing object sizes
> is easy to detect, but there were many more subtle changes
> + (function you are fixing
> is on the stack...) that take more work to prevent.
> + And then you have to
> explain these conditions the user in some helpful way.
> + </p>
> + </li>
> + </ol>
> + </div>
> + <div class="postfooter"></div>
> + </div>
> + </div>
> + </div>
> +</div>
> +</body>
> +</html>
>
> Propchange: lldb/trunk/www/projects.html
>
> ------------------------------------------------------------------------------
> svn:executable = *
>
> Modified: lldb/trunk/www/sidebar.incl
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/www/sidebar.incl?rev=296814&r1=296813&r2=296814&view=diff
>
> ==============================================================================
> --- lldb/trunk/www/sidebar.incl (original)
> +++ lldb/trunk/www/sidebar.incl Thu Mar 2 15:39:27 2017
> @@ -8,6 +8,7 @@
> <li><a href="/goals.html">Goals</a></li>
> <li><a href="/features.html">Features</a></li>
> <li><a href="/status.html">Status</a></li>
> + <li><a href="/projects.html">Projects</a></li>
> </ul>
> </div>
> <div class="menu">
>
>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170302/eb0df3df/attachment-0001.html>
More information about the lldb-commits
mailing list