public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] [gdb/doc] aarch64: Expand documentation of XML features
@ 2023-02-23  9:52 Luis Machado
  2023-02-23 11:04 ` Eli Zaretskii
  2023-02-24 18:41 ` [PATCH, v2] " Luis Machado
  0 siblings, 2 replies; 7+ messages in thread
From: Luis Machado @ 2023-02-23  9:52 UTC (permalink / raw)
  To: gdb-patches; +Cc: eliz

Similar to the arm target documentation situation, the documentation of the
XML features for AArch64 targets is rather brief.  I have received the same
feedback that what gdb carries in the documentation is quite unclear from the
perspective of what debugging servers should define in the XML features, how and
what the outcome is in gdb.

This patch attempts to clarify a bit more what all the possible features are.
---
 gdb/doc/gdb.texinfo | 199 ++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 191 insertions(+), 8 deletions(-)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 3c3a9f98de2..50bc6f733e2 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -47761,20 +47761,203 @@ registers using the capitalization used in the description.
 @subsection AArch64 Features
 @cindex target descriptions, AArch64 features
 
+@subsubsection AArch64 core registers feature
+
 The @samp{org.gnu.gdb.aarch64.core} feature is required for AArch64
-targets.  It should contain registers @samp{x0} through @samp{x30},
-@samp{sp}, @samp{pc}, and @samp{cpsr}.
+targets.  It must contain the following:
+
+@itemize @minus
+@item
+@samp{x0} through @samp{x30}, with size of 64-bit.  Register @samp{x30} is
+also known as the link register @samp{lr}.
+@item
+@samp{sp}, the stack pointer register or @samp{x31}.  It is 64-bit in size and
+has a type of @samp{data_ptr}.
+@item
+@samp{pc}, the program counter register. It is 64-bit in size and has a type
+of @samp{code_ptr}.
+@item
+@samp{cpsr}, the current program status register.  It is 32-bit in size
+and has a custom flags type.
+@end itemize
+
+The @samp{cpsr} flags type gets updated based on new architectural
+features.  The current layout can be found in the aarch64-core.xml file.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 floating-point registers feature
 
 The @samp{org.gnu.gdb.aarch64.fpu} feature is optional.  If present,
-it should contain registers @samp{v0} through @samp{v31}, @samp{fpsr},
-and @samp{fpcr}.
+it must contain the following registers:
+
+@itemize @minus
+@item
+@samp{v0} through @samp{v31}, the vector registers with size of 128-bit.  The
+type is a custom vector type.
+@item
+@samp{fpsr}, the floating-point status register.  It is 32-bit in size and has
+a custom flags type.
+@item
+@samp{fpcr}, the floating-point control register.  It is 32-bit in size and has
+a custom flags type.
+@end itemize
+
+The types for the vector registers, @samp{fpsr} and @samp{fpcr} registers can
+be found in the aarch64-fpu.xml file.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 SVE registers feature
 
 The @samp{org.gnu.gdb.aarch64.sve} feature is optional.  If present,
-it should contain registers @samp{z0} through @samp{z31}, @samp{p0}
-through @samp{p15}, @samp{ffr} and @samp{vg}.
+it means the target supports the Scalable Vector Extension and must contain
+the following registers:
+
+@itemize @minus
+@item
+@samp{z0} through @samp{z31}, the scalable vector registers.  Their sizes are
+variable and a multiple of 128-bit up to a maximum of 2048-bit.  Their type is
+a custom union type that helps visualize different sizes of sub-vectors.
+@item
+@samp{fpsr}, the floating-point status register.  It is 32-bit in size and has
+a custom flags type.
+@item
+@samp{fpcr}, the floating-point control register.  It is 32-bit in size and has
+a custom flags type.
+@item
+@samp{p0} through @samp{p15}, the predicate registers.  Their sizes are
+variable, based on the current vector length, and a multiple of 16-bit.  Their
+types are a custom union to help visualize sub-elements.
+@item
+@samp{ffr}, the First Fault register.  It has a variable size based on the
+current vector length and is a multiple of 16-bit.  The type is the same as
+the predicate registers.
+@item
+@samp{vg}, the vector granule.  It represents the number of 64-bit chunks in
+a @samp{z} register.  It is closely associated with the current vector
+length.  It has a type of @samp{int}.
+@end itemize
+
+When @value{GDBN} sees the SVE feature, it will assume the Scalable Vector
+Extension is supported, and will adjust the sizes of the @samp{z}, @samp{p}
+and @samp{ffr} registers accordingly, based on the value of @samp{vg}.
 
