Re: [PATCH] Avoid depending on destructor order

[Iain Sandoe <iain@sandoe.co.uk>]

> On 23 Sep 2022, at 15:30, David Edelsohn via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> 
> On Fri, Sep 23, 2022 at 10:12 AM Thomas Neumann <neumann@in.tum.de> wrote:
> 
>>> 
>>>    +static const bool in_shutdown = false;
>>> 
>>> I'll let Jason or others decide if this is the right solution.  It seems
>>> that in_shutdown also could be declared outside the #ifdef and
>>> initialized as "false".
>> 
>> sure, either is fine. Moving it outside the #ifdef wastes one byte in
>> the executable (while the compiler can eliminate the const), but it does
>> not really matter.
>> 
>> I have verified that the patch below fixes builds for both fast-path and
>> non-fast-path builds. But if you prefer I will move the in_shutdown
>> definition instead.
>> 
>> Best
>> 
>> Thomas
>> 
>> PS: in_shutdown is an int here instead of a bool because non-fast-path
>> builds do not include stdbool. Not a good reason, of course, but I
>> wanted to keep the patch minimal and it makes no difference in practice.
>> 
>> 
>>     When using the atomic fast path deregistering can fail during
>>     program shutdown if the lookup structures are already destroyed.
>>     The assert in __deregister_frame_info_bases takes that into
>>     account. In the non-fast-path case however is not aware of
>>     program shutdown, which caused a compiler error on such platforms.
>>     We fix that by introducing a constant for in_shutdown in
>>     non-fast-path builds.
>> 
>>     libgcc/ChangeLog:
>>             * unwind-dw2-fde.c: Introduce a constant for in_shutdown
>>             for the non-fast-path case.
>> 
>> diff --git a/libgcc/unwind-dw2-fde.c b/libgcc/unwind-dw2-fde.c
>> index d237179f4ea..0bcd5061d76 100644
>> --- a/libgcc/unwind-dw2-fde.c
>> +++ b/libgcc/unwind-dw2-fde.c
>> @@ -67,6 +67,8 @@ static void
>>  init_object (struct object *ob);
>> 
>>  #else
>> +/* Without fast path frame deregistration must always succeed.  */
>> +static const int in_shutdown = 0;
>> 
>>  /* The unseen_objects list contains objects that have been registered
>>     but not yet categorized in any way.  The seen_objects list has had
>> 
> 
> Thanks for the patch.  I'll let you and Jason decide which style solution
> is preferred.

This also breaks bootstrap on Darwin at least, so an early solution would be
welcome (the fix here allows bootstrap to continue, testing on-going).
thanks,
Iain

> 
> Thanks, David