[PATCH] D64505: [Support] Move the static initializer install_out_memory_new_handler to InitLLVM
Fangrui Song via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jul 10 19:16:38 PDT 2019
MaskRay added a comment.
In D64505#1579593 <https://reviews.llvm.org/D64505#1579593>, @jfb wrote:
> In D64505#1579592 <https://reviews.llvm.org/D64505#1579592>, @rnk wrote:
>
> > In D64505#1579577 <https://reviews.llvm.org/D64505#1579577>, @jfb wrote:
> >
> > > So you're saying: maybe it's a bug if we install one but there was already one installed?
> >
> >
> > Yes. And the user can call llvm_shutdown without setting creating an `InitLLVM` object, so llvm_shutdown shouldn't assume that LLVM's new handler is in use.
>
Yes. I could check `std::get_new_handler`, but I think that is not really necessary. Beside manging argv on Windows, InitLLVM installs signal handlers, which may not be desired in application code. I agree that InitLLVM should only be used by LLVM tools.
>> So, I think this change is fine as is:
>>
>> - LLVM tools want this OOM handler, and they use InitLLVM to set up crash handlers
>> - Users of LLVM as a library should avoid InitLLVM and set their own OOM handler if they want one
>
> Is there a diagnostic that we can add to catch misuses for `InitLLVM`?
I can imagine some out-of-tree LLVM tools don't bother doing their own signal handlers or new handler. I don't know how such tools (where LLVM is an integral part of them) can be differentiated from other tools (e.g. the AMD GPU driver that revealed the problem). So, I don't think a diagnostic is possible...
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D64505/new/
https://reviews.llvm.org/D64505
More information about the llvm-commits
mailing list