public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Custom types in target description XMLs
@ 2021-07-13 19:08 Shahab Vahedi
  2021-07-15 14:37 ` Simon Marchi
  2021-08-02 11:51 ` Shahab Vahedi
  0 siblings, 2 replies; 4+ messages in thread
From: Shahab Vahedi @ 2021-07-13 19:08 UTC (permalink / raw)
  To: gdb

Hello,

I have difficulties defining a custom register type in a target
description XML format. For the sake of argument, consider the
32-bit register below with it's own contrived fields:

bit:   31     ...     11  10  9   8  7  ...  0
      ,-----------------.---.---.---.---------.
      | dont_care_field | g | u | b | version |
      `-----------------^---^---^---^---------'

I've come up with two definitions. One uses the "flag" and the
other uses the "struct" type. However, both have their issues
in representing the correct values. The definitions are as
follows:

-----------------------------8<-----------------------------
<?xml version="1.0"?>

<!DOCTYPE feature SYSTEM "gdb-target.dtd">
<feature name="org.gnu.gdb.arc.fpu">
  <flags id="flag_type" size="4">
    <field name="version" start="0"  end="7"  type="int" />
    <field name="b"       start="8"  end="8"  type="bool"/>
    <field name="u"       start="9"  end="9"  type="bool"/>
    <field name="g"       start="10" end="10" type="bool"/>
    <field name=""        start="11" end="31"            />
  </flags>
  <struct id="struct_type" size="4">
    <field name="version" start="0"  end="7"  type="int" />
    <field name="b"       start="8"  end="8"  type="bool"/>
    <field name="u"       start="9"  end="9"  type="bool"/>
    <field name="g"       start="10" end="10" type="bool"/>
    <field name=""        start="11" end="31"            />
  </struct>
  <reg name="f_reg" bitsize="32" type="flag_type"/>
  <reg name="s_reg" bitsize="32" type="struct_type"/>
</feature>
----------------------------->8-----------------------------

The value reported by GDBstub (QEMU) is 0x1337 for both registers:

0  x   1    3    3    7
     0001 0011 0011 0111

version: 0x37 (55)
b: true
u: true
g: false

However, this is how GDB prints them:

---------------------- [ gdb ] ----------------------
(gdb) info reg $f_reg
f_reg          0x1337              [ version=0 b u ]
-----------------------------------------------------

Here, while "$f_reg" holds the correct value (0x1337), the
"version" field is 0 instead of 55. "b", "u", and "g" fields
are inferred correctly though.

---------------------- [ gdb ] ----------------------
(gdb) info reg $s_reg
s_reg          {
  version = 0x37,
  b = 0xff,
  u = 0xff,
  g = 0x0
} {
  version = 55,
  b = -1,
  u = -1,
  g = false
}
-----------------------------------------------------

The register with struct type on the other hand, interprets
"version" correctly while misjudging the "boolean" fields that
are set.

Am I doing something wrong or this could be a bug in parsing?
If latter is the case, I will dive into the code to find the
root cause. I just need someone to confirm it first.


Thanks,
Shahab

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

* Re: Custom types in target description XMLs
  2021-07-13 19:08 Custom types in target description XMLs Shahab Vahedi
@ 2021-07-15 14:37 ` Simon Marchi
  2021-07-15 17:21   ` Shahab Vahedi
  2021-08-02 11:51 ` Shahab Vahedi
  1 sibling, 1 reply; 4+ messages in thread
From: Simon Marchi @ 2021-07-15 14:37 UTC (permalink / raw)
  To: Shahab Vahedi, gdb

On 2021-07-13 3:08 p.m., Shahab Vahedi via Gdb wrote:
> Hello,
> 
> I have difficulties defining a custom register type in a target
> description XML format. For the sake of argument, consider the
> 32-bit register below with it's own contrived fields:
> 
> bit:   31     ...     11  10  9   8  7  ...  0
>       ,-----------------.---.---.---.---------.
>       | dont_care_field | g | u | b | version |
>       `-----------------^---^---^---^---------'
> 
> I've come up with two definitions. One uses the "flag" and the
> other uses the "struct" type. However, both have their issues
> in representing the correct values. The definitions are as
> follows:
> 
> -----------------------------8<-----------------------------
> <?xml version="1.0"?>
> 
> <!DOCTYPE feature SYSTEM "gdb-target.dtd">
> <feature name="org.gnu.gdb.arc.fpu">
>   <flags id="flag_type" size="4">
>     <field name="version" start="0"  end="7"  type="int" />
>     <field name="b"       start="8"  end="8"  type="bool"/>
>     <field name="u"       start="9"  end="9"  type="bool"/>
>     <field name="g"       start="10" end="10" type="bool"/>
>     <field name=""        start="11" end="31"            />
>   </flags>
>   <struct id="struct_type" size="4">
>     <field name="version" start="0"  end="7"  type="int" />
>     <field name="b"       start="8"  end="8"  type="bool"/>
>     <field name="u"       start="9"  end="9"  type="bool"/>
>     <field name="g"       start="10" end="10" type="bool"/>
>     <field name=""        start="11" end="31"            />
>   </struct>
>   <reg name="f_reg" bitsize="32" type="flag_type"/>
>   <reg name="s_reg" bitsize="32" type="struct_type"/>
> </feature>
> ----------------------------->8-----------------------------
> 
> The value reported by GDBstub (QEMU) is 0x1337 for both registers:
> 
> 0  x   1    3    3    7
>      0001 0011 0011 0111
> 
> version: 0x37 (55)
> b: true
> u: true
> g: false
> 
> However, this is how GDB prints them:
> 
> ---------------------- [ gdb ] ----------------------
> (gdb) info reg $f_reg
> f_reg          0x1337              [ version=0 b u ]
> -----------------------------------------------------
> 
> Here, while "$f_reg" holds the correct value (0x1337), the
> "version" field is 0 instead of 55. "b", "u", and "g" fields
> are inferred correctly though.
> 
> ---------------------- [ gdb ] ----------------------
> (gdb) info reg $s_reg
> s_reg          {
>   version = 0x37,
>   b = 0xff,
>   u = 0xff,
>   g = 0x0
> } {
>   version = 55,
>   b = -1,
>   u = -1,
>   g = false
> }
> -----------------------------------------------------
> 
> The register with struct type on the other hand, interprets
> "version" correctly while misjudging the "boolean" fields that
> are set.
> 
> Am I doing something wrong or this could be a bug in parsing?
> If latter is the case, I will dive into the code to find the
> root cause. I just need someone to confirm it first.

Hi Shahab,

Given the lack of response, I would say that nobody knows that off-hand,
and you would need to dive into the code to check what is happening, if
it's a GDB bug or something else.

Simon

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

* Re: Custom types in target description XMLs
  2021-07-15 14:37 ` Simon Marchi
