<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 6, 2016 at 1:29 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Tue, Sep 6, 2016 at 1:23 PM, Rafael Espíndola via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 6 September 2016 at 16:18, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br>
> Do we intend to make this demangler asynch signal safe, i.e. not call malloc<br>
> at all? If so, I vote keep the custom allocator. If not, I'd say nuke it.<br>
<br>
</span>Is that a requirement for the demangler in libcxxabi?</blockquote><div><br></div></span><div>No.  In fact, it cannot be with the API it implements because you can ask it to allocate memory via malloc.</div></div></div></div></blockquote><div><br></div><div>That is superficial, though. We could add another entry point that takes avoids malloc.</div><div><br></div><div>The use case is, from my crash handler, I want to print a demangled stack trace and exit, without involving a subprocess. You can't allocate much stack and you can't use heap memory, so you probably want to use preallocated global memory or mmap some fresh pages without talking to glibc.</div></div></div></div>