[Lldb-commits] [lldb] r231310 - Introduce lldbassert(x)

[jingham at apple.com]

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 <zturner at google.com> 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 <egranata at apple.com> wrote:
>> On Mar 4, 2015, at 4:39 PM, Zachary Turner <zturner at google.com> 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 <sivachandra at google.com> wrote:
>> On Wed, Mar 4, 2015 at 2:59 PM, Enrico Granata <egranata at apple.com> 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
>> lldb-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> 
> 
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits