Re: Questions on XML register descriptions

[Luis Machado via Gdb <gdb@sourceware.org>]

Hi,

On 12/26/23 22:42, H. Peter Anvin via Gdb wrote:
> Hi,
> 
> I have been looking at the XML register descriptions, and I have a couple of questions, as I'm trying to add gdb remote support to an emulator, which involves additional system-level registers as well as memory spaces.
> 
> 1. Some registers can't be written to, and some registers may affect other registers. What, if anything, is the best way to handle that?

There isn't a single right way. You could teach gdb about those registers explicitly (not ideal) or you could make the remote just ignore or error out when gdb tries to modify such a register.

As for side-effects (changing a register has an effect on a different register), this might be best implemented via p/P packets. With those gdb can write out one specific register and then it re-reads the rest of the registers.

In such a case, you get the opportunity to apply the side-effects to other registers in time for sending the updated register buffer block.

This is a bit odd with the g/G packets, as it gets confusing having to write all registers at once, and you might not know what values have changed or not.

> 
> 2. How do the G/g commands interact with the XML target descriptions? Do they apply specifically to group="general", or are there other rules?

My recollection of it is that G/g will request all of the reported XML register with non-zero sizes. If p/P is also supported, gdb will attempt to fetch things using g and write things using P.

I vaguely recall something about gdb not requesting some register in g, but I'm not sure if that's still a thing.

> 
> 3. Is there any concept at all of different address spaces in gdb? Alternatively, is there any way to tell gdb that it should communicate addresses wider than the pointer type of the base architecture (which would allow a Python helper script to define a convenience API.> 

Yes, but the architecture-specific / os-specific layers need to be taught about it. Ideally the compiler would also establish a way of communicating this information to debuggers via the generated DWARF info. See DW_AT_address_class in the DWARF standard.

Are we talking about short pointers here? Say, a 16-bit pointer in a 32-bit address space?

> 4. There doesn't seem to be a way to trigger a Python function when a connection is *established*, which is as far as I understand the point at which the XML register description is downloaded from the remote, and definitely the first point at which register values can be examined. Am I missing something obvious?
> 

The Python API is still growing. If this is needed, I'd make the case to the gdb community. Patches are always welcome.

> 5. I presume the byte codes use for the Z commands are the same as the agent bytecode in Appendix F, even though the latter specifically seems to be referring to tracepoints?

Yes, the byte codes used for evaluating breakpoint conditions is the same as the ones used for tracepoints. The documentation could make that a bit more explict.

> 
> Many thanks,
> 
>     -hpa