[lld] r285224 - Call _exit.

Rafael Espíndola via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 10 19:38:51 PST 2016


True.

In any case, for llvm all we need in llvm_shutdown, but yes, in case
of a destructor we don't control something like this would be useful.

Cheers,
Rafael


On 10 November 2016 at 15:19, Rui Ueyama <ruiu at google.com> wrote:
> On Thu, Nov 10, 2016 at 11:06 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>
>> On 10 November 2016 at 14:03, Rui Ueyama <ruiu at google.com> wrote:
>> > On Thu, Nov 10, 2016 at 6:47 AM, Rafael Espíndola
>> > <rafael.espindola at gmail.com> wrote:
>> >>
>> >> On 10 November 2016 at 00:28, Rui Ueyama <ruiu at google.com> wrote:
>> >> > I think we could add a new member function to
>> >> > SpecificBumpPtrAllocator
>> >> > to
>> >> > discard all objects without calling their dtors. Now that almost all
>> >> > objects
>> >> > are allocated from the pool, so if we call that function before
>> >> > exiting,
>> >> > exit should be as fast as _exit.
>> >>
>> >> But is then the static destructors run the risk of accessing freed
>> >> memory,
>> >> no?
>> >
>> >
>> > How does it happen?
>>
>> It seems too easy to have a global that points to a pool allocated entry.
>
>
> They shouldn't use objects allocated from the pool from the dtor in the
> first place because even now the pool may be freed earlier than the other
> globals, no?


More information about the llvm-commits mailing list