-The @samp{org.gnu.gdb.aarch64.pauth} feature is optional.  If present,
-it should contain registers @samp{pauth_dmask} and @samp{pauth_cmask}.
+@value{GDBN} will also create pseudo-registers equivalent to the @samp{v}
+vector registers from the @samp{org.gnu.gdb.aarch64.fpu} feature.
+
+The first 128 bits of the @samp{z} registers overlap the 128 bits of the
+@samp{v} registers, so changing one will trigger a change to the other.
+
+For the types of the @samp{z}, @samp{p} and @samp{ffr} registers, please
+check the aarch64-sve.c file.  No XML file is available for this feature
+because it is dynamically generated based on the current vector length.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 Pointer Authentication registers feature
+
+The @samp{org.gnu.gdb.aarch64.pauth} optional feature was introduced so
+@value{GDBN} could detect support for the Pointer Authentication
+extension.  If present, it must contain one of two possible register sets.
+
+Pointer Authentication masks for user-mode:
+
+@itemize @minus
+@item
+@samp{pauth_dmask}, the user-mode pointer authentication mask for data
+pointers.  It is 64-bit in size.
+@item
+@samp{pauth_cmask}, the user-mode pointer authentication mask for code
+pointers.  It is 64-bit in size.
+@end itemize
+
+Pointer Authentication masks for user-mode and kernel-mode:
+
+@itemize @minus
+@item
+@samp{pauth_dmask}, the user-mode pointer authentication mask for data
+pointers.  It is 64-bit in size.
+@item
+@samp{pauth_cmask}, the user-mode pointer authentication mask for code
+pointers.  It is 64-bit in size.
+@item
+@samp{pauth_dmask_high}, the kernel-mode pointer authentication mask for
+data pointers.  It is 64-bit in size.
+@item
+@samp{pauth_cmask_high}, the kernel-mode pointer authentication mask for
+code pointers.  It is 64-bit in size.
+@end itemize
+
+If @value{GDBN} sees any of the two sets of registers in this feature, it will
+assume the target is capable of signing pointers.  If so, @value{GDBN} will
+decorate backtraces with a @samp{[PAC]} marker alongside a function that
+has a signed link register value that needs to be unmasked/decoded.
+
+@value{GDBN} will also use the masks to remove non-address bits from pointers.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 TLS registers feature
+
+The @samp{org.gnu.gdb.aarch64.tls} optional feature was introduced to expose
+the TLS registers to @value{GDBN}.  If present, it must contain either one
+of the following register sets.
+
+Only @samp{tpidr}:
+
+@itemize @minus
+@item
+@samp{tpidr}, the software thread id register.  It is 64-bit in size and has a
+type of @samp{data_ptr}.
+@end itemize
+
+Both @samp{tpidr} and @samp{tpidr2}.
+
+@itemize @minus
+@item
+@samp{tpidr}, the software thread id register.  It is 64-bit in size and has a
+type of @samp{data_ptr}.
+@item
+@samp{tpidr2}, the second software thread id register.  It is 64-bit in size
+and has a type of @samp{data_ptr}.  It may be used in the future alongside
+the Scalable Matrix Extension for a lazy restore scheme.
+@end itemize
+
+If @value{GDBN} sees this feature, it will attempt to find one of the
+variations of the register set.  If @samp{tpidr2} is available,
+@value{GDBN} may act on it to display additional data in the future.
+
+There is no XML for this feature as the presence of @samp{tpidr2} is
+determined dynamically at runtime.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 MTE registers feature
+
+The @samp{org.gnu.gdb.aarch64.mte} optional feature was introduced so
+@value{GDBN} could detect support for the Memory Tagging Extension and
+control memory tagging settings.  If present, this feature must have the
+following register:
+
+@itemize @minus
+@item
+@samp{tag_ctl}, the tag control register.  It is 64-bit in size and has a type
+of @samp{uint64}.
+@end itemize
+
+Memory Tagging detection is done via a runtime check though, so the presence
+of this feature and register is not enough to enable memory tagging support.
+
+This restriction may be lifted in the future.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
 
 @node ARC Features
 @subsection ARC Features
