> On Sep 11, 2017, at 4:05 PM, Leonard Mosescu via lldb-commits
> <lldb-commits@lists.llvm.org> wrote:
>
>
> Process already has "Error Process::WillResume()" for this very reason. Just
> have the Windows mini dump core file plug-in override it. The code in
> Process::Resume already checks this:
> Status Process::PrivateResume() {
> Status error(WillResume());
> // Tell the process it is about to resume before the thread list
> if (error.Success()) {
> ...
> }
> }
> return error;
> }
> Problem solved no???
>
> It would be great, but that also happens too late (by the time
> PrivateResume() is called the state has been already changed)
>
> lldb command interruption requires two parts, one is the rollback, and the
> other is to have someone listening for interruption. To give an instance
> that works in lldb today, if you run the "expr" command, while we are in the
> process of compiling there's no way to interrupt "expr" because clang doesn't
> listen for interrupts. But once the expression is running, we're back in the
> lldb event loop and so we can handle interruption. And of course if you
> interrupt an expression while running it knows how to clean up after itself.
> That wasn't done for interruption primarily, rather "expr" already had to
> know that to be able to clean up from expressions that crashed or raised
> signals while running.
>
> I don't think we need a general "interrupt me anywhere you want" mechanism to
> support command interruption however. Most of the time-consuming work in
> lldb comes in self-contained chunks (reading in symbols from shared
> libraries, reading in the debug info index tables, etc) or happens while lldb
> is actually waiting for something to happen (that part already is
> interruptible at a low level). We try to do work as lazily as possible, so
> if the chunk boundaries and the lazy work boundaries line up you won't really
> need to roll-back at all. The model where you check for interrupts after
> each chunk of work is done will I think be responsive enough for user's
> needs, and also greatly simplify the work to handle interruption. This is a
> little more manual, since you have to insert appropriate "yields", but I
> think will be good enough for our purposes and much easier to make stable.
>
> @Jim: I think we're thinking along the same lines, something intended for the
> poor soul who's does something like "target modules dump symtab", rather than
> the ability to interrupt at any arbitrary point (which as you point out it's
> not really feasible).
Exactly. The ^C in the driver is currently wired up to
SBDebugger::DispatchInputInterrupt(). All that does at present is see if any
targets under the debugger have running processes, and interrupt them. That
could be extended to do more general interrupting. But I haven't taken any
time to think of a good strategy for implementing that.
Jim
>
>
> On Mon, Sep 11, 2017 at 3:43 PM, Greg Clayton via lldb-commits
> <lldb-commits@lists.llvm.org> wrote:
>
>> On Sep 11, 2017, at 3:37 PM, Zachary Turner <ztur...@google.com> wrote:
>>
>> On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits
>> <lldb-commits@lists.llvm.org> wrote:
>> I know there are two points of view here so I will give my two cents:
>>
>> If it comes down to something as easy as "always check for NULL before doing
>> something", or something that is similar and very easy, I would say just
>> code around it. Don't "assert(...)" or "llvm_unreachable(...)". Things that
>> fall into this category: switch statements with defaults that might catch
>> things, checking var/ivar for NULL, seeing if a collection is empty, bounds
>> checking things.
>>
>> One example here is LLDB has its own object file readers for mach-o and ELF.
>> Mach-o has load commands in the file header and each load command has a
>> "cmd" uint32_t whose value is an enum. It is followed by a uint32_t "length"
>> of this data. The LLVM version of the mach-o file parser, a while back
>> before changes were made, wanted to assert or llvm_unreachable for any load
>> command that it didn't recognize. This kind of thing can't happen in a
>> debugger.
>>
>> Right, but that's user input. On the other hand, suppose LLDB manually
>> constructs some IR that it passes to the interpreter. Since LLDB is in full
>> control of the IR it generates, it can safely assert that the interpreter
>> was successful at interpreting it.
>
> Like when you run an expression, it generated some relocation that the JIT
> doesn't handle and it crashes??? We ran into this a few times. So I don't
> agree that anything in the expression stack is not subject to these rules. It
> is something we should fix and we should not crash. So while unexpected
> things are harder to handle, I still say we should recover if at all possible
> and we ran into the relocations stuff not being handles many times over the
> years. We don't control user input that is in the expression.
>
> If you are a shared library, you shouldn't crash if you can help it. If you
> are an executable, do what you want and feel free to crash yourself. We took
> LLDB out of process in Xcode so we could load unsigned code from Swift
> nightly builds, and another benefit was it didn't crash Xcode when things
> went wrong in LLDB.
>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
