[Lldb-commits] [PATCH] D59911: Don't abort() in lldb_assert and document why.

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.

In D59911#1446942 <https://reviews.llvm.org/D59911#1446942>, @jingham wrote:

> In this case it might be better to print an error at the problem site.  You could certainly do this with an assert and a printf.  lldbassert just provides a convenient way to do that.
>
> So I would say: use lldbassert for recoverable errors that you would want to catch at the error site in testing, and would want to warn about (as opposed to logging) at the error site in the field.


I just realized that this can cause problems with tests that specifically check the handling of invalid/corrupted debug info (which we don't have many of right now, but we probably should). Normally, you would want to test that lldb gracefully recovers from such a situation, but then in a debug build this will just crash. Theoretically, we could make this behavior dependent on at runtime property (LLDB_ASSERT_SANE_COMPILER=True), but that may just make things too complicated.

> However, I do agree that lldbasserts should be used sparingly.  I'm thinking of the gdb "complaints" which would print a message for everything that wasn't copasetic in debug info.  In practice you would either get no complaints, or you would get a new compiler that did one or two bad things MANY times, and so you would get a spew of complaints and you really wouldn't be able to use the debugger w/o turning them off altogether.
> 
> So you have to make sure that they are not used in situations where they are going to be noisy.

It should be fairly easy to whip up a helper function, which reports an error only once. Perhaps something like:

  switch(form) {
  ...
  default:
    static std::once_flag report_bad_dw_form;
    report_once(report_bad_dw_form, "Unknown form: {0}", form);
    return something;
  }

This would even allow you to place the once_flag inside some object, and get the error reported once for each (e.g.) Module that we are processing.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59911/new/

https://reviews.llvm.org/D59911