> Any specific reason to not expose report_data structure layout in the > interface header? This pack of functions doesn't look nice.
It's to make it easier to use from LLDB. When we add a new function, it's easier to check whether that symbol exists than to version this struct. See the original suggestion at http://reviews.llvm.org/D4527?id=11470#inline-37585 > Why have you moved ScopedInErrorReport here? Because ScopedInErrorReport's constructor does things where I'd like the report data to already be available. Namely, it calls __asan_on_error, which seems like the only sensible place for a breakpoint *before* the actual report is printed (I'm using it in the debug_report.cc test case). I know we have to be careful about this, but it seems to me this move should be safe (the code in between doesn't do any locks, etc.). Or is there any subtle issue due to this move? I agree with the other comments, will submit a new patch. Kuba http://reviews.llvm.org/D4527 _______________________________________________ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
