From: Luis Machado <luis.machado@arm.com>
To: John Baldwin <jhb@FreeBSD.org>, Pedro Alves <pedro@palves.net>,
gdb-patches@sourceware.org,
David Spickett <David.Spickett@arm.com>
Subject: Re: [PATCH] [Arm] Remove dead FPA code
Date: Tue, 4 Oct 2022 18:43:06 +0100 [thread overview]
Message-ID: <56653c70-593a-4b8d-ddf7-52f7dd0608f7@arm.com> (raw)
In-Reply-To: <73479562-ab47-dfbf-aadc-7a2203c0f0e4@FreeBSD.org>
On 10/4/22 18:08, John Baldwin wrote:
> On 10/4/22 1:43 AM, Luis Machado via Gdb-patches wrote:
>> On 10/3/22 20:16, Pedro Alves wrote:
>>> On 2022-09-20 1:30 p.m., Luis Machado via Gdb-patches wrote:
>>>
>>>> diff --git a/gdb/arch/arm.h b/gdb/arch/arm.h
>>>> index 36757493406..74a6ba93bc7 100644
>>>> --- a/gdb/arch/arm.h
>>>> +++ b/gdb/arch/arm.h
>>>> @@ -44,11 +44,6 @@ enum gdb_regnum {
>>>> ARM_SP_REGNUM = 13, /* Contains address of top of stack */
>>>> ARM_LR_REGNUM = 14, /* address to return to from a function call */
>>>> ARM_PC_REGNUM = 15, /* Contains program counter */
>>>> - /* F0..F7 are the fp registers for the (obsolete) FPA architecture. */
>>>
>>> Shouldn't we leave behind a comment explaining why there's a hole between 15 and 25?
>>
>> I pondered about this a bit more, and I think we should close the gap and bring CPSR down to
>> 16, its "natural" position. It is what linux uses for user_regs as well, in gdb/arch/arm-linux.h:
>>
>> /* The index to access CSPR in user_regs defined in GLIBC. */
>> #define ARM_CPSR_GREGNUM 16
>>
>>>
>>> IIRC the numbers can't be changed since we need to handle the case when the target
>>> doesn't send an xml tdesc, so it'd be good to help future readers understand why
>>> there's a hole.
>>
>> That's correct. Though a 32-bit Arm target that doesn't support XML descriptions these days is not very
>> common. I haven't seen one in a while.
>>
>> I'm willing to declare old 32-bit Arm targets that don't send XML target descriptions back as unsupported.
>>
>> To that effect, I suppose we should add a note to make it more explicit.
>>
>> More below.
>
> FWIW, the GDB stub in FreeBSD's kernel does not use XML target descriptions
> for any architectures, but it also only tends to do GPRs and not any floating
> point. For 32-bit ARM it does not report any register values higher than
> number 15 (PC), so it would not be affected by changing this.
Does it care about CPSR and/or XPSR? Could you please give it a try to see if the defaults would suit it just fine?
>
> Do you know if LLDB supports floating-point registers on 32-bit arm as well?
> The register numbers in the 'g' packet are effectively part of the protocol
> shared between the two, so might be worth coording with lldb folks as well if
> they support FPA?
>
It does seem to support FP registers, but not FPA.
For example, from https://github.com/llvm-mirror/lldb/blob/master/examples/python/armv7_cortex_m_target_defintion.py:
armv7_register_infos = [
{ 'name':'r0' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo, 'alt-name':'arg1' },
{ 'name':'r1' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo, 'alt-name':'arg2' },
{ 'name':'r2' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo, 'alt-name':'arg3' },
{ 'name':'r3' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo, 'alt-name':'arg4' },
{ 'name':'r4' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo },
{ 'name':'r5' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo },
{ 'name':'r6' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo },
{ 'name':'r7' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo, 'alt-name':'fp' },
{ 'name':'r8' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo },
{ 'name':'r9' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo },
{ 'name':'r10' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo },
{ 'name':'r11' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo },
{ 'name':'r12' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo },
{ 'name':'sp' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo, 'alt-name':'r13' },
{ 'name':'lr' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo, 'alt-name':'r14' },
{ 'name':'pc' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo, 'alt-name':'r15' },
{ 'name':'xpsr' , 'set':0, 'bitsize':32 , 'encoding':eEncodingUint , 'format':eFormatAddressInfo, 'alt-name':'cpsr' },
];
Also, for the SEGGER J-Link:
<!DOCTYPE feature SYSTEM "gdb-target.dtd">
<target version="1.0">
<architecture>arm</architecture>
<feature name="org.gnu.gdb.arm.m-profile">
<reg name="r0" bitsize="32" regnum="0" type="uint32" group="general"/>
<reg name="r1" bitsize="32" regnum="1" type="uint32" group="general"/>
<reg name="r2" bitsize="32" regnum="2" type="uint32" group="general"/>
<reg name="r3" bitsize="32" regnum="3" type="uint32" group="general"/>
<reg name="r4" bitsize="32" regnum="4" type="uint32" group="general"/>
<reg name="r5" bitsize="32" regnum="5" type="uint32" group="general"/>
<reg name="r6" bitsize="32" regnum="6" type="uint32" group="general"/>
<reg name="r7" bitsize="32" regnum="7" type="uint32" group="general"/>
<reg name="r8" bitsize="32" regnum="8" type="uint32" group="general"/>
<reg name="r9" bitsize="32" regnum="9" type="uint32" group="general"/>
<reg name="r10" bitsize="32" regnum="10" type="uint32" group="general"/>
<reg name="r11" bitsize="32" regnum="11" type="uint32" group="general"/>
<reg name="r12" bitsize="32" regnum="12" type="uint32" group="general"/>
<reg name="sp" bitsize="32" regnum="13" type="data_ptr" group="general"/>
<reg name="lr" bitsize="32" regnum="14" type="uint32" group="general"/>
<reg name="pc" bitsize="32" regnum="15" type="code_ptr" group="general"/>
<reg name="xpsr" bitsize="32" regnum="25" type="uint32" group="general"/>
</feature>
<feature name="org.gnu.gdb.arm.m-system">
<reg name="msp" bitsize="32" regnum="26" type="uint32" group="general"/>
<reg name="psp" bitsize="32" regnum="27" type="uint32" group="general"/>
<reg name="primask" bitsize="32" regnum="28" type="uint32" group="general"/>
<reg name="basepri" bitsize="32" regnum="29" type="uint32" group="general"/>
<reg name="faultmask" bitsize="32" regnum="30" type="uint32" group="general"/>
<reg name="control" bitsize="32" regnum="31" type="uint32" group="general"/>
</feature>
<feature name="org.gnu.gdb.arm.m-float">
<reg name="fpscr" bitsize="32" regnum="32" type="uint32" group="float"/>
<reg name="s0" bitsize="32" regnum="33" type="float" group="float"/>
<reg name="s1" bitsize="32" regnum="34" type="float" group="float"/>
<reg name="s2" bitsize="32" regnum="35" type="float" group="float"/>
<reg name="s3" bitsize="32" regnum="36" type="float" group="float"/>
<reg name="s4" bitsize="32" regnum="37" type="float" group="float"/>
<reg name="s5" bitsize="32" regnum="38" type="float" group="float"/>
<reg name="s6" bitsize="32" regnum="39" type="float" group="float"/>
<reg name="s7" bitsize="32" regnum="40" type="float" group="float"/>
<reg name="s8" bitsize="32" regnum="41" type="float" group="float"/>
<reg name="s9" bitsize="32" regnum="42" type="float" group="float"/>
<reg name="s10" bitsize="32" regnum="43" type="float" group="float"/>
<reg name="s11" bitsize="32" regnum="44" type="float" group="float"/>
<reg name="s12" bitsize="32" regnum="45" type="float" group="float"/>
<reg name="s13" bitsize="32" regnum="46" type="float" group="float"/>
<reg name="s14" bitsize="32" regnum="47" type="float" group="float"/>
<reg name="s15" bitsize="32" regnum="48" type="float" group="float"/>
<reg name="s16" bitsize="32" regnum="49" type="float" group="float"/>
<reg name="s17" bitsize="32" regnum="50" type="float" group="float"/>
<reg name="s18" bitsize="32" regnum="51" type="float" group="float"/>
<reg name="s19" bitsize="32" regnum="52" type="float" group="float"/>
<reg name="s20" bitsize="32" regnum="53" type="float" group="float"/>
<reg name="s21" bitsize="32" regnum="54" type="float" group="float"/>
<reg name="s22" bitsize="32" regnum="55" type="float" group="float"/>
<reg name="s23" bitsize="32" regnum="56" type="float" group="float"/>
<reg name="s24" bitsize="32" regnum="57" type="float" group="float"/>
<reg name="s25" bitsize="32" regnum="58" type="float" group="float"/>
<reg name="s26" bitsize="32" regnum="59" type="float" group="float"/>
<reg name="s27" bitsize="32" regnum="60" type="float" group="float"/>
<reg name="s28" bitsize="32" regnum="61" type="float" group="float"/>
<reg name="s29" bitsize="32" regnum="62" type="float" group="float"/>
<reg name="s30" bitsize="32" regnum="63" type="float" group="float"/>
<reg name="s31" bitsize="32" regnum="64" type="float" group="float"/>
<reg name="d0" bitsize="64" regnum="65" type="ieee_double" group="float"/>
<reg name="d1" bitsize="64" regnum="66" type="ieee_double" group="float"/>
<reg name="d2" bitsize="64" regnum="67" type="ieee_double" group="float"/>
<reg name="d3" bitsize="64" regnum="68" type="ieee_double" group="float"/>
<reg name="d4" bitsize="64" regnum="69" type="ieee_double" group="float"/>
<reg name="d5" bitsize="64" regnum="70" type="ieee_double" group="float"/>
<reg name="d6" bitsize="64" regnum="71" type="ieee_double" group="float"/>
<reg name="d7" bitsize="64" regnum="72" type="ieee_double" group="float"/>
<reg name="d8" bitsize="64" regnum="73" type="ieee_double" group="float"/>
<reg name="d9" bitsize="64" regnum="74" type="ieee_double" group="float"/>
<reg name="d10" bitsize="64" regnum="75" type="ieee_double" group="float"/>
<reg name="d11" bitsize="64" regnum="76" type="ieee_double" group="float"/>
<reg name="d12" bitsize="64" regnum="77" type="ieee_double" group="float"/>
<reg name="d13" bitsize="64" regnum="78" type="ieee_double" group="float"/>
<reg name="d14" bitsize="64" regnum="79" type="ieee_double" group="float"/>
<reg name="d15" bitsize="64" regnum="80" type="ieee_double" group="float"/>
</feature>
</target>
David, does LLDB actively maintain register descriptions for 32-bit Arm?
next prev parent reply other threads:[~2022-10-04 17:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 12:30 Luis Machado
2022-09-20 12:47 ` Eli Zaretskii
2022-10-02 13:39 ` Enze Li
2022-10-03 8:27 ` Luis Machado
2022-10-03 17:33 ` John Baldwin
2022-10-03 19:16 ` Pedro Alves
2022-10-04 8:43 ` Luis Machado
2022-10-04 17:08 ` John Baldwin
2022-10-04 17:43 ` Luis Machado [this message]
2022-10-04 21:36 ` John Baldwin
2022-10-05 8:26 ` Luis Machado
2022-10-05 8:36 ` David Spickett
2022-10-05 8:36 ` David Spickett
2022-10-05 16:48 ` John Baldwin
2022-10-05 16:57 ` Richard Earnshaw
2022-10-06 13:02 ` Luis Machado
2022-10-10 14:58 ` Pedro Alves
2022-10-13 7:23 ` Luis Machado
2022-10-13 8:29 ` Pedro Alves
2022-10-13 9:40 ` Luis Machado
2022-10-25 13:54 ` Luis Machado
2022-11-14 14:30 ` Simon Marchi
2022-10-10 14:56 ` Pedro Alves
2022-10-13 7:18 ` Luis Machado
2022-10-13 8:44 ` Pedro Alves
2022-10-13 9:15 ` Luis Machado
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=56653c70-593a-4b8d-ddf7-52f7dd0608f7@arm.com \
--to=luis.machado@arm.com \
--cc=David.Spickett@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=jhb@FreeBSD.org \
--cc=pedro@palves.net \
/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).