I think everyone is in agreement that input should be sanitized, and
ill-formed input should not trigger an abrupt termination if there's a way
to recover (which is not always feasible).
The conversation started around fail-fast for inconsistent and
unrecoverable state, where I think the math is v
> On Sep 11, 2017, at 10:24 AM, Leonard Mosescu wrote:
>
> I think everyone is in agreement that input should be sanitized, and
> ill-formed input should not trigger an abrupt termination if there's a way to
> recover (which is not always feasible).
>
> The conversation started around fail-f
Thanks Jim, I'll give option #1 a try and upload a new patch.
think your divisions into options is too simplistic. lldb is built of
> many different subsystems, and a lot of "inconsistent state" can be
> confined to one subsystem or other. So for instance, if one CU's debug is
> unrecoverably d
+Mark Mentovai
On Mon, Sep 11, 2017 at 12:24 PM, Leonard Mosescu
wrote:
> Thanks Jim, I'll give option #1 a try and upload a new patch.
>
> think your divisions into options is too simplistic. lldb is built of
>> many different subsystems, and a lot of "inconsistent state" can be
>> confined t
> On Sep 11, 2017, at 12:24 PM, Leonard Mosescu wrote:
>
> Thanks Jim, I'll give option #1 a try and upload a new patch.
>
> think your divisions into options is too simplistic. lldb is built of many
> different subsystems, and a lot of "inconsistent state" can be confined to
> one subsyste
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
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 an
> On Sep 11, 2017, at 3:37 PM, Zachary Turner wrote:
>
> On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits
> mailto: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 chec
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 wrote:
>
> On Sep 11, 2017, at 3:37 PM, Zachary Turner wrote:
>
> On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits <
> lldb-commit
>
>
> 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 t
> On Sep 11, 2017, at 4:04 PM, Zachary Turner wrote:
>
> Maybe I'm missing something, but Why can't you just not generate a relocation
> that the JIT doesn't handle?
Eventually Lang did that for us and he now has tests for all kinds of
relocations. Before that we would crash.
___
> On Sep 11, 2017, at 4:05 PM, Leonard Mosescu 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() {
> Statu
fwiw the reason the JIT came up is because we had an instance where the older
MCJIT wasn't handling a relocation in thumb code about six weeks ago and we
only caught the crash a couple days before we released a beta of it. It
definitely can happen with MCJIT. I think with ORC JIT this is a not
> On Sep 11, 2017, at 4:05 PM, Leonard Mosescu via lldb-commits
> 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::Private
On Mon, Sep 11, 2017 at 4:22 PM Jason Molenda via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> fwiw the reason the JIT came up is because we had an instance where the
> older MCJIT wasn't handling a relocation in thumb code about six weeks ago
> and we only caught the crash a couple days b
Hi All,
I see in the command Mapping Documnet, we can use "image lookup -type" in
place of "ptype" from gdb. Currently, this can be used only for Type(link
int, char) , or gloal, static variable or function symbol.
This is not as efficient as GDB, where it will whole structure if we point
to var
16 matches
Mail list logo
