qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 14/14] target/arm: Support reading m-profile system registers


From: Richard Henderson
Subject: Re: [PATCH 14/14] target/arm: Support reading m-profile system registers from gdb
Date: Mon, 20 Feb 2023 07:00:38 -1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

On 2/20/23 06:02, Peter Maydell wrote:
+    /*
+     * NOTE: MSP, PSP, MSPLIM, PSPLIM technically don't exist if the
+     * secure extension is present (replaced by MSP_S, MSP_NS, et al).
+     * However, the MRS instruction is still allowed to read from MSP and PSP,
+     * and will return the value associated with the current security state.

What's "don't exist" based on here? Architecturally MSPLIM, PSPLIM etc
are banked registers; MRS/MSR let you access the one for the current
security state, and (if you are Secure) the one for the NS state.

Copied that wording from David.

+    g_string_printf(s, "<?xml version=\"1.0\"?>");
+    g_string_append_printf(s, "<!DOCTYPE target SYSTEM \"gdb-target.dtd\">");
+    g_string_append_printf(s, "<feature name=\"org.gnu.gdb.arm.m-system\">\n");

Half of these need to be in org.gnu.gdb.arm.secext.
These aren't our own XML features we're making up (if they
were then they would be in org.qemu.something), so we should
follow the existing precedent about what registers go in them.

Now that you point it out (and I should have checked myself), we are kinda making them up. The only registers within upstream gdb m-system and secext are MSP, PSP, MSP_NS, MSP_S, PSP_NS, PSP_S. All the others are our own addition.

Should all the rest be in a third bit of xml?


r~




reply via email to

[Prev in Thread] Current Thread [Next in Thread]