public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: "Wilco Dijkstra" <Wilco.Dijkstra@arm.com>,
	"Martin Liška" <mliska@suse.cz>,
	"Kyrylo Tkachov" <Kyrylo.Tkachov@arm.com>,
	"Szabolcs Nagy" <Szabolcs.Nagy@arm.com>,
	"GCC Patches" <gcc-patches@gcc.gnu.org>,
	richard.sandiford@arm.com
Subject: Re: [PATCH] libgcc: Fix uninitialized RA signing on AArch64 [PR107678]
Date: Thu, 12 Jan 2023 16:34:22 +0100	[thread overview]
Message-ID: <Y8AofgFEZ0sfiGan@tucnak> (raw)
In-Reply-To: <mptcz7jwze7.fsf@arm.com>

On Thu, Jan 12, 2023 at 03:22:56PM +0000, Richard Sandiford wrote:
> If we have a new enum, I think we should handle it explicitly.  The fact
> that the information isn't propagated between frames is a key part of
> the semantics.
> 
> >> Another option is to just define the arch dependent value for how field
> >> in the arch code, right now it is unsigned char type, so using say
> >> (unsigned char) ~0 or (unsigned char) ~0 and (unsigned char) ~1 as arch
> >> specific values might be ok too.
> >
> > Yet another option would be to define 1-2 extra REG_ values in the generic
> > unwind-dw2.h header, but name them
> >   REG_ARCH_SPECIFIC_1,
> >   REG_ARCH_SPECIFIC_2,
> > or so, and then the machine specific code can
> > #define REG_AARCH64_TOGGLE_ON REG_ARCH_SPECIFIC_1
> > Of course, all this depends on whether the arch specific codes can be
> > handled in uw_update_context_1 by doing break; there and nothing else.
> 
> Yeah, personally I'd prefer for target-independent code to provide
> the toggle representation, even if it isn't widely used.

I can live even with that, I just hope it won't make code generation worse
on other targets.
Anyway, I understood aarch64 needs 2 states for the signing, so one would
be REG_TOGGLE_ON and the other anything else?
Users can always create (invalid?) unwind info where they save the magic
register, make it undefined etc.

And
void bar (void), baz (void), boo (void), qux (void), corge (void);
enum {
  REG_UNSAVED,
  REG_SAVED_OFFSET,
  REG_SAVED_REG,
  REG_SAVED_EXP,
  REG_SAVED_VAL_OFFSET,
  REG_SAVED_VAL_EXP,
  REG_UNDEFINED
#ifdef ANOTHER
  , REG_TOGGLE_ON
#endif
};

void
foo (unsigned char c)
{
  switch (c)
    {
      case REG_UNSAVED:
      case REG_UNDEFINED:
#ifdef ANOTHER
      case REG_TOGGLE_ON:
#endif
        break;
          
      case REG_SAVED_OFFSET:
        bar ();
        break;
     
      case REG_SAVED_REG:
        baz ();
        break;
  
      case REG_SAVED_EXP:
        boo ();
        break;
  
      case REG_SAVED_VAL_OFFSET:
        qux ();
        break;

      case REG_SAVED_VAL_EXP:
        corge ();
        break;
    }
}
suggests that it doesn't, already cfg pass turns the implicit default:
into something that covers even the REG_UNSAVED, REG_UNDEFINED and maybe
REG_TOGGLE_ON values into default:

	Jakub


  reply	other threads:[~2023-01-12 15:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01 16:55 Wilco Dijkstra
2022-12-05 19:04 ` Richard Sandiford
2022-12-06 10:50   ` Szabolcs Nagy
2022-12-06 11:58     ` Wilco Dijkstra
2022-12-06 21:33       ` Szabolcs Nagy
2023-01-03 17:27   ` Wilco Dijkstra
2023-01-05 14:57     ` Szabolcs Nagy
2023-01-10 16:33       ` Wilco Dijkstra
2023-01-10 18:12         ` Jakub Jelinek
2023-01-11 11:33           ` Martin Liška
2023-01-11 11:59             ` Wilco Dijkstra
2023-01-12 10:49               ` Jakub Jelinek
2023-01-12 12:05                 ` Richard Sandiford
2023-01-12 12:08                   ` Richard Sandiford
2023-01-12 12:28                   ` Jakub Jelinek
2023-01-12 14:39                     ` Jakub Jelinek
2023-01-12 15:22                       ` Richard Sandiford
2023-01-12 15:34                         ` Jakub Jelinek [this message]
2023-01-12 15:40                           ` Richard Sandiford
2023-01-12 18:57         ` Jakub Jelinek
2023-01-16 13:04           ` Martin Liška
2023-01-17 19:49             ` Wilco Dijkstra
2023-01-17 20:43               ` Richard Sandiford
2023-01-18 12:49                 ` Wilco Dijkstra

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=Y8AofgFEZ0sfiGan@tucnak \
    --to=jakub@redhat.com \
    --cc=Kyrylo.Tkachov@arm.com \
    --cc=Szabolcs.Nagy@arm.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mliska@suse.cz \
    --cc=richard.sandiford@arm.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).