public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Claudiu Zissulescu <claziss@gmail.com>
Cc: gcc-patches@gcc.gnu.org, Francois Bedard <fbedard@synopsys.com>,
	Andrew Burgess <andrew.burgess@embecosm.com>
Subject: Re: [PATCH 1/2] [ARC] Fix and refurbish the interrupts.
Date: Mon, 08 Jul 2019 18:20:00 -0000	[thread overview]
Message-ID: <31973904-ea6e-3fbc-5c40-51881fb4c82a@redhat.com> (raw)
In-Reply-To: <CAL0iMy2UL3FyQWXYUJ3NfGVVH7knAQX+HPx+qqL1a9LZQTmDNQ@mail.gmail.com>

On 7/8/19 2:35 AM, Claudiu Zissulescu wrote:
> Hi Jeff,
> 
> Originally, I had the scheduler barrier as you suggested. However,
> there were some user cases when an ISR messed up with SP register
> leading to errors. As a solution was to add barriers on either part of
> frame operations. However, I would need to recheck the original
> rationale of that issue, as it may not be the case with newer cores.
For the prologue ISTM that the only issue would be if you had a store
via the frame pointer that moved to a point before allocating the stack.
 I don't think we've ever seen that in practice though.

In the epilogue, the case we've seen several times is we have register
restores via the frame pointer move to a point before deallocating the
stack.

In both cases there'd be live data that would be out of the bounds of
the current stack pointer.  THus if an interrupt occurred the handler
could stomp on that data.

> 
> On the other hand, I found a small error of the current patch when one
> is having the fno-omit-frame-pointer option in the order how some
> auxiliary registers are saved. What will be the best solution having
> in mind that I haven't pushed this patch to the mainline yet:
> - to have the current patch re-spin?
> - to have a separate patch for the new issue.
Your decision.

Jeff

  reply	other threads:[~2019-07-08 18:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28 13:40 Claudiu Zissulescu
2019-06-28 13:39 ` [PATCH 2/2] [ARC] Fix emitting TLS symbols Claudiu Zissulescu
2019-06-28 22:06   ` Jeff Law
2019-07-02 23:15 ` [PATCH 1/2] [ARC] Fix and refurbish the interrupts Jeff Law
2019-07-08  9:01   ` Claudiu Zissulescu
2019-07-08 18:20     ` Jeff Law [this message]
2019-07-09 16:37       ` claziss
2019-07-22 21:54         ` Jeff Law
2019-07-24 13:29           ` Claudiu Zissulescu

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=31973904-ea6e-3fbc-5c40-51881fb4c82a@redhat.com \
    --to=law@redhat.com \
    --cc=andrew.burgess@embecosm.com \
    --cc=claziss@gmail.com \
    --cc=fbedard@synopsys.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).