[Bug server/28822] New: sh4 gdbserver crash

[Bug server/28822] New: sh4 gdbserver crash

[nkulikov at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28822

            Bug ID: 28822
           Summary: sh4 gdbserver crash
           Product: gdb
           Version: 11.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: server
          Assignee: unassigned at sourceware dot org
          Reporter: nkulikov at gmail dot com
  Target Milestone: ---

gdbserver crashes when gdb is connecting to remote (couple printfs added to
dump variables):

$  ./gdbserver :55555 /bin/ls
Process /bin/ls created; pid = 1356
Listening on port 55555
Remote debugging from host 192.168.254.44, port 45206
current_thread = 0x48a5e8                           <- extra printf
tdesc->xmltarget = (nil)                            <- extra printf
tdesc->features.empty = 0, tdesc->arch = (nil)      <- extra printf
tdesc.cc:200: A problem internal to GDBserver has been detected.
const char* tdesc_get_features_xml(const target_desc*): Assertion
`tdesc->xmltarget != NULL || (!tdesc->features.empty () && tdesc->arch !=
NULL)' failed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/28822] sh4 gdbserver crash

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28822

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aburgess at redhat dot com

--- Comment #1 from Andrew Burgess <aburgess at redhat dot com> ---
The following is just from looking at the code, I've not tested anything, so
take this all with a pinch of salt...

I think the important bit from your printfs is 'tdesc->arch = (nil)', it looks
like you have a features list, but no architecture set.

The sh target description is setup in a generated file, for those without a sh
build, we can just enter the gdbserver build directory, and do:

  $ make reg-sh-generated.cc

The you can check out the new file reg-sh-generated.cc.  Notice that there's no
call to set_tdesc_architecture in here.

I would be tempted to try adding a call to set_tdesc_architecture into either
initialize_low_arch or sh_target::low_arch_setup (in linux-sh-low.cc),
something like:

  set_tdesc_architecture (tdesc_sh, "....");

obviously replace "...." with a suitable string for this architecture name,
there's lots to choose from in bfd/cpu-sh.c, so I can't help much there.

What's not clear to me is where the set_tdesc_architecture call is _actually_
supposed to live for sh... but maybe if you try the above we can know if that
will solve the problem or not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/28822] sh4 gdbserver crash

[nkulikov at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28822

--- Comment #2 from Nicholas Kulikov <nkulikov at gmail dot com> ---
Created attachment 13934
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13934&action=edit
gdb-server-logs

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/28822] sh4 gdbserver crash

[nkulikov at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28822

--- Comment #3 from Nicholas Kulikov <nkulikov at gmail dot com> ---
Thanks for feedback!

It was first idea which I got after looking at code. However `tdesc_sh` points
to constant object, so I've decided to make another hack — change generator
which produce `reg-sh-generated.cc`:

--- a/gdb/regformats/regdat.sh  2022-01-27 10:28:26.203607929 +0300
+++ b/gdb/regformats/regdat.sh  2022-01-27 10:29:50.819415389 +0300
@@ -195,6 +195,7 @@

   init_target_desc (result, expedite_regs_${name});

+  result->arch = "${name}";
   tdesc_${name} = result;
 }
 EOF

That is not quite good solution but helped to check idea...

I've checked two variants: "sh" (when use ${name}) and "sh4" (hardcoded value
which more relevant to target board — STi7105 SoC).

Both variants allow to bypass assertion (and immediate crash) but lead to
another one issue: "warning: while parsing target description: not well-formed
(invalid token)"


(gdb) target remote 192.168.254.10:55555
`target:/bin/busybox' has disappeared; keeping its symbols.
Remote debugging using 192.168.254.10:55555
target description (line 1): Starting:
<?xml version="1.0"?>
<!DOCTYPE target SYSTEM "gdb-target.dtd">
<target>
  <architecture>sh4</architecture>
  <feature name="sh">
    <reg name="r0" bitsize="32" type="<unknown>" regnum="0" save-restore="no"/>
...skip for clarity...
    <reg name="" bitsize="32" type="<unknown>" regnum="0" save-restore="no"/>
  </feature>
</target>

target description (line 3): Entering element <target>
target description (line 4): Entering element <architecture>
target description (line 4): Leaving element <architecture>
target description (line 5): Entering element <feature>
warning: while parsing target description: not well-formed (invalid token)
warning: Could not load XML target description; ignoring
threads (line 1): Starting:
<threads>
<thread id="p4ca.4ca" core="0"/>
</threads>

threads (line 1): Entering element <threads>
threads (line 1): Ignoring unknown attribute version
threads (line 2): Entering element <thread>
threads (line 2): Parsing attribute id="p4ca.4ca"
threads (line 2): Parsing attribute core="0"
threads (line 2): Leaving element <thread>
threads (line 3): Leaving element <threads>
target library list (line 1): Starting:
<library-list-svr4 version="1.0"/>
target library list (line 1): Entering element <library-list-svr4>
target library list (line 1): Parsing attribute version="1.0"
target library list (line 1): Leaving element <library-list-svr4>
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
threads (line 1): Starting:
<threads>
<thread id="p4ca.4ca" core="0"/>
</threads>

threads (line 1): Entering element <threads>
threads (line 1): Ignoring unknown attribute version
threads (line 2): Entering element <thread>
threads (line 2): Parsing attribute id="p4ca.4ca"
threads (line 2): Parsing attribute core="0"
threads (line 2): Leaving element <thread>
threads (line 3): Leaving element <threads>
0x29559368 in ?? ()

It seems XML parser does not like '<' in type value:

<reg name="r0" bitsize="32" type="<unknown>" regnum="0" save-restore="no"/>

Ok, I've made another one hack:

--- a/gdbsupport/tdesc.cc       2022-01-27 20:10:41.348756159 +0300
+++ b/gdbsupport/tdesc.cc       2022-01-27 20:10:54.868697299 +0300
@@ -27,7 +27,7 @@
     save_restore (save_restore_),
     group (group_ != NULL ? group_ : ""),
     bitsize (bitsize_),
-    type (type_ != NULL ? type_ : "<unknown>")
+    type (type_ != NULL ? type_ : "uint32")
 {
   /* If the register's type is target-defined, look it up now.  We may not
      have easy access to the containing feature when we want it later.  */

And of course faced with one more error: "warning: Target-supplied registers
are not supported by the current architecture" :)


(gdb) target remote 192.168.254.10:55555
`target:/bin/busybox' has disappeared; keeping its symbols.
Remote debugging using 192.168.254.10:55555
target description (line 1): Starting:
<?xml version="1.0"?>
<!DOCTYPE target SYSTEM "gdb-target.dtd">
<target>
  <architecture>sh4</architecture>
  <feature name="sh">
    <reg name="r0" bitsize="32" type="uint32" regnum="0" save-restore="no"/>
...skip for clarity...
  </feature>
</target>

target description (line 3): Entering element <target>
target description (line 4): Entering element <architecture>
target description (line 4): Leaving element <architecture>
target description (line 5): Entering element <feature>
target description (line 6): Entering element <reg>
target description (line 6): Leaving element <reg>
...skip for clarity...
target description (line 67): XInclude processing succeeded.
target description (line 1): Starting:

<!DOCTYPE target SYSTEM "gdb-target.dtd">
<target>
  <architecture>sh4</architecture>
  <feature name="sh">
    <reg name="r0" bitsize="32" type="uint32" regnum="0" save-restore="no"/>
...skip for clarity...
  </feature>
</target>

target description (line 3): Entering element <target>
target description (line 3): Parsing attribute version="1.0"
target description (line 4): Entering element <architecture>
target description (line 4): Leaving element <architecture>
target description (line 5): Entering element <feature>
target description (line 5): Parsing attribute name="sh"
target description (line 6): Entering element <reg>
target description (line 6): Parsing attribute name="r0"
target description (line 6): Parsing attribute bitsize="32"
target description (line 6): Parsing attribute regnum="0"
target description (line 6): Parsing attribute type="uint32"
target description (line 6): Parsing attribute save-restore="no"
target description (line 6): Leaving element <reg>
...skip for clarity...
target description (line 65): Leaving element <feature>
target description (line 66): Leaving element <target>
warning: Target-supplied registers are not supported by the current
architecture
threads (line 1): Starting:
<threads>
<thread id="p4f6.4f6" core="0"/>
</threads>

threads (line 1): Entering element <threads>
threads (line 1): Ignoring unknown attribute version
threads (line 2): Entering element <thread>
threads (line 2): Parsing attribute id="p4f6.4f6"
threads (line 2): Parsing attribute core="0"
threads (line 2): Leaving element <thread>
threads (line 3): Leaving element <threads>
target library list (line 1): Starting:
<library-list-svr4 version="1.0"/>
target library list (line 1): Entering element <library-list-svr4>
target library list (line 1): Parsing attribute version="1.0"
target library list (line 1): Leaving element <library-list-svr4>
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
threads (line 1): Starting:
<threads>
<thread id="p4f6.4f6" core="0"/>
</threads>

threads (line 1): Entering element <threads>
threads (line 1): Ignoring unknown attribute version
threads (line 2): Entering element <thread>
threads (line 2): Parsing attribute id="p4f6.4f6"
threads (line 2): Parsing attribute core="0"
threads (line 2): Leaving element <thread>
threads (line 3): Leaving element <threads>
0x29559368 in ?? ()

It look like this code path not used anymore for a long time... I don't have
any idea how to fix this error at this moment, however it seems host gdb
fallback to some target configuration which allow to debug target (may be in
some no side effects which I do not see right now).

p.s. Full logs attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.