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

[Zachary Turner via lldb-commits]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170911/d1316edc/attachment.html>