From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18794 invoked by alias); 23 Jan 2006 15:51:32 -0000 Received: (qmail 18783 invoked by uid 22791); 23 Jan 2006 15:51:31 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-01.spheriq.net (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jan 2006 15:51:27 +0000 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-01.spheriq.net with ESMTP id k0NFpEbU014776 for ; Mon, 23 Jan 2006 15:51:16 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-03.spheriq.net with ESMTP id k0NFpCwL001177 for ; Mon, 23 Jan 2006 15:51:14 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id k0NFp1OI009327 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 23 Jan 2006 15:51:02 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5ADF6DA44; Mon, 23 Jan 2006 15:50:56 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id EF23247460; Mon, 23 Jan 2006 15:54:26 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHD83234 (AUTH stubbsa); Mon, 23 Jan 2006 15:50:54 GMT Message-ID: <43D4FADC.4070303@st.com> Date: Mon, 23 Jan 2006 15:51:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [SH] PATCH: Define the register groups References: <436105B8.7020605@st.com> <436F6CF7.1070003@st.com> <20060120233520.GJ21181@nevyn.them.org> In-Reply-To: <20060120233520.GJ21181@nevyn.them.org> Content-Type: multipart/mixed; boundary="------------040708070607040002040208" X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00326.txt.bz2 This is a multi-part message in MIME format. --------------040708070607040002040208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 2176 Daniel Jacobowitz wrote: > - Are the fv registers for floating point vectors? Since you > put them in both info float and info vector. I'm guessing that > they are. Makes sense. Yes. > - Can we reuse default_register_reggroup_p for most of this, and > just handle the register numbers that it's likely to get > wrong? e.g. we probably do need to handle FPUL here - but > calling the default will handle dr0 just fine. Yes, I hadn't thought of that, but I suppose it can. I attach an implementation of this patch. Actually, FPUL is handled fine, but FPSCR is not, and, more to the point, none of the vector registers are. > - You've put a bunch of registers in system_reggroup (e.g. pc, pr) > that other folks don't; but no one besides the TUI uses that > anyway, so it doesn't really matter. I wouldn't have included > those two. I don't remember what the other ones you listed do, > so I've got no idea about them :-) Well, there is, of course, a debate to be had over many of the registers. I have included FPSCR, a system register, in the float reggroup because (to the initiated) it helps you read the other float registers. I'm not really sure what system_reggroup is supposed to be for - I imagine sr (status register) that control various features (FPU, exceptions etc.) of the CPU is a definite member of this group. Others are less clear - how about spc and spr which are like pc and pr for exceptions. Incidentally, insight also uses these groups. The attached patch has pc and pr moved from system to general. I have also moved GBR similarly. I had previously classified this as system because it is not generally useful (the compiler does not normally generate code that uses it), but on reflection it just isn't a system register. At the end of the day the important thing is that 'info registers', 'info float' and 'info vector' print the right thing. OK? Andrew Stubbs P.S. Your email headers contain: Mail-Followup-To: Andrew STUBBS , gdb-patches@sources.redhat.com which means I end up replying to myself! Is this deliberate? It is slightly irritating. --------------040708070607040002040208 Content-Type: text/plain; name="sh_reggroups-2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sh_reggroups-2.patch" Content-length: 3107 2006-01-23 Andrew Stubbs * sh-tdep.c: Include reggroups.h. (sh_register_reggroup_p): New function. (sh_gdbarch_init): Add call to set_gdbarch_register_reggroup_p. * Makefile.in (sh-tdep.o): Add dependency on reggroups.h. Index: src/gdb/sh-tdep.c =================================================================== --- src.orig/gdb/sh-tdep.c 2006-01-16 12:44:50.000000000 +0000 +++ src/gdb/sh-tdep.c 2006-01-23 14:42:11.000000000 +0000 @@ -44,6 +44,7 @@ #include "regcache.h" #include "doublest.h" #include "osabi.h" +#include "reggroups.h" #include "sh-tdep.h" @@ -1812,6 +1813,47 @@ sh_default_register_type (struct gdbarch return builtin_type_int; } +/* Is a register in a reggroup? + The default code in reggroup.c doesn't identify system registers, some + float registers or any of the vector registers. + TODO: sh2a and dsp registers. */ +int +sh_register_reggroup_p (struct gdbarch *gdbarch, int regnum, + struct reggroup *reggroup) +{ + if (REGISTER_NAME (regnum) == NULL + || *REGISTER_NAME (regnum) == '\0') + return 0; + + if (reggroup == float_reggroup + && (regnum == FPUL_REGNUM + || regnum == FPSCR_REGNUM)) + return 1; + + if (regnum >= FV0_REGNUM && regnum <= FV_LAST_REGNUM) + { + if (reggroup == vector_reggroup || reggroup == float_reggroup) + return 1; + if (reggroup == general_reggroup) + return 0; + } + + if (regnum == VBR_REGNUM + || regnum == SR_REGNUM + || regnum == FPSCR_REGNUM + || regnum == SSR_REGNUM + || regnum == SPC_REGNUM) + { + if (reggroup == system_reggroup) + return 1; + if (reggroup == general_reggroup) + return 0; + } + + /* The default code can cope with any other registers. */ + return default_register_reggroup_p (gdbarch, regnum, reggroup); +} + /* On the sh4, the DRi pseudo registers are problematic if the target is little endian. When the user writes one of those registers, for instance with 'ser var $dr0=1', we want the double to be stored @@ -2371,6 +2413,7 @@ sh_gdbarch_init (struct gdbarch_info inf set_gdbarch_num_pseudo_regs (gdbarch, 0); set_gdbarch_register_type (gdbarch, sh_default_register_type); + set_gdbarch_register_reggroup_p (gdbarch, sh_register_reggroup_p); set_gdbarch_breakpoint_from_pc (gdbarch, sh_breakpoint_from_pc); Index: src/gdb/Makefile.in =================================================================== --- src.orig/gdb/Makefile.in 2006-01-23 12:33:23.000000000 +0000 +++ src/gdb/Makefile.in 2006-01-23 12:39:55.000000000 +0000 @@ -2538,7 +2538,7 @@ sh-tdep.o: sh-tdep.c $(defs_h) $(frame_h $(value_h) $(dis_asm_h) $(inferior_h) $(gdb_string_h) \ $(gdb_assert_h) $(arch_utils_h) $(floatformat_h) $(regcache_h) \ $(doublest_h) $(osabi_h) $(sh_tdep_h) $(elf_bfd_h) $(solib_svr4_h) \ - $(elf_sh_h) $(gdb_sim_sh_h) + $(elf_sh_h) $(gdb_sim_sh_h) $(reggroups_h) sol2-tdep.o: sol2-tdep.c $(defs_h) $(frame_h) $(symtab_h) solib-aix5.o: solib-aix5.c $(defs_h) $(gdb_string_h) $(elf_external_h) \ $(symtab_h) $(bfd_h) $(symfile_h) $(objfiles_h) $(gdbcore_h) \ --------------040708070607040002040208--