Re: parcelling up struct gdbarch

Andrew Cagney
2001-07-17T11:37:00Z

>> If raw registers are given names independant of the user visible cooked
>> registers then, something as silly as:
>>
>> 0:gpr0,4;1:gpr1,4;4;3:spr0;8;4;...
>>
>> would even work.
>
>
> I don't understand why you say that we would need more than one
> G-packet format per gdbarch. Why? Compatibility with different stubs?

To remove the need to recompile GDB every time someone wants to get GDB
to talk to a stub. Instead of having to incorporate C code for each and
every MIPS g-packet format, a simple generic table. If the user finds
their packet isn't included then just specify its layout on using the CLI.

> That seems like the wrong approach. We've currently got one G-packet
> format per definition of the register cache, and we've got one of those
> per gdbarch, right?

Why should the entire register cache get re-structured everytime someone
tweeks the architecture. It is what GDB currently does, I don't think
it is right.

> I don't really understand what you mean by that string, either what the
> fields or supposed to be or what it is supposed to define.

g-register 0 is 4 bytes and gets written to gpr0.
g-register 1 is 4 bytes and is written to gpr1
there is a gap of 4 bytes
g-register 3 is 8 bytes and is written to spr0
.
.
.