From: Thomas Neumann <neumann@in.tum.de>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: Jason Merrill <jason@redhat.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Avoid depending on destructor order
Date: Fri, 23 Sep 2022 16:12:15 +0200 [thread overview]
Message-ID: <d4355dda-30ae-facb-d89c-813108dd3b8d@in.tum.de> (raw)
In-Reply-To: <CAGWvnykdvtdwN+jg5kbzB54bhK6namLhZyvwhMBDD+uha8mdTA@mail.gmail.com>
>
> +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
next prev parent reply other threads:[~2022-09-23 14:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 13:25 David Edelsohn
2022-09-23 13:38 ` Thomas Neumann
2022-09-23 14:01 ` David Edelsohn
2022-09-23 14:12 ` Thomas Neumann [this message]
2022-09-23 14:30 ` David Edelsohn
2022-09-25 6:29 ` Iain Sandoe
2022-09-25 15:29 ` Jeff Law
2022-09-26 7:55 ` Rainer Orth
2022-09-27 0:17 ` Jason Merrill
2022-09-23 14:11 ` David Edelsohn
-- strict thread matches above, loose matches on Subject: below --
2022-09-19 16:20 Thomas Neumann
2022-09-22 22:22 ` Jason Merrill
2022-09-26 11:46 ` Claudiu Zissulescu Ianculescu
2022-09-26 11:49 ` Thomas Neumann
2022-09-26 11:50 ` Claudiu Zissulescu Ianculescu
2022-09-26 12:53 ` Iain Sandoe
2022-09-26 13:14 ` Thomas Neumann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d4355dda-30ae-facb-d89c-813108dd3b8d@in.tum.de \
--to=neumann@in.tum.de \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).