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

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Fri Jan 4 08:48:44 PST 2019

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:
>   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/b530ce47/attachment.html>

More information about the lldb-commits mailing list