From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20874 invoked by alias); 28 Apr 2003 22:52:06 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20862 invoked from network); 28 Apr 2003 22:52:05 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 28 Apr 2003 22:52:05 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DFB6B2B2F; Mon, 28 Apr 2003 18:52:05 -0400 (EDT) Message-ID: <3EADB095.2090409@redhat.com> Date: Tue, 29 Apr 2003 02:15:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com Subject: re-ordered i386 regcache References: <20030426015010.GA25355@nevyn.them.org> <3EA9F295.2090803@redhat.com> <20030426030534.GA26304@nevyn.them.org> <3EA9FDDF.8070205@redhat.com> <200304272203.h3RM35Ur016419@elgar.kettenis.dyndns.org> <3EAD474C.6090403@redhat.com> <20030428153247.GA28501@nevyn.them.org> <3EAD51F1.8050605@redhat.com> <20030428161443.GA30324@nevyn.them.org> <3EAD58B8.2070003@redhat.com> <20030428192506.GA11978@nevyn.them.org> Content-Type: multipart/mixed; boundary="------------020308070003000304070003" X-SW-Source: 2003-04/txt/msg00535.txt.bz2 This is a multi-part message in MIME format. --------------020308070003000304070003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1737 [I changed subjects, this thread is too long] > On Mon, Apr 28, 2003 at 12:37:12PM -0400, Andrew Cagney wrote: > >> Hmm, I think it will be needed anyway, what happens when the user is >> debugging an i386 mode function (with 32 bit register based long long >> debug info) on an x86-64 target? That's the MIPS problem, and it needs >> that projection(1). >> >> Also, the next_regnum method assumes that all debug infos use the same >> register sequencing. >> >> A word of caution though, the projection, at the register level works. >> Frame's might need tweaking. The alternative is to start out with >> deprecated_next_regnum so that it is clear where this stands. > > > Here's a discussion piece. I've implemented your suggestion. Two > notes: > - Having done it, I still don't like it :) Using the register cache > in this way seems very wrong to me. Got another way of getting MIPS (32 on 64), i386 on x86-64 (or even ia64?), e500 on PPC, sh4 on sh64, ... all working? > - It doesn't work for frames, because by the time > i386_pseudo_register_read is called the regcache is always > current_regcache. I believe this is because of > legacy_saved_regs_prev_register: > > 975 if (get_frame_saved_regs (frame) != NULL > 976 && get_frame_saved_regs (frame)[regnum] != 0) > > I guess doing this much without doing the rest of the conversion makes > the frame machinery quite sad. Should there be a frame equivalent to the regcache's cooked->raw projection? Should the read side of the cooked->raw projection be moved to the frame? Note that things like the m68hc11 some of the cooked registers are mapped onto memory so the cooked->raw writes would likely still need to remain. Andrew --------------020308070003000304070003 Content-Type: message/rfc822; name="mailbox-message://ac131313@movemail/fsf/gdb/patches#3703853" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mailbox-message://ac131313@movemail/fsf/gdb/patches#3703853" Content-length: 9443 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: cagney@localhost.redhat.com Received: from localhost (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AC1A22B2F for ; Mon, 28 Apr 2003 16:26:44 -0400 (EDT) Envelope-to: cagney@gnu.org Delivery-date: Mon, 28 Apr 2003 16:23:26 -0400 Received: from fencepost.gnu.org by localhost with IMAP (fetchmail-6.2.1) for cagney@localhost (single-drop); Mon, 28 Apr 2003 16:26:44 -0400 (EDT) Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.10) id 19AF9q-0001Bs-00 for cagney@gnu.org; Mon, 28 Apr 2003 16:23:26 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19AF9f-0001n4-00 for cagney@gnu.org; Mon, 28 Apr 2003 16:23:23 -0400 Received: from sources.redhat.com ([66.187.233.205]) by monty-python.gnu.org with smtp (Exim 4.10.13) id 19AF9c-0001bt-00 for cagney@gnu.org; Mon, 28 Apr 2003 16:23:12 -0400 Received: (qmail 11840 invoked by alias); 28 Apr 2003 20:23:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Delivered-To: mailing list gdb-patches@sources.redhat.com Received: (qmail 11832 invoked from network); 28 Apr 2003 20:23:09 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 28 Apr 2003 20:23:09 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19AF9l-0003ZL-00; Mon, 28 Apr 2003 15:23:22 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19AEFP-00037f-00; Mon, 28 Apr 2003 15:25:07 -0400 Date: Mon, 28 Apr 2003 15:25:07 -0400 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com Subject: Re: patch for printing 64-bit values in i386 registers; STABS format Message-ID: <20030428192506.GA11978@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com References: <20030426015010.GA25355@nevyn.them.org> <3EA9F295.2090803@redhat.com> <20030426030534.GA26304@nevyn.them.org> <3EA9FDDF.8070205@redhat.com> <200304272203.h3RM35Ur016419@elgar.kettenis.dyndns.org> <3EAD474C.6090403@redhat.com> <20030428153247.GA28501@nevyn.them.org> <3EAD51F1.8050605@redhat.com> <20030428161443.GA30324@nevyn.them.org> <3EAD58B8.2070003@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EAD58B8.2070003@redhat.com> User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-13.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Content-length: 6107 On Mon, Apr 28, 2003 at 12:37:12PM -0400, Andrew Cagney wrote: > Hmm, I think it will be needed anyway, what happens when the user is > debugging an i386 mode function (with 32 bit register based long long > debug info) on an x86-64 target? That's the MIPS problem, and it needs > that projection(1). > > Also, the next_regnum method assumes that all debug infos use the same > register sequencing. > > A word of caution though, the projection, at the register level works. > Frame's might need tweaking. The alternative is to start out with > deprecated_next_regnum so that it is clear where this stands. Here's a discussion piece. I've implemented your suggestion. Two notes: - Having done it, I still don't like it :) Using the register cache in this way seems very wrong to me. - It doesn't work for frames, because by the time i386_pseudo_register_read is called the regcache is always current_regcache. I believe this is because of legacy_saved_regs_prev_register: 975 if (get_frame_saved_regs (frame) != NULL 976 && get_frame_saved_regs (frame)[regnum] != 0) I guess doing this much without doing the rest of the conversion makes the frame machinery quite sad. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 2003-04-28 Daniel Jacobowitz * i386-tdep.c (debug_register_to_gdb, gdb_to_debug_register) (i386_num_debuginfo_regs, FIRST_DEBUGINFO_REGNUM) (i386_debuginfo_regnum_p): New. (i386_register_name, i386_stab_reg_to_regnum) (i386_dwarf_reg_to_regnum, i386_pseudo_register_read) (i386_pseudo_register_write, i386_register_reggroup_p): Use i386_debuginfo_regnum_p and associates. (i386_gdbarch_init): Update num_pseudo_regs. Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.139 diff -u -p -r1.139 i386-tdep.c --- i386-tdep.c 21 Apr 2003 18:55:52 -0000 1.139 +++ i386-tdep.c 28 Apr 2003 19:08:50 -0000 @@ -85,6 +85,43 @@ i386_mmx_regnum_p (int regnum) && regnum < MM0_REGNUM + i386_num_mmx_regs); } +/* Debug info registers. This is necessary because GDB assumes that + multi-word (double, long long) variables are held in consecutively + numbered registers. In the absence of better debug information to + explicitly say where the pieces are, arrange a set of extra + registers to match GCC's normal allocation order. These are used + by the various REG_TO_REGNUM methods. */ + +/* GDB's registers are in the order: + eax ecx edx ebx esp ebp esi edi + GCC's are in the order: + eax edx ecx ebx esi edi ebp esp +*/ + +static int debug_register_to_gdb[] = +{ + 0, 2, 1, 3, 6, 7, 5, 4 +}; + +static int gdb_to_debug_register[] = +{ + 0, 2, 1, 3, 7, 6, 4, 5 +}; + +static const int i386_num_debuginfo_regs = + (sizeof (debug_register_to_gdb) / sizeof (debug_register_to_gdb[0])); + +#define FIRST_DEBUGINFO_REGNUM (MM0_REGNUM + i386_num_mmx_regs) + +static int +i386_debuginfo_regnum_p (int regnum) +{ + if (regnum >= FIRST_DEBUGINFO_REGNUM + && regnum < FIRST_DEBUGINFO_REGNUM + i386_num_debuginfo_regs) + return 1; + return 0; +} + /* FP register? */ int @@ -128,6 +165,12 @@ i386_register_name (int reg) if (i386_mmx_regnum_p (reg)) return i386_mmx_names[reg - MM0_REGNUM]; + if (i386_debuginfo_regnum_p (reg)) + { + int real_regno = debug_register_to_gdb[reg - FIRST_DEBUGINFO_REGNUM]; + return i386_register_names[real_regno]; + } + return NULL; } @@ -141,7 +184,7 @@ i386_stab_reg_to_regnum (int reg) if (reg >= 0 && reg <= 7) { /* General registers. */ - return reg; + return FIRST_DEBUGINFO_REGNUM + gdb_to_debug_register[reg]; } else if (reg >= 12 && reg <= 19) { @@ -171,11 +214,14 @@ i386_dwarf_reg_to_regnum (int reg) { /* The DWARF register numbering includes %eip and %eflags, and numbers the floating point registers differently. */ - if (reg >= 0 && reg <= 9) + + if (reg >= 0 && reg <= 7) { /* General registers. */ - return reg; + return FIRST_DEBUGINFO_REGNUM + gdb_to_debug_register[reg]; } + else if (reg >= 8 && reg <= 9) + return reg; else if (reg >= 11 && reg <= 18) { /* Floating-point registers. */ @@ -1104,6 +1150,11 @@ i386_pseudo_register_read (struct gdbarc regcache_raw_read (regcache, fpnum, mmx_buf); memcpy (buf, mmx_buf, REGISTER_RAW_SIZE (regnum)); } + else if (i386_debuginfo_regnum_p (regnum)) + { + int real_regnum = debug_register_to_gdb[regnum - FIRST_DEBUGINFO_REGNUM]; + regcache_raw_read (regcache, real_regnum, buf); + } else regcache_raw_read (regcache, regnum, buf); } @@ -1124,6 +1175,11 @@ i386_pseudo_register_write (struct gdbar /* ... Write. */ regcache_raw_write (regcache, fpnum, mmx_buf); } + else if (i386_debuginfo_regnum_p (regnum)) + { + int real_regnum = debug_register_to_gdb[regnum - FIRST_DEBUGINFO_REGNUM]; + regcache_raw_write (regcache, real_regnum, buf); + } else regcache_raw_write (regcache, regnum, buf); } @@ -1407,6 +1463,8 @@ i386_register_reggroup_p (struct gdbarch int fp_regnum_p = (i386_fp_regnum_p (regnum) || i386_fpc_regnum_p (regnum)); int mmx_regnum_p = (i386_mmx_regnum_p (regnum)); + if (i386_debuginfo_regnum_p (regnum)) + return 0; if (group == i386_mmx_reggroup) return mmx_regnum_p; if (group == i386_sse_reggroup) @@ -1541,8 +1599,8 @@ i386_gdbarch_init (struct gdbarch_info i set_gdbarch_frame_num_args (gdbarch, frame_num_args_unknown); set_gdbarch_pc_in_sigtramp (gdbarch, i386_pc_in_sigtramp); - /* Wire in the MMX registers. */ - set_gdbarch_num_pseudo_regs (gdbarch, i386_num_mmx_regs); + /* Wire in the MMX and debuginfo registers. */ + set_gdbarch_num_pseudo_regs (gdbarch, i386_num_mmx_regs + i386_num_debuginfo_regs); set_gdbarch_pseudo_register_read (gdbarch, i386_pseudo_register_read); set_gdbarch_pseudo_register_write (gdbarch, i386_pseudo_register_write); --------------020308070003000304070003--