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
next prev parent 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).