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