@ 2021-07-15 17:21   ` Shahab Vahedi
  0 siblings, 0 replies; 4+ messages in thread
From: Shahab Vahedi @ 2021-07-15 17:21 UTC (permalink / raw)
  To: Simon Marchi; +Cc: gdb

Hi Simon,

On Thu, Jul 15, 2021 at 10:37:39AM -0400, Simon Marchi wrote:
> Given the lack of response, I would say that nobody knows that off-hand,
> and you would need to dive into the code to check what is happening, if
> it's a GDB bug or something else.

I was just about to write another email. I have investigated both of the
problems and they seem like a bug to me.

The following change fixes the "field" type issue:

------------------------8<------------------------
diff --git a/gdb/valprint.c b/gdb/valprint.c
index 0749f38983e..91602b41274 100644
--- a/gdb/valprint.c
+++ b/gdb/valprint.c
@@ -1186,7 +1186,7 @@ val_print_type_code_flags (struct type *type, ...
 	    {
 	      unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
 	      ULONGEST field_val
-		= val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);
+		= val >> TYPE_FIELD_BITPOS (type, field);
 
 	      if (field_len < sizeof (ULONGEST) * TARGET_CHAR_BIT)
 		field_val &= ((ULONGEST) 1 << field_len) - 1;
------------------------>8------------------------

And this one solves the "struct" type problem:
------------------------8<------------------------
diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index 43c05d344d0..68e65ef8bb5 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -5805,7 +5805,7 @@ gdbtypes_post_init (struct gdbarch *gdbarch)
   builtin_type->builtin_string
     = arch_type (gdbarch, TYPE_CODE_STRING, TARGET_CHAR_BIT, "string");
   builtin_type->builtin_bool
-    = arch_type (gdbarch, TYPE_CODE_BOOL, TARGET_CHAR_BIT, "bool");
+    = arch_boolean_type (gdbarch, TARGET_CHAR_BIT, 1, "bool");
 
   /* The following three are about decimal floating point types, which
      are 32-bits, 64-bits and 128-bits respectively.  */
------------------------>8------------------------

I will file two separate bugs and then submit the two patches with the
explanations.


Cheers,
Shahab

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

* Re: Custom types in target description XMLs
  2021-07-13 19:08 Custom types in target description XMLs Shahab Vahedi
  2021-07-15 14:37 ` Simon Marchi
@ 2021-08-02 11:51 ` Shahab Vahedi
  1 sibling, 0 replies; 4+ messages in thread
From: Shahab Vahedi @ 2021-08-02 11:51 UTC (permalink / raw)
  To: gdb

For the record, this problem was reported under PR28103 [1] and
PR28104 [2].

It has been resolved by the following patches in master and
gdb-11-branch:

   gdb: Fix numerical field extraction for target ... [3][4]
   gdb: Make the builtin "boolean" type an unsigned type [5][6]


Cheers,
Shahab

[1] Incorrect extraction of integer fields in target description...
https://sourceware.org/PR28103

[2] Incorrect extraction of boolean fields in target description...
https://sourceware.org/PR28104

[3] [master] gdb: Fix numerical field extraction for target...
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c9bd985

[4] [gdb-11] gdb: Fix numerical field extraction for target...
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=70417f2

[5] [master] gdb: Make the builtin "boolean" type an unsigned type
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=91254b9

[6] [gdb-11] gdb: Make the builtin "boolean" type an unsigned type
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e4c1aea

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

end of thread, other threads:[~2021-08-02 11:51 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-13 19:08 Custom types in target description XMLs Shahab Vahedi
2021-07-15 14:37 ` Simon Marchi
2021-07-15 17:21   ` Shahab Vahedi
2021-08-02 11:51 ` Shahab Vahedi

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