From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: parcelling up struct gdbarch Date: Tue, 17 Jul 2001 11:37:00 -0000 Message-id: <3B5485C5.2010007@cygnus.com> References: <20010713001635.A19524@nevyn.them.org> <3B4F4D7F.6010201@cygnus.com> <20010713145356.A4898@nevyn.them.org> <3B506250.5080502@cygnus.com> <20010716112536.A19620@nevyn.them.org> <3B533AAD.1060300@cygnus.com> <20010716130559.B25488@nevyn.them.org> <3B536764.1000508@cygnus.com> <20010716154904.A8712@nevyn.them.org> <3B547A08.2030403@cygnus.com> <20010717110305.A18932@nevyn.them.org> X-SW-Source: 2001-07/msg00217.html >> 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 . . .