public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: <tom@tromey.com>, <brobecker@adacore.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH v3] gdb/arm: Handle lazy FPU register stacking
Date: Tue, 27 Sep 2022 22:27:43 +0200	[thread overview]
Message-ID: <cebfa8a9-f511-4acd-010c-3fc4a01ec8b0@foss.st.com> (raw)
In-Reply-To: <87pmfgeg1h.fsf@linaro.org>

Hello,

On 2022-09-27 22:08, Thiago Jung Bauermann wrote:
> 
> Hello,
> 
> Torbjörn SVENSSON via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
>> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
>> index 2810232fcb8..43ce1a45782 100644
>> --- a/gdb/arm-tdep.c
>> +++ b/gdb/arm-tdep.c
>> @@ -68,6 +68,7 @@
>>   #endif
>>   
>>   static bool arm_debug;
>> +static bool force_fpu_regs_from_stack = false;
> 
> I'm a bit concerned about having a global variable to indicate what is
> (IIUC) a per-CPU state. Does this logic work with multi-processor
> inferiors?
> 
> Instead of using a global variable, can arm_m_exception_cache use
> “this_frame->level > 0” to decide whether to get the FPU registers from
> the stack?
> 

I share your concern, but haven't found any better way to achieve the 
required condition.

The content of FPCCR shall only be considered for the first extended 
exception frame on the stack. As there are likely other kinds of frames 
on the stack, the level would not be enough to decide if stack or 
registers should be used.

Do you know a way that this state can be saved per inferior?

On the other hand, I got the impression that the cache is purged when 
the inferior is switched, but this assumption might be wrong.

I've only verified the function with a simple single inferior.

Kind regards,
Torbjörn

  reply	other threads:[~2022-09-27 20:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-27 19:09 Torbjörn SVENSSON
2022-09-27 20:08 ` Thiago Jung Bauermann
2022-09-27 20:27   ` Torbjorn SVENSSON [this message]
2022-09-30  2:55     ` Thiago Jung Bauermann
2022-09-30 13:20       ` Luis Machado
2022-09-30 15:13 ` Pedro Alves
2022-09-30 15:26   ` Torbjorn SVENSSON
2022-09-30 15:52     ` Pedro Alves

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=cebfa8a9-f511-4acd-010c-3fc4a01ec8b0@foss.st.com \
    --to=torbjorn.svensson@foss.st.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=thiago.bauermann@linaro.org \
    --cc=tom@tromey.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).