-- 
2.25.1


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] [gdb/doc] aarch64: Expand documentation of XML features
  2023-02-23  9:52 [PATCH] [gdb/doc] aarch64: Expand documentation of XML features Luis Machado
@ 2023-02-23 11:04 ` Eli Zaretskii
  2023-02-23 13:33   ` Luis Machado
  2023-02-24 18:41 ` [PATCH, v2] " Luis Machado
  1 sibling, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2023-02-23 11:04 UTC (permalink / raw)
  To: Luis Machado; +Cc: gdb-patches

> From: Luis Machado <luis.machado@arm.com>
> CC: <eliz@gnu.org>
> Date: Thu, 23 Feb 2023 09:52:44 +0000
> 
> Similar to the arm target documentation situation, the documentation of the
> XML features for AArch64 targets is rather brief.  I have received the same
> feedback that what gdb carries in the documentation is quite unclear from the
> perspective of what debugging servers should define in the XML features, how and
> what the outcome is in gdb.
> 
> This patch attempts to clarify a bit more what all the possible features are.

Thanks.

>  The @samp{org.gnu.gdb.aarch64.core} feature is required for AArch64
> -targets.  It should contain registers @samp{x0} through @samp{x30},
> -@samp{sp}, @samp{pc}, and @samp{cpsr}.
> +targets.  It must contain the following:
> +
> +@itemize @minus
> +@item
> +@samp{x0} through @samp{x30}, with size of 64-bit.  Register @samp{x30} is

This doesn't say these are registers, please add that.

> +also known as the link register @samp{lr}.

The "link register" part should probably be in @dfn, and "@samp{lr}"
should probably be ", or @samp{lr}", as it's an alternative name AFAIU.

> +@item
> +@samp{pc}, the program counter register. It is 64-bit in size and has a type
> +of @samp{code_ptr}.                    ^^

Two spaces there, please.

> +The @samp{cpsr} flags type gets updated based on new architectural
> +features.

"flags type gets updated" sounds awkward and confusing.  What did you
mean by that? what is updated?

> +@item
> +@samp{v0} through @samp{v31}, the vector registers with size of 128-bit.  The
                                                                   ^^^^^^^
The dash is redundant there and should be dropped.

> +@samp{z0} through @samp{z31}, the scalable vector registers.  Their sizes are
> +variable and a multiple of 128-bit up to a maximum of 2048-bit.  Their type is

Same here.

> +@samp{p0} through @samp{p15}, the predicate registers.  Their sizes are
> +variable, based on the current vector length, and a multiple of 16-bit.  Their

And here.

> +@item
> +@samp{ffr}, the First Fault register.  It has a variable size based on the
> +current vector length and is a multiple of 16-bit.  The type is the same as

And here.  Also, "and is" is ambiguous: you mean the size is a
multiple, but the text can be interpreted as alluding to the register,
not its size.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] [gdb/doc] aarch64: Expand documentation of XML features
  2023-02-23 11:04 ` Eli Zaretskii
@ 2023-02-23 13:33   ` Luis Machado
  2023-02-23 15:06     ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Luis Machado @ 2023-02-23 13:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gdb-patches

On 2/23/23 11:04, Eli Zaretskii wrote:
>> From: Luis Machado <luis.machado@arm.com>
>> CC: <eliz@gnu.org>
>> Date: Thu, 23 Feb 2023 09:52:44 +0000
>>
>> Similar to the arm target documentation situation, the documentation of the
>> XML features for AArch64 targets is rather brief.  I have received the same
>> feedback that what gdb carries in the documentation is quite unclear from the
>> perspective of what debugging servers should define in the XML features, how and
>> what the outcome is in gdb.
>>
>> This patch attempts to clarify a bit more what all the possible features are.
> 
> Thanks.
> 
>>   The @samp{org.gnu.gdb.aarch64.core} feature is required for AArch64
>> -targets.  It should contain registers @samp{x0} through @samp{x30},
>> -@samp{sp}, @samp{pc}, and @samp{cpsr}.
>> +targets.  It must contain the following:
>> +
>> +@itemize @minus
>> +@item
>> +@samp{x0} through @samp{x30}, with size of 64-bit.  Register @samp{x30} is
> 
> This doesn't say these are registers, please add that.
> 
>> +also known as the link register @samp{lr}.
> 
> The "link register" part should probably be in @dfn, and "@samp{lr}"
> should probably be ", or @samp{lr}", as it's an alternative name AFAIU.
> 
>> +@item
>> +@samp{pc}, the program counter register. It is 64-bit in size and has a type
>> +of @samp{code_ptr}.                    ^^
> 
> Two spaces there, please.
> 
>> +The @samp{cpsr} flags type gets updated based on new architectural
>> +features.
> 
> "flags type gets updated" sounds awkward and confusing.  What did you
> mean by that? what is updated?
> 

Some flags/fields are reserved to be used in future extensions of the architecture.

For example, suppose bit 26 in 32-bit register is undefined, but then gets defined for a new
architecture extension. We need to update the XML to reflect that.

>> +@item
>> +@samp{v0} through @samp{v31}, the vector registers with size of 128-bit.  The
>                                                                     ^^^^^^^
> The dash is redundant there and should be dropped.
> 
>> +@samp{z0} through @samp{z31}, the scalable vector registers.  Their sizes are
>> +variable and a multiple of 128-bit up to a maximum of 2048-bit.  Their type is
> 
> Same here.
> 
>> +@samp{p0} through @samp{p15}, the predicate registers.  Their sizes are
>> +variable, based on the current vector length, and a multiple of 16-bit.  Their
> 
> And here.
> 
>> +@item
>> +@samp{ffr}, the First Fault register.  It has a variable size based on the
>> +current vector length and is a multiple of 16-bit.  The type is the same as
> 
> And here.  Also, "and is" is ambiguous: you mean the size is a
> multiple, but the text can be interpreted as alluding to the register,
> not its size.

Indeed. I'll fix that and the other comments.

Thanks!

> 
> Reviewed-By: Eli Zaretskii <eliz@gnu.org>


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] [gdb/doc] aarch64: Expand documentation of XML features
  2023-02-23 13:33   ` Luis Machado
@ 2023-02-23 15:06     ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2023-02-23 15:06 UTC (permalink / raw)
  To: Luis Machado; +Cc: gdb-patches

> Date: Thu, 23 Feb 2023 13:33:08 +0000
> Cc: gdb-patches@sourceware.org
> From: Luis Machado <luis.machado@arm.com>
> 
> On 2/23/23 11:04, Eli Zaretskii wrote:
> > 
> >> +The @samp{cpsr} flags type gets updated based on new architectural
> >> +features.
> > 
> > "flags type gets updated" sounds awkward and confusing.  What did you
> > mean by that? what is updated?
> > 
> 
> Some flags/fields are reserved to be used in future extensions of the architecture.
> 
> For example, suppose bit 26 in 32-bit register is undefined, but then gets defined for a new
> architecture extension. We need to update the XML to reflect that.

Then I suggest something like

  The semantics of the individual flags in @samp{cpsr} can change as
  new architectural features are added.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH, v2] [gdb/doc] aarch64: Expand documentation of XML features
  2023-02-23  9:52 [PATCH] [gdb/doc] aarch64: Expand documentation of XML features Luis Machado
  2023-02-23 11:04 ` Eli Zaretskii
@ 2023-02-24 18:41 ` Luis Machado
  2023-02-24 19:25   ` Eli Zaretskii
  1 sibling, 1 reply; 7+ messages in thread
From: Luis Machado @ 2023-02-24 18:41 UTC (permalink / raw)
  To: gdb-patches; +Cc: eliz

Similar to the arm target documentation situation, the documentation of the
XML features for AArch64 targets is rather brief.  I have received the same
feedback that what gdb carries in the documentation is quite unclear from the
perspective of what debugging servers should define in the XML features, how and
what the outcome is in gdb.

This patch attempts to clarify a bit more what all the possible features are.
---
 gdb/doc/gdb.texinfo | 210 ++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 202 insertions(+), 8 deletions(-)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index efb059efd46..4e259acb1cd 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -47761,20 +47761,214 @@ registers using the capitalization used in the description.
 @subsection AArch64 Features
 @cindex target descriptions, AArch64 features
 
+@subsubsection AArch64 core registers feature
+
 The @samp{org.gnu.gdb.aarch64.core} feature is required for AArch64
-targets.  It should contain registers @samp{x0} through @samp{x30},
-@samp{sp}, @samp{pc}, and @samp{cpsr}.
+targets.  It must contain the following:
+
+@itemize @minus
+@item
+@samp{x0} through @samp{x30}, the general purpose registers, with size of
+64 bits.  Register @samp{x30} is also known as the @dfn{link register},
+or @samp{lr}.
+@item
+@samp{sp}, the stack pointer register or @samp{x31}.  It is 64 bits in size and
+has a type of @samp{data_ptr}.
+@item
+@samp{pc}, the program counter register.  It is 64 bits in size and has a type
+of @samp{code_ptr}.
+@item
+@samp{cpsr}, the current program status register.  It is 32 bits in size
+and has a custom flags type.
+@end itemize
+
+The semantics of the individual flags and fields in @samp{cpsr} can change as
+new architectural features are added.  The current layout can be found in the
+aarch64-core.xml file.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 floating-point registers feature
 
 The @samp{org.gnu.gdb.aarch64.fpu} feature is optional.  If present,
-it should contain registers @samp{v0} through @samp{v31}, @samp{fpsr},
-and @samp{fpcr}.
+it must contain the following registers:
+
+@itemize @minus
+@item
+@samp{v0} through @samp{v31}, the vector registers with size of 128 bits.  The
+type is a custom vector type.
+@item
+@samp{fpsr}, the floating-point status register.  It is 32 bits in size and has
+a custom flags type.
+@item
+@samp{fpcr}, the floating-point control register.  It is 32 bits in size and has
+a custom flags type.
+@end itemize
+
+The semantics of the individual flags and fields in @samp{fpsr} and @samp{fpcr}
+can change as new architectural features are added.
+
+The types for the vector registers, @samp{fpsr} and @samp{fpcr} registers can
+be found in the aarch64-fpu.xml file.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 SVE registers feature
 
 The @samp{org.gnu.gdb.aarch64.sve} feature is optional.  If present,
-it should contain registers @samp{z0} through @samp{z31}, @samp{p0}
-through @samp{p15}, @samp{ffr} and @samp{vg}.
+it means the target supports the Scalable Vector Extension and must contain
+the following registers:
+
+@itemize @minus
+@item
+@samp{z0} through @samp{z31}, the scalable vector registers.  Their sizes are
+variable and a multiple of 128 bits up to a maximum of 2048 bit.  Their type is
+a custom union type that helps visualize different sizes of sub-vectors.
+@item
+@samp{fpsr}, the floating-point status register.  It is 32 bits in size and has
+a custom flags type.
+@item
+@samp{fpcr}, the floating-point control register.  It is 32 bits in size and has
+a custom flags type.
+@item
+@samp{p0} through @samp{p15}, the predicate registers.  Their sizes are
+variable, based on the current vector length, and a multiple of
+16 bits.  Their types are a custom union to help visualize sub-elements.
+@item
+@samp{ffr}, the First Fault register.  It has a variable size based on the
+current vector length and is a multiple of 16 bits.  The type is the same as
+the predicate registers.
+@item
+@samp{vg}, the vector granule.  It represents the number of 64 bits chunks in
+a @samp{z} register.  It is closely associated with the current vector
+length.  It has a type of @samp{int}.
+@end itemize
+
+When @value{GDBN} sees the SVE feature, it will assume the Scalable Vector
+Extension is supported, and will adjust the sizes of the @samp{z}, @samp{p}
+and @samp{ffr} registers accordingly, based on the value of @samp{vg}.
+
+@value{GDBN} will also create pseudo-registers equivalent to the @samp{v}
+vector registers from the @samp{org.gnu.gdb.aarch64.fpu} feature.
+
+The first 128 bits of the @samp{z} registers overlap the 128 bits of the
+@samp{v} registers, so changing one will trigger a change to the other.
+
+For the types of the @samp{z}, @samp{p} and @samp{ffr} registers, please
+check the aarch64-sve.c file.  No XML file is available for this feature
+because it is dynamically generated based on the current vector length.
+
+The semantics of the individual flags and fields in @samp{fpsr} and @samp{fpcr}
+can change as new architectural features are added.
+
+The types for the @samp{fpsr} and @samp{fpcr} registers can be found in the
+aarch64-sve.c file, and should match what is described in aarch64-fpu.xml.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 Pointer Authentication registers feature
+
+The @samp{org.gnu.gdb.aarch64.pauth} optional feature was introduced so
+@value{GDBN} could detect support for the Pointer Authentication
+extension.  If present, it must contain one of two possible register sets.
+
+Pointer Authentication masks for user-mode:
 
-The @samp{org.gnu.gdb.aarch64.pauth} feature is optional.  If present,
-it should contain registers @samp{pauth_dmask} and @samp{pauth_cmask}.
+@itemize @minus
+@item
+@samp{pauth_dmask}, the user-mode pointer authentication mask for data
+pointers.  It is 64 bits in size.
+@item
+@samp{pauth_cmask}, the user-mode pointer authentication mask for code
+pointers.  It is 64 bits in size.
+@end itemize
+
+Pointer Authentication masks for user-mode and kernel-mode:
+
+@itemize @minus
+@item
+@samp{pauth_dmask}, the user-mode pointer authentication mask for data
+pointers.  It is 64 bits in size.
+@item
+@samp{pauth_cmask}, the user-mode pointer authentication mask for code
+pointers.  It is 64 bits in size.
+@item
+@samp{pauth_dmask_high}, the kernel-mode pointer authentication mask for
+data pointers.  It is 64 bits in size.
+@item
+@samp{pauth_cmask_high}, the kernel-mode pointer authentication mask for
+code pointers.  It is 64 bits in size.
+@end itemize
+
+If @value{GDBN} sees any of the two sets of registers in this feature, it will
+assume the target is capable of signing pointers.  If so, @value{GDBN} will
+decorate backtraces with a @samp{[PAC]} marker alongside a function that
+has a signed link register value that needs to be unmasked/decoded.
+
+@value{GDBN} will also use the masks to remove non-address bits from pointers.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 TLS registers feature
+
+The @samp{org.gnu.gdb.aarch64.tls} optional feature was introduced to expose
+the TLS registers to @value{GDBN}.  If present, it must contain either one
+of the following register sets.
+
+Only @samp{tpidr}:
+
+@itemize @minus
+@item
+@samp{tpidr}, the software thread id register.  It is 64 bits in size and has a
+type of @samp{data_ptr}.
+@end itemize
+
+Both @samp{tpidr} and @samp{tpidr2}.
+
+@itemize @minus
+@item
+@samp{tpidr}, the software thread id register.  It is 64 bits in size and has a
+type of @samp{data_ptr}.
+@item
+@samp{tpidr2}, the second software thread id register.  It is 64 bits in size
+and has a type of @samp{data_ptr}.  It may be used in the future alongside
+the Scalable Matrix Extension for a lazy restore scheme.
+@end itemize
+
+If @value{GDBN} sees this feature, it will attempt to find one of the
+variations of the register set.  If @samp{tpidr2} is available,
+@value{GDBN} may act on it to display additional data in the future.
+
+There is no XML for this feature as the presence of @samp{tpidr2} is
+determined dynamically at runtime.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
+
+@subsubsection AArch64 MTE registers feature
+
+The @samp{org.gnu.gdb.aarch64.mte} optional feature was introduced so
+@value{GDBN} could detect support for the Memory Tagging Extension and
+control memory tagging settings.  If present, this feature must have the
+following register:
+
+@itemize @minus
+@item
+@samp{tag_ctl}, the tag control register.  It is 64 bits in size and has a type
+of @samp{uint64}.
+@end itemize
+
+Memory Tagging detection is done via a runtime check though, so the presence
+of this feature and register is not enough to enable memory tagging support.
+
+This restriction may be lifted in the future.
+
+Extra registers are allowed in this feature, but they will not affect
+@value{GDBN}.
 
 @node ARC Features
 @subsection ARC Features
-- 
2.25.1


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH, v2] [gdb/doc] aarch64: Expand documentation of XML features
  2023-02-24 18:41 ` [PATCH, v2] " Luis Machado
