<div dir="ltr">Right, but I was just talking about that specific instance of replacing Host::Backtrace() with llvm::sys::PrintStackTrace().  There is not a good reason for that specific instance of Host::Backtrace to remain as-is instead of being replaced with llvm::sys::PrintStackTrace.  Even independently of whether we delete Host::Backtrace entirely in favor of llvm::sys::PrintStacktrace across the rest of the codebase.  There's nothing particualrly useful or special about having a StreamString at that call-site.  <div><br></div><div>As for the larger issue of whether to replace Host::Backtrace across the codebase, llvm is open source and has an easy to work with community.  I'm always surprised when I see things like "the right method signature isn't available, let's go re-implement hundreds of lines of code on 4 different platforms".  All we need to do is add the method with the right signature.  <a href="http://reviews.llvm.org/D8074">I've already done that</a> and <a href="http://llvm.org/viewvc/llvm-project?revision=231392&view=revision">it's been committed</a><span style="font-size:13.1999998092651px">. It would be great for the community if people were more open to and comfortable with working in both codebases.</span></div><div><span style="font-size:13.1999998092651px"><br></span></div><div><span style="font-size:13.1999998092651px">It's true that we can't add an signature that takes a StreamString&, but that's the cost of adding unnecessary abstractions (for reference: llvm::raw_ostream supports printf style formatting, and everything else that StreamString supports.  I'm still at a loss for why we don't use it, but that's a discussion for another day).  Because we're stuck in this boat though doesn't mean we should continue adding unnecessary technical debt.</span></div><div><span style="font-size:13.1999998092651px"><br></span></div><div><span style="font-size:13.1999998092651px">By making this simple replacement all stack traces will now have file and line number information, and be able to unwind through inlined functions.  </span></div><div><span style="font-size:13.1999998092651px"><br></span></div><div><span style="font-size:13.1999998092651px">We should always be using llvm library functionality where it's available. And as Chandler said, not because anyone thinks the LLVM side is perfect, but  because we are all part of the same project, and we need to benefit from each other <b>as well as</b> share each others' costs.</span></div><div><span style="font-size:13.1999998092651px"><br></span></div><div><br><div class="gmail_quote">On Thu, Mar 5, 2015 at 11:37 AM <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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."<br>
<br>
Jim<br>
<br>
> On Mar 4, 2015, at 5:22 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> On Wed, Mar 4, 2015 at 5:12 PM Enrico Granata <<a href="mailto:egranata@apple.com" target="_blank">egranata@apple.com</a>> wrote:<br>
>> On Mar 4, 2015, at 4:39 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
>><br>
>> BTW, I have just uploaded <a href="http://reviews.llvm.org/D8068" target="_blank">http://reviews.llvm.org/D8068</a> 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(),<br>
><br>
> I don’t think we should make this change.<br>
> 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<br>
><br>
> 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<br>
><br>
> 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<br>
><br>
>> we should have a standard backtrace format across all platforms that LLVM supports.<br>
>><br>
>> I like this feature now that I understand the use case, thanks for introducing it.<br>
>><br>
><br>
> We had a power outage here in Cupertino, which delayed my reply<br>
> Glad to hear we all agree on this :-)<br>
><br>
>> On Wed, Mar 4, 2015 at 3:31 PM Siva Chandra <<a href="mailto:sivachandra@google.com" target="_blank">sivachandra@google.com</a>> wrote:<br>
>> On Wed, Mar 4, 2015 at 2:59 PM, Enrico Granata <<a href="mailto:egranata@apple.com" target="_blank">egranata@apple.com</a>> wrote:<br>
>> > +#ifdef LLDB_CONFIGURATION_DEBUG<br>
>> > +#define lldbassert(x) assert(x)<br>
>> > +#else<br>
>> > +#define lldbassert(x) lldb_private::lldb_assert(x, #x, __FUNCTION__, __FILE__, __LINE__)<br>
>> > +#endif<br>
>><br>
>> Why should we have this ifdef? As in, why shouldn't we use lldb_assert<br>
>> unconditionally, always (giving us the benefit of backtraces always)?<br>
>> ______________________________<u></u><u></u>_________________<br>
>> lldb-commits mailing list<br>
>> <a href="mailto:lldb-commits@cs.uiuc.edu" target="_blank">lldb-commits@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailm<u></u>an/listinfo/lldb-commits</a><br>
> Thanks,<br>
> - Enrico<br>
> 📩 egranata@.com ☎️ 27683<br>
><br>
><br>
><br>
><br>
> ______________________________<u></u><u></u>_________________<br>
> lldb-commits mailing list<br>
> <a href="mailto:lldb-commits@cs.uiuc.edu" target="_blank">lldb-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailm<u></u>an/listinfo/lldb-commits</a><br>
<br>
</blockquote></div></div></div>