On Tue, 2021-01-12 at 08:44 +0100, Richard Biener wrote: > On Mon, Jan 11, 2021 at 10:57 PM David Malcolm via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > If fancy_abort is called before the diagnostic subsystem is > > initialized, > > internal_error will crash internally in a way that prevents a > > useful > > message reaching the user. > > > > This can happen with libgccjit in the case of gcc_assert failures > > that occur outside of the libgccjit mutex that guards the rest of > > gcc's state, including global_dc (when global_dc may not be > > initialized yet, or might be in use by another thread). > > > > I tried a few approaches to fixing this as noted in PR jit/98586 > > e.g. using a temporary diagnostic_context and initializing it for > > the call to internal_error, however the more code that runs, the > > more chance there is for other errors to occur. > > > > The best fix appears to be to simply fall back to a minimal abort > > implementation that only relies on i18n, as implemented by this > > patch. > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > > > Is there a better way to fix this? If not I plan to push this > > to master in a few days. > > The only other idea I can come up with is to somehow statically > initialize global_dc to a minimal implementation to catch those.
We sort of do that already, given that it points at a global diagnostic_context. I think trying to integrate this handling with the diagnostic subsystem any further will run into issues for the case of libgccjit linked into a multithreaded program, given that global_dc is global state. Thinking about those kinds of cases makes me feel that this crash-handling for the crash handler ought to be as simple as possible. > Otherwise your approach is entirely reasonable. Thanks. I've gone ahead and pushed this to master as r11-6700- g387f6c15d303a8f8da508e419fea10a6ef0e2590. Dave
