<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="font-size:12.8px"><br></span><span style="font-size:12.8px">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:</span><br style="font-size:12.8px"><span style="font-size:12.8px">Status Process::PrivateResume() {<br></span><span style="font-size:12.8px"> Status error(WillResume());<br></span><span style="font-size:12.8px"> // Tell the process it is about to resume before the thread list<br></span><span style="font-size:12.8px"> if (error.Success()) {<br></span><span style="font-size:12.8px"> ...<br></span><span style="font-size:12.8px"> }<br></span><span style="font-size:12.8px"> }<br></span><span style="font-size:12.8px"> return error;<br></span><span style="font-size:12.8px">}</span><br style="font-size:12.8px"><span style="font-size:12.8px">Problem solved no???</span></blockquote><div><br></div><div>It would be great, but that also happens too late (by the time PrivateResume() is called the state has been already changed)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">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.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">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.</span></blockquote><div> </div><div>@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).<br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 11, 2017 at 3:43 PM, Greg Clayton via lldb-commits <span dir="ltr"><<a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><div><blockquote type="cite"><div>On Sep 11, 2017, at 3:37 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:</div><br class="m_-2891098468255748471Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" target="_blank">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">I know there are two points of view here so I will give my two cents:<br>
<br>
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.<br>
<br>
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. </blockquote><div><br></div><div>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.</div></div></div>
</div></blockquote></div><br></div></div><div>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.</div><div><br></div><div>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. </div></div><br>______________________________<wbr>_________________<br>
lldb-commits mailing list<br>
<a href="mailto:lldb-commits@lists.llvm.org">lldb-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-commits</a><br>
<br></blockquote></div><br></div>