From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: parcelling up struct gdbarch Date: Wed, 18 Jul 2001 13:21:00 -0000 Message-id: <20010718132140.A2937@nevyn.them.org> References: <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> <3B5485C5.2010007@cygnus.com> X-SW-Source: 2001-07/msg00253.html On Tue, Jul 17, 2001 at 02:36:53PM -0400, Andrew Cagney wrote: > > 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. > 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'm looking right now at rs6000-tdep.c. When we need a gdbarch for a PPC binary, we call rs6000_gdbarch_init, which builds the architecture. What registers are available depends on what registers the target architecture actually has. At the same time, what registers gdbserver can provide are strictly limited - in the same way that what registers infptrace can provide are also strictly limited. In this case, to the bulk of the GPRs, the FPRs, and eventually (if no one beats me to it, I'll be adding kernel support for...) the Altivec registers if we're on a processor that has them. No matter what architecture is set, if we're debugging userland Linux applications, they see the same things. Linux userland is, for all intents and purposes that I can see, a gdbarch itself - two if you break it up w.r.t. whether Altivec is available or not. It determines calling conventions and available registers. This could, of course, change. It's not unreasonable to hypothesize ptrace returning different registers depending on what processor is actually in use. Somehow, we need to get GDB and gdbserver to agree on what registers exist and what will be sent in a register info packet. This will, as far as I'm concerned, require some sort of protocol addition. As I see it: - gdbserver is the authority on what registers are available. - gdb must be prepared to give meaning to all of those registers (even if "meaning" == "none"). We can tie it to the gdbarch, but that seems like a bad idea, especially given the flexibility with which gdbarches seem to be generated. So, in my N'th consecutive suggestion: is it reasonable to assign a name to each register packet format, document them by name, and allow GDB to send a query for the format which gdbserver will use? (for what it's worth, which is probably not much, I like this solution for this particular problem better than anything else I've come up with or heard so far, and it sounds like we were both going in this general direction.) -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer