From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32533 invoked by alias); 30 Nov 2001 00:38:29 -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 32507 invoked from network); 30 Nov 2001 00:38:26 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.138.202.10) by hostedprojects.ges.redhat.com with SMTP; 30 Nov 2001 00:38:26 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 47BD43DE8; Thu, 29 Nov 2001 19:38:25 -0500 (EST) Message-ID: <3C06D501.8010805@cygnus.com> Date: Tue, 20 Nov 2001 16:11:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] ppc-linux-nat.c: Don't use regmap[] anymore. References: <15362.34742.58613.695856@krustylu.cygnus.com> <1011129205738.ZM19235@ocotillo.lan> <3C06AC88.50403@cygnus.com> <1011129215935.ZM19472@ocotillo.lan> <3C06BD1F.2070809@cygnus.com> <1011129235941.ZM19970@ocotillo.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00377.txt.bz2 Message-ID: <20011120161100.VZGeSuqQ9U_s0jxTl5TMgRLCUJC-0g12K5dhQc9XPyA@z> > > 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. Yes, a given nat file will use constant offsets to find a given register in the ptrace / corefile / .... The ``regnum'' assigned to that register, however, can change. > 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]; > } Yes. This would handle two of the possible REGNUM -> OFFSET mappings. I think a more robust way of doing it is: if (regnum in I386_FP0_REGNUM to MAX) DO SOMETHING; else if regnum in someother register range; do something else; which means you're insulated from a problem such as the regnum's being re-aranged (Hmm, lets slip MMX registers in between FP and XMM registers). > 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. I suspect Mark K has thoughts of doing that :-) There are other ways this could be handled, however, for the moment I think the run-time test is safest. I'm getting ready to post a really nasty regcache.[hc] patch that will hopefully illustrate one of the problems - NUM_REGS and REGISTER_BYTES. enjoy, Andrew