Debugger: Could not figure register value for... #3541

astrelsky · 2021-10-24T18:58:56Z

astrelsky
Oct 24, 2021

jar:file:/C:/Users/astre/Documents/ghidra_10.1_DEV/Ghidra/Framework/Docking/lib/Docking.jar!/images/dialog-warning.png | Could not figure register value for [65] = {d = {f = {0x0, 0x0}, u = {0x0, 0x0}, s = {0x0, 0x0}}, s = {f = {0x0, 0x0, 0x0, 0x0}, u = {0x0, 0x0, 0x0, 0x0}, s = {0x0, 0x0, 0x0, 0x0}}, h = {f = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, s = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, b = {u = {0x0 }, s = {0x0 }}, q = {u = {0x0}, s = {0x0}}} | [] | Sun Oct 24 14:54:43 EDT 2021

What does this mean? I get a ton of these with different [x] values.

d-millar · 2021-10-25T01:37:21Z

d-millar
Oct 25, 2021
Collaborator

Generally speaking, that indicates there was a parsing error processing the values returned by a “read registers” request. I can hunt this down for you, but a little more context would be helpful, i.e. what target are you looking at, what architecture is gdb reporting for the target, what version of gdb are you using, how are you connecting to the target, do you have a static disassembly loaded, what language does it use, etc.

3 replies

astrelsky Oct 25, 2021
Author

How can I correlate the number to the register? This is from usage with a wip gdb stub so it is more likely that the problem is on my end.

Its aarch64 connected via remote target with the ssh gdb gadp.

d-millar Oct 25, 2021
Collaborator

I'll check with @nsadeveloper789, but I think, if you're implementing the stub, this is on you. In other words, when you implement the $g RSP packet, it should match what you're reporting via "info registers" or the architecture you're reporting via "show architecture". There are also some peculiarities you'll need to pay attention to regarding sizing. From the RSP spec (https://sourceware.org/gdb/onlinedocs/gdb/Packets.html#Packets):

‘g’
Read general registers.

Reply:

‘XX…’
Each byte of register data is described by two hex digits. The bytes with the register are transmitted in target byte order. The size of each register and their position within the ‘g’ packet are determined by the GDB internal gdbarch functions DEPRECATED_REGISTER_RAW_SIZE and gdbarch_register_name.

When reading registers from a trace frame (see Using the Collected Data), the stub may also return a string of literal ‘x’’s in place of the register data digits, to indicate that the corresponding register has not been collected, thus its value is unavailable. For example, for an architecture with 4 registers of 4 bytes each, the following reply indicates to GDB that registers 0 and 2 have not been collected, while registers 1 and 3 have been collected, and both have zero value:

-> g
<- xxxxxxxx00000000xxxxxxxx00000000
‘E NN’
for an error.

astrelsky Oct 26, 2021
Author

So this is the target xml I send to gdb:

constexpr auto target_xml =
    R"(l<?xml version="1.0"?>
<!DOCTYPE target SYSTEM "gdb-target.dtd">
<target version="1.0">
  <architecture>aarch64</architecture>
  <feature name="org.gnu.gdb.aarch64.core"/>
  <feature name="org.gnu.gdb.aarch64.fpu"/>
</target>
)"sv;

Here is an example response to g:

$1c1b7a9520000000201b7a9520000000ff81000000000000ffffffffffffffff00000000000000000b020000000000000c0000000000000002000000000000000042800b000000000000000000000000000000000000000040a2f3c6200000004002000000000000000000000000000000000000000000000000000000000000a858670b00000000404cd50a000000000000000000000000201b7a95200000001c1b7a9520000000ff81000000000000fc14100800000000c81b7a9520000000e81c7a95200000000100000000000000309fae08000000000300000000000000f21a3d0800000000603c900b10000000b0d1d50a00000000403c900b1000000070bbda0a0000000000000060f0b5ed3a0000000000000000000000008988883c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000804000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000803f000000000000000000000000000000000000803f000000000000000000000000000080bf0000803f8988883a00000000000000000000000000000000d6b9f2ba00000000000000008988883a00000000000000000000000000000000d6b9f2ba000000000000000000000000000000000ad723bc00000000000080bf0000803f0ad7233c0000803f00000000000000000ad723bc00000000000080bf0000803f000000800000803f000080bf000000000000000000000000000000000000000000000000000000000000a0400000000000000000000000000000803f00000000000000000000000000000000#ee

~~I think I'm screwing up the size of the vector registers.~~

I'm screwing up a lot of things. Turns out I was using outdated functions that I thought I had replaced but hadn't. In some places I'm sending the correct stuff and in others (like signal responses) I'm not. Seems like I've got quite a bit of work to do this weekend 🤣. Thank you for the assistance!

nsadeveloper789 · 2021-10-25T13:46:34Z

nsadeveloper789
Oct 25, 2021
Maintainer

So, that message is coming from GdbReadRegistersCommand. Without a full stack trace, it's difficult to discern exactly what went wrong, but AFAICT, it probably deals with the d = {f = {...}} structure of the reported value.
If you have a dev environment set up, we might answer 2 questions:

Set a breakpoint on GdbReadRegistersCommand#complete (approx line 150)
Step over the init of regsByNumber. You should be able to see in there what register is numbered 65. BTW, if you want to to get that same info from GDB's CLI, type interpreter-exec mi2 -data-list-register-names. You may need to process the output some, but that should be a one-time thing for your arch/stub.
Probably set a conditional breakpoint right after int number = Integer.parseInt(...) for number == 65.
Assuming it's hit, step from there into parseAndFindInteger.

Beyond that, it all depends on what you find out. I'm curious if this affects us for aarch with GDB in general, or if it's particular to your stub....

6 replies

astrelsky Oct 26, 2021
Author

This was definitely helpful. With a bit of regex replace I reformatted it like so:

register_names = [
	"x0", "x1", "x2", "x3", 
	"x4", "x5", "x6", "x7", 
	"x8", "x9", "x10", "x11", 
	"x12", "x13", "x14", "x15", 
	"x16", "x17", "x18", "x19", 
	"x20", "x21", "x22", "x23", 
	"x24", "x25", "x26", "x27", 
	"x28", "x29", "x30", "sp", 
	"pc", "cpsr", "v0", "v1", 
	"v2", "v3", "v4", "v5", 
	"v6", "v7", "v8", "v9", 
	"v10", "v11", "v12", "v13", 
	"v14", "v15", "v16", "v17", 
	"v18", "v19", "v20", "v21", 
	"v22", "v23", "v24", "v25", 
	"v26", "v27", "v28", "v29", 
	"v30", "v31", "fpsr", "fpcr", 
	"q0", "q1", "q2", "q3", 
	"q4", "q5", "q6", "q7", 
	"q8", "q9", "q10", "q11", 
	"q12", "q13", "q14", "q15", 
	"q16", "q17", "q18", "q19", 
	"q20", "q21", "q22", "q23", 
	"q24", "q25", "q26", "q27", 
	"q28", "q29", "q30", "q31", 
	"d0", "d1", "d2", "d3", "d4", 
	"d5", "d6", "d7", "d8", "d9", 
	"d10", "d11", "d12", "d13", 
	"d14", "d15", "d16", "d17", 
	"d18", "d19", "d20", "d21", 
	"d22", "d23", "d24", "d25", 
	"d26", "d27", "d28", "d29", 
	"d30", "d31", "s0", "s1", 
	"s2", "s3", "s4", "s5", 
	"s6", "s7", "s8", "s9", 
	"s10", "s11", "s12", "s13", 
	"s14", "s15", "s16", "s17", 
	"s18", "s19", "s20", "s21", 
	"s22", "s23", "s24", "s25", 
	"s26", "s27", "s28", "s29", 
	"s30", "s31", "h0", "h1", 
	"h2", "h3", "h4", "h5", 
	"h6", "h7", "h8", "h9", 
	"h10", "h11", "h12", "h13", 
	"h14", "h15", "h16", "h17", 
	"h18", "h19", "h20", "h21", 
	"h22", "h23", "h24", "h25", 
	"h26", "h27", "h28", "h29", 
	"h30", "h31", "b0", "b1", 
	"b2", "b3", "b4", "b5", 
	"b6", "b7", "b8", "b9", 
	"b10", "b11", "b12", "b13", 
	"b14", "b15", "b16", "b17", 
	"b18", "b19", "b20", "b21", 
	"b22", "b23", "b24", "b25", 
	"b26", "b27", "b28", "b29", 
	"b30", "b31"
]

Then just pasted it into a python interpreter and got my answer register_names[65] gave me v31. I've found the root cause of the problem. It is 100% just my stub and so nice of gdb to just not complain about it. Had it not been for the debug console I wouldn't have known. Thank you for the assistance!

d-millar Oct 26, 2021
Collaborator

Getting a gdbstub right is definitely non-trivial, and gdb doesn’t make it easy on you. “set debug remote 1” and “set debug serial 1” are your friends.

astrelsky Oct 26, 2021
Author

Getting a gdbstub right is definitely non-trivial, and gdb doesn’t make it easy on you. “set debug remote 1” and “set debug serial 1” are your friends.

I knew of the remote one but not of the serial one. I never saw it complain about the registers, plenty of other complaints though. Of course the documentation is about as vague as possible. Then again it is an ancient protocol now its just unfortunate that there doesn't really seem to be a simple replacement.

astrelsky Nov 7, 2021
Author

So, that message is coming from GdbReadRegistersCommand. Without a full stack trace, it's difficult to discern exactly what went wrong, but AFAICT, it probably deals with the d = {f = {...}} structure of the reported value. If you have a dev environment set up, we might answer 2 questions:

Set a breakpoint on GdbReadRegistersCommand#complete (approx line 150)

Step over the init of regsByNumber. You should be able to see in there what register is numbered 65. BTW, if you want to to get that same info from GDB's CLI, type interpreter-exec mi2 -data-list-register-names. You may need to process the output some, but that should be a one-time thing for your arch/stub.

Probably set a conditional breakpoint right after int number = Integer.parseInt(...) for number == 65.

Assuming it's hit, step from there into parseAndFindInteger.

Beyond that, it all depends on what you find out. I'm curious if this affects us for aarch with GDB in general, or if it's particular to your stub....

So it turns out that this would be particular to aarch64 as I'm using the default aarch64 gdb target. I did have an issue in my stub with sending the register values but it ended up being unrelated. You were correct, the issue does lie in GdbReadRegistersCommand::parseAndFindInteger. GdbCValueParser.parseValue(val) is able to successfully parse the composite but since it is a composite of composites and not a composite of arrays parseAndFindInteger doesn't successfully get the value. Below is the string value which gets parsed. I have expanded its layout to make it easier to read.

{
    d = {
        f = {0x0, 0x0},
        u = {0x3c888889, 0x0},
        s = {0x3c888889, 0x0}
    },
    s = {
        f = {0x0, 0x0, 0x0, 0x0},
        u = {0x3c888889, 0x0, 0x0, 0x0},
        s = {0x3c888889, 0x0, 0x0, 0x0}
    },
    h = {
        f = {0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
        u = {0x8889, 0x3c88, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
        s = {0x8889, 0x3c88, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    },
    b = {
        u = {0x89, 0x88, 0x88, 0x3c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
        s = {0x89, 0x88, 0x88, 0x3c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    },
    q = {
        u = {0x3c888889},
        s = {0x3c888889}
    }
}

astrelsky Nov 7, 2021
Author

So these are actually defined as unions. It might be a good idea to generate some sort of factory class by parsing the register definitions and map them to each register or something. The layout seen above was for v0 which is defined to union id aarch64v as seen below:

<vector id="v2d" type="ieee_double" count="2"/>
<vector id="v2u" type="uint64" count="2"/>
<vector id="v2i" type="int64" count="2"/>
<vector id="v4f" type="ieee_single" count="4"/>
<vector id="v4u" type="uint32" count="4"/>
<vector id="v4i" type="int32" count="4"/>
<!-- <vector id="v8f" type="ieee_half" count="8"/> -->
<vector id="v8u" type="uint16" count="8"/>
<vector id="v8i" type="int16" count="8"/>
<vector id="v16u" type="uint8" count="16"/>
<vector id="v16i" type="int8" count="16"/>
<vector id="v1u" type="uint128" count="1"/>
<vector id="v1i" type="int128" count="1"/>
<union id="vnd">
	<field name="f" type="v2d"/>
	<field name="u" type="v2u"/>
	<field name="s" type="v2i"/>
</union>
<union id="vns">
	<field name="f" type="v4f"/>
	<field name="u" type="v4u"/>
	<field name="s" type="v4i"/>
</union>
<union id="vnh">
	<!-- <field name="f" type="v8f"/> -->
	<field name="u" type="v8u"/>
	<field name="s" type="v8i"/>
</union>
<union id="vnb">
	<field name="u" type="v16u"/>
	<field name="s" type="v16i"/>
</union>
<union id="vnq">
	<field name="u" type="v1u"/>
	<field name="s" type="v1i"/>
</union>
<union id="aarch64v">
	<field name="d" type="vnd"/>
	<field name="s" type="vns"/>
	<field name="h" type="vnh"/>
	<field name="b" type="vnb"/>
	<field name="q" type="vnq"/>
</union>

That definition above was stolen from here since I don't know off the top of my head where it is in gdb.

nsadeveloper789 · 2021-11-08T16:50:12Z

nsadeveloper789
Nov 8, 2021
Maintainer

Cool. The example is very helpful, and I think I can work with that. I'll probably take the unsigned byte array from the union. Regarding a factory class, that might be a nice way to isolate each parsing case, but I'm not inclined to go there, yet. It might be nice if I can just generically handle it from an XML definition, but I have to be careful the licensing where I find those....

1 reply

astrelsky Nov 9, 2021
Author

Cool. The example is very helpful, and I think I can work with that. I'll probably take the unsigned byte array from the union. Regarding a factory class, that might be a nice way to isolate each parsing case, but I'm not inclined to go there, yet. It might be nice if I can just generically handle it from an XML definition, but I have to be careful the licensing where I find those....

The xml definitions can be found here. They fall under the same license as binutils which is GPL. I'm wondering what lldb uses since it supports the gdb remote protocol as well but I have to look for it.

Either way the specification isn't too complex so it shouldn't be hard to design something without using it.

nsadeveloper789 · 2022-11-17T15:37:30Z

nsadeveloper789
Nov 17, 2022
Maintainer

So, the parsing issue is now resolved; however, at least one issue related to mapping/aliasing still remains. Ghidra names these qN, each being a child of its respective zN register. We should be able to alias the vN to qN, but we'll also need to tweak the Debugger's register mapper (it doesn't consider aliases currently) to make these actually display in the Registers panel. I suspect you'll want to leave this ticket open until that is resolved, too....

1 reply

astrelsky Nov 17, 2022
Author

So, the parsing issue is now resolved; however, at least one issue related to mapping/aliasing still remains. Ghidra names these qN, each being a child of its respective zN register. We should be able to alias the vN to qN, but we'll also need to tweak the Debugger's register mapper (it doesn't consider aliases currently) to make these actually display in the Registers panel. I suspect you'll want to leave this ticket open until that is resolved, too....

I'm no longer working on what I was doing at the time but if you want it open until then I have no complaints.

Debugger: Could not figure register value for... #3541

Uh oh!

astrelsky Oct 24, 2021

Replies: 4 comments · 11 replies

Uh oh!

d-millar Oct 25, 2021 Collaborator

Uh oh!

Uh oh!

astrelsky Oct 25, 2021 Author

Uh oh!

d-millar Oct 25, 2021 Collaborator

Uh oh!

Uh oh!

astrelsky Oct 26, 2021 Author

Uh oh!

nsadeveloper789 Oct 25, 2021 Maintainer

Uh oh!

Uh oh!

astrelsky Oct 26, 2021 Author

Uh oh!

d-millar Oct 26, 2021 Collaborator

Uh oh!

Uh oh!

astrelsky Oct 26, 2021 Author

Uh oh!

Uh oh!

astrelsky Nov 7, 2021 Author

Uh oh!

Uh oh!

astrelsky Nov 7, 2021 Author

Uh oh!

nsadeveloper789 Nov 8, 2021 Maintainer

Uh oh!

Uh oh!

astrelsky Nov 9, 2021 Author

Uh oh!

nsadeveloper789 Nov 17, 2022 Maintainer

Uh oh!

astrelsky Nov 17, 2022 Author

astrelsky
Oct 24, 2021

Replies: 4 comments 11 replies

d-millar
Oct 25, 2021
Collaborator

astrelsky Oct 25, 2021
Author

d-millar Oct 25, 2021
Collaborator

astrelsky Oct 26, 2021
Author

nsadeveloper789
Oct 25, 2021
Maintainer

astrelsky Oct 26, 2021
Author

d-millar Oct 26, 2021
Collaborator

astrelsky Oct 26, 2021
Author

astrelsky Nov 7, 2021
Author

astrelsky Nov 7, 2021
Author

nsadeveloper789
Nov 8, 2021
Maintainer

astrelsky Nov 9, 2021
Author

nsadeveloper789
Nov 17, 2022
Maintainer

astrelsky Nov 17, 2022
Author