[Lldb-commits] [PATCH] D56293: Use the minidump exception record if present

[Leonard Mosescu via lldb-commits]

>
> ouldn’t we have lldb generate the mini dump itself as the first step of
> the test?
>

How would this work cross-platform?

On Fri, Jan 4, 2019 at 8:48 AM Zachary Turner <zturner at google.com> wrote:

> For those kinds of cases, we could use obj2yaml and check in yaml right?
> Fwiw I tried to round-trip an exe through obj->yaml->obj recently and the
> resulting exe was incorrect but it was close, so I think there’s only some
> small fixes needed.
>
> In regards to your previous response, couldn’t we have lldb generate the
> mini dump itself as the first step of the test?
>
> On Thu, Jan 3, 2019 at 11:59 PM Pavel Labath via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> labath added a comment.
>>
>> In D56293#1345790 <https://reviews.llvm.org/D56293#1345790>, @zturner
>> wrote:
>>
>> > I don't think we can check in an executable file, we should try to
>> compile it on the spot.  We have 1-2 existing unit tests that check in an
>> exe and we occasionally get reports that peoples' virus scanners flag them
>> as trojans, even though they obviously aren't.  In any case, I've been
>> meaning to remove those tests, so I think we should set a precedent that
>> executable binaries are never checked in.
>>
>>
>> While I agree that a checked-in exe shouldn't be needed in this (and most
>> other) cases, I am not sure about the policy in general. For example, I can
>> see a case for having a bunch of badly corrupted binaries (things like
>> corrupted section headers, overlapping sections in the file; things that
>> even yaml2obj will have trouble generating) and then a test that makes sure
>> we do something reasonable (e.g., not crash) when opening them. These are
>> exactly the kind of files that make paranoid virus scanners sound the alarm.
>>
>>
>> Repository:
>>   rLLDB LLDB
>>
>> CHANGES SINCE LAST ACTION
>>   https://reviews.llvm.org/D56293/new/
>>
>> https://reviews.llvm.org/D56293
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20190104/1e86f66b/attachment.html>