There are other use cases (e.g. for adding a backtrace to log messages) where we want to put the backtrace out in ways lldb is used to outputting information - e.g. lldb::Stream's. So I don't think it is true that "all we want to do is get a backtrace to the screen."
Jim > On Mar 4, 2015, at 5:22 PM, Zachary Turner <[email protected]> wrote: > > As mentioned in the other thread, I think the StreamString thing is kind of > irrelevant. The goal here is to get the backtrace to the screen. I would > argue the reverse, that we should only be reinventing facilities in LLDB when > there's a good reason to do so. In this case, I don't think being able to > use a StreamString is a compelling enough reason. On the other hand, having > a consistent backtrace format which supports all platforms is definitely a > compelling reason to use the LLVM facility. So I do think it makes sense > here. > > On Wed, Mar 4, 2015 at 5:12 PM Enrico Granata <[email protected]> wrote: >> On Mar 4, 2015, at 4:39 PM, Zachary Turner <[email protected]> wrote: >> >> BTW, I have just uploaded http://reviews.llvm.org/D8068 to LLVM which >> implements backtracing of self on Windows (previously only backtracing of >> other threads was supported). So once that goes through, if we switch this >> code to using llvm::sys::PrintBacktrace(), > > I don’t think we should make this change. > Host::Backtrace prints to an lldb_private::Stream which is our preferred API > for accumulating output - the LLVM version of this seems to print to a FILE* > which is much less general > > I understand using LLVM facilities where it makes sense, but we should not be > doing so blindly when the net effect is a loss of functionality for us > > If you can implement Host::Backtrace in general on all platforms via LLVM, > feel free to do so - but we should still go through lldb's Host::Backtrace > for this, and Host::Backtrace should still use our Streams > >> we should have a standard backtrace format across all platforms that LLVM >> supports. >> >> I like this feature now that I understand the use case, thanks for >> introducing it. >> > > We had a power outage here in Cupertino, which delayed my reply > Glad to hear we all agree on this :-) > >> On Wed, Mar 4, 2015 at 3:31 PM Siva Chandra <[email protected]> wrote: >> On Wed, Mar 4, 2015 at 2:59 PM, Enrico Granata <[email protected]> wrote: >> > +#ifdef LLDB_CONFIGURATION_DEBUG >> > +#define lldbassert(x) assert(x) >> > +#else >> > +#define lldbassert(x) lldb_private::lldb_assert(x, #x, __FUNCTION__, >> > __FILE__, __LINE__) >> > +#endif >> >> Why should we have this ifdef? As in, why shouldn't we use lldb_assert >> unconditionally, always (giving us the benefit of backtraces always)? >> _______________________________________________ >> lldb-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits > Thanks, > - Enrico > 📩 egranata@.com ☎️ 27683 > > > > > _______________________________________________ > lldb-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