@ 2023-02-24 19:25   ` Eli Zaretskii
  2023-03-13 11:32     ` Luis Machado
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2023-02-24 19:25 UTC (permalink / raw)
  To: Luis Machado; +Cc: gdb-patches

> From: Luis Machado <luis.machado@arm.com>
> CC: <eliz@gnu.org>
> Date: Fri, 24 Feb 2023 18:41:23 +0000
> 
> Similar to the arm target documentation situation, the documentation of the
> XML features for AArch64 targets is rather brief.  I have received the same
> feedback that what gdb carries in the documentation is quite unclear from the
> perspective of what debugging servers should define in the XML features, how and
> what the outcome is in gdb.
> 
> This patch attempts to clarify a bit more what all the possible features are.
> ---
>  gdb/doc/gdb.texinfo | 210 ++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 202 insertions(+), 8 deletions(-)

Thanks.

Approved-By: Eli Zaretskii <eliz@gnu.org>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH, v2] [gdb/doc] aarch64: Expand documentation of XML features
  2023-02-24 19:25   ` Eli Zaretskii
@ 2023-03-13 11:32     ` Luis Machado
  0 siblings, 0 replies; 7+ messages in thread
From: Luis Machado @ 2023-03-13 11:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gdb-patches

On 2/24/23 19:25, Eli Zaretskii wrote:
>> From: Luis Machado <luis.machado@arm.com>
>> CC: <eliz@gnu.org>
>> Date: Fri, 24 Feb 2023 18:41:23 +0000
>>
>> Similar to the arm target documentation situation, the documentation of the
>> XML features for AArch64 targets is rather brief.  I have received the same
>> feedback that what gdb carries in the documentation is quite unclear from the
>> perspective of what debugging servers should define in the XML features, how and
>> what the outcome is in gdb.
>>
>> This patch attempts to clarify a bit more what all the possible features are.
>> ---
>>   gdb/doc/gdb.texinfo | 210 ++++++++++++++++++++++++++++++++++++++++++--
>>   1 file changed, 202 insertions(+), 8 deletions(-)
> 
> Thanks.
> 
> Approved-By: Eli Zaretskii <eliz@gnu.org>

Thanks Eli. Pushed now.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-03-13 11:32 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-23  9:52 [PATCH] [gdb/doc] aarch64: Expand documentation of XML features Luis Machado
2023-02-23 11:04 ` Eli Zaretskii
2023-02-23 13:33   ` Luis Machado
2023-02-23 15:06     ` Eli Zaretskii
2023-02-24 18:41 ` [PATCH, v2] " Luis Machado
2023-02-24 19:25   ` Eli Zaretskii
2023-03-13 11:32     ` Luis Machado

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).