<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - [r600-llvm] mono games with opengl are blocking on start"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=60929#c18">Comment # 18</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - [r600-llvm] mono games with opengl are blocking on start"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=60929">bug 60929</a>
              from <span class="vcard"><a class="email" href="mailto:nmiell@gmail.com" title="Nicholas Miell <nmiell@gmail.com>"> <span class="fn">Nicholas Miell</span></a>
</span></b>
        <pre>(In reply to <a href="show_bug.cgi?id=60929#c17">comment #17</a>)
<span class="quote">> Thanks for tracking this down.  I think we'll need to extend the LLVM C API
> in order to get access to this variable.  However, looking through the LLVM
> code it looks like the PrettyStackTrace handler is registered by a static
> initializer, so I wonder if setting this variable is enough and if we can
> guarantee that r600g will set this variable before the handler is
> initialized.</span >

I don't think this is true -- IIRC, all the stack traces I saw were the result
of one of the runOnFunction methods (either BBPassManager or FPPassManager, I
wasn't paying attention) creating a PassManagerPrettyStackEntry object.

<span class="quote">> Also, this seems to me like it is a bug in LLVM.  Is it common practice for
> libraries to override signal handlers of applications?</span >

Common enough that both Mono and LLVM stomp on each other, but its
unambiguously wrong for a shared library to globally modify signal handlers.
(Temporarily setting a new handler on entry to your library and later restoring
the saved handler before returning is fine, but that only works in the
single-threaded case since handlers aren't per-thread. Arguably modern
applications shouldn't use any signals at all.)

Mono (generally) gets away with it because it uses crazy signals that
applications never touch (SIGPWR is only sent to PID 1 by the kernel on power
failure, SIGXCPU is relic of obsolete job billing infrastructure that nobody
uses), but had the bad luck of LLVM deciding to future-proof itself against all
possible fatal signals.

If I were to be prescriptive, llvm::DisablePrettyStackTrace should be true by
default, should only ever be set by clang, and shouldn't be a global variable.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>