[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Zachary Turner via lldb-commits]

Maybe I'm missing something, but Why can't you just not generate a
relocation that the JIT doesn't handle?

On Mon, Sep 11, 2017 at 3:43 PM Greg Clayton <clayborg at gmail.com> wrote:

>
> On Sep 11, 2017, at 3:37 PM, Zachary Turner <zturner at google.com> wrote:
>
> On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits <
> lldb-commits at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170911/4431abf7/attachment.html>