From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19769 invoked by alias); 30 Nov 2001 00:01:14 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19109 invoked from network); 29 Nov 2001 23:59:53 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 29 Nov 2001 23:59:53 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA23406; Thu, 29 Nov 2001 15:59:52 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.9.3/8.9.3) id QAA19971; Thu, 29 Nov 2001 16:59:41 -0700 Date: Tue, 20 Nov 2001 11:10:00 -0000 From: Kevin Buettner Message-Id: <1011129235941.ZM19970@ocotillo.lan> In-Reply-To: Andrew Cagney "Re: [RFA] ppc-linux-nat.c: Don't use regmap[] anymore." (Nov 29, 5:56pm) References: <15362.34742.58613.695856@krustylu.cygnus.com> <1011129205738.ZM19235@ocotillo.lan> <3C06AC88.50403@cygnus.com> <1011129215935.ZM19472@ocotillo.lan> <3C06BD1F.2070809@cygnus.com> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Andrew Cagney Subject: Re: [RFA] ppc-linux-nat.c: Don't use regmap[] anymore. Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-11/txt/msg00373.txt.bz2 On Nov 29, 5:56pm, Andrew Cagney wrote: > > On Nov 29, 4:45pm, Andrew Cagney wrote: > > > >> I suspect a few more targets could do with the same treatment. > >> Eliminating that hardwired regmap[] would probably help a few more targets. > > > > Perhaps. But, I think each target better have good reasons for doing > > so before undertaking such a transformation. Replacing the hardwired > > regmap[] with a function with the same constants hardwired into it > > doesn't accomplish much (aside from slowing things somewhat). > > The problem is, they are not constant. Because of limitations in the > way other parts of GDB currently work, an architecture change can cause > those offsets to change :-( Check x86-64 vs i386. Just to make sure we're talking about the same thing... regmap[] maps GDB register numbers to ``struct user'' offsets. These are used when calling ptrace() and are sometimes used for obtaining struct offsets within a gregset. I don't know much about Linux/x86-64, but I would imagine that its ``struct user'' is different than that used for Linux/x86. (Which, I gather, is what you mean by these offsets not being constant.) If it's somehow possible to debug Linux/x86 programs on Linux/x86-64, then we would indeed need a mechanism to pick the right regmap[]. Certainly, using a function in this case would make sense. However, it might well be implemented something like this: static int regmap (int regno) { static int x86_regmap[] = { ... }; static int x86_64_regmap[] = { ... }; if (target_is_x86_64 ()) return x86_64_regmap[regno]; else return x86_regmap[regno]; } I did look at x86-64-linux-nat.c and it does appear to be amazingly similar to i386-linux-nat.c. It would be nice if the same file could be used for both architectures. If making a more dynamic regmap[] is what's needed, then I'm all for it. Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] ppc-linux-nat.c: Don't use regmap[] anymore. Date: Thu, 29 Nov 2001 16:01:00 -0000 Message-ID: <1011129235941.ZM19970@ocotillo.lan> References: <15362.34742.58613.695856@krustylu.cygnus.com> <1011129205738.ZM19235@ocotillo.lan> <3C06AC88.50403@cygnus.com> <1011129215935.ZM19472@ocotillo.lan> <3C06BD1F.2070809@cygnus.com> X-SW-Source: 2001-11/msg00588.html Message-ID: <20011129160100.veSCPp3eEAp8BKIBhLFB33SMGhMQSDZQlfRA8J1e3l4@z> On Nov 29, 5:56pm, Andrew Cagney wrote: > > On Nov 29, 4:45pm, Andrew Cagney wrote: > > > >> I suspect a few more targets could do with the same treatment. > >> Eliminating that hardwired regmap[] would probably help a few more targets. > > > > Perhaps. But, I think each target better have good reasons for doing > > so before undertaking such a transformation. Replacing the hardwired > > regmap[] with a function with the same constants hardwired into it > > doesn't accomplish much (aside from slowing things somewhat). > > The problem is, they are not constant. Because of limitations in the > way other parts of GDB currently work, an architecture change can cause > those offsets to change :-( Check x86-64 vs i386. Just to make sure we're talking about the same thing... regmap[] maps GDB register numbers to ``struct user'' offsets. These are used when calling ptrace() and are sometimes used for obtaining struct offsets within a gregset. I don't know much about Linux/x86-64, but I would imagine that its ``struct user'' is different than that used for Linux/x86. (Which, I gather, is what you mean by these offsets not being constant.) If it's somehow possible to debug Linux/x86 programs on Linux/x86-64, then we would indeed need a mechanism to pick the right regmap[]. Certainly, using a function in this case would make sense. However, it might well be implemented something like this: static int regmap (int regno) { static int x86_regmap[] = { ... }; static int x86_64_regmap[] = { ... }; if (target_is_x86_64 ()) return x86_64_regmap[regno]; else return x86_regmap[regno]; } I did look at x86-64-linux-nat.c and it does appear to be amazingly similar to i386-linux-nat.c. It would be nice if the same file could be used for both architectures. If making a more dynamic regmap[] is what's needed, then I'm all for it. Kevin