[cfe-dev] [llvm] r193937 - When LLVM is embedded in a larger application, it's not OK for LLVM to intercept crashes. LLVM already has

[Eric Christopher]

On Sat, Nov 2, 2013 at 9:51 PM, Filip Pizlo <fpizlo at apple.com> wrote:

>
> On Nov 2, 2013, at 9:49 PM, Alp Toker <alp at nuanti.com> wrote:
>
>
> On 03/11/2013 04:40, Filip Pizlo wrote:
>
> I certainly could.  I'm just playing out the trade-offs and I don't
> see the upside of reverting.  I think we agree that we will replace
> this API with something more thought-out.  So, we agree that this new
> function of mine will have a short shelf-life and should not make it
> into a release.  We can either leave my horrible function in svn for
> the next few days, or we can revert it.  Leaving it in has the
> downside that maybe others will take a liking to it.  Reverting it
> means more hassle for C API clients, like me.  Seems like leaving it
> in is the lesser evil?
>
>
> Filip, as long as you're committed to following this up -- amending the
> comment now and removing the function in the next few days, this is OK
> with me as long as others don't object.
>
>
> Thank you! :-)
>
> Here's my proposal for how to do it:
>
> - Enabling pretty stack tracing is done via an explicit function call,
> which has pthread_once-like behavior (you can call it many times and it's
> idempotent).
> - PrettyStackTraceProgram will call this function.
> - The function will be exposed via the C API and DisablePrettyStackTrace
> will be removed.
>
> This *should* mean that none of LLVM's command-line tools should need any
> changes, since AFAICT, they all do PrettyStackTraceProgram.
>
> Does this sound like the right thing for clang and others?  If so, I can
> hack up the patch.
>
>
This sounds totally reasonable. Probably some docs updates for
PrettyStackTraceProgram et al saying that it needs to be called if you want
pretty stack traces.

-eric


> -Filip
>
>
>
> FWIW I'll be around to help test as soon as you have an Enable() patch.
>
> Most of all, please make sure the function doesn't inadvertently end up
> in 3.4 (!) or it'll be the wrong outcome to a long-standing bug.
>
> Alp.
>
> --
> http://www.nuanti.com
> the browser experts
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131104/6ad8969b/attachment.html>