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 23:22:00 -0000 Message-id: <20010718232242.A24417@nevyn.them.org> References: <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> <20010718132140.A2937@nevyn.them.org> <3B5675BA.4010403@cygnus.com> X-SW-Source: 2001-07/msg00270.html On Thu, Jul 19, 2001 at 01:52:58AM -0400, Andrew Cagney wrote: > > 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. > > > Don't forget you need to bump the syscall number as part of that new > interface. Well, the example I was considering here was something like SSE registers or Altivec registers which may or may not be available - you can safely increase the size of the user struct, and you can add subrequests like PTRACE_GETFPXREGS (or whatever it's called). > > 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? > > > Hmm > > > > (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.) > > > I think there are two paths. One has a formalized G packet layout the > other has total flexability. If GDB is going to try to accept multiple > different packet layouts then it will surely miss one. In that case, > why not assume it will miss one and give the user the flexability to > specify a custom packet spec. The set of named packets could just be > pre-defined specifications. A set of hard-wired packet specs would be a > compromise. Well, implementation-wise and protocol-wise I'll need the same things to do it hard-wired before I can do it flexibly, so I'm implementing that structure now (I'm mostly done it, actually - I'm testing it for mips32 now, and if it works I'll post it in the morning). Having flexible packet specs would remove a couple of trivial functions that I wrote, but I'd prefer to tackle that idea after the remainder of the issues have been dealt with. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer