From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22495 invoked by alias); 7 Sep 2012 08:19:26 -0000 Received: (qmail 22472 invoked by uid 22791); 7 Sep 2012 08:19:21 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_CP X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Sep 2012 08:18:29 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1T9tlk-0002S9-Q5 from Thomas_Schwinge@mentor.com ; Fri, 07 Sep 2012 01:18:28 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 01:18:28 -0700 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Fri, 7 Sep 2012 09:18:26 +0100 From: Thomas Schwinge To: CC: Kevin Buettner Subject: Re: SH: double pseudo registers little-endian/big-endian In-Reply-To: <87zk5cjs1n.fsf@schwinge.name> References: <87zk5cjs1n.fsf@schwinge.name> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Fri, 07 Sep 2012 08:19:00 -0000 Message-ID: <87d31y9rg7.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00057.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 6848 Hi! Ping. On Thu, 30 Aug 2012 17:52:36 +0200, I wrote: > Little-endian SH GDB: >=20 > (gdb) set $dr0 =3D -1 > (gdb) info registers dr0 fr0 fr1 > dr0 -1 (raw 0xbff0000000000000) > fr0 -1.875 (raw 0xbff00000) > fr1 0 (raw 0x00000000) >=20 > This is correct. Big-endian SH GDB: >=20 > (gdb) set $dr0 =3D -1 > (gdb) info registers dr0 fr0 fr1 > dr0 -1 (raw 0xbff0000000000000) > fr0 8.63634257e-41 (raw 0x0000f0bf) > fr1 0 (raw 0x00000000) >=20 > Here, the value stored in fr0 is bogus. This comes from the > sh_register_convert_to_virtual conversion: as the commentary says, this > should be applied in the little-endian case only. The reasons that dr0 > is displayed correctly nevertheless is due to sh_register_convert_to_raw > (erroneously) doing the same conversion backwards, too. >=20 > A similar problem exists when displaying double values loaded as part of > the program text. >=20 > Here is a patch (basically copying code from sh64-tdep.c which got this > right), and also fixes some commentary. OK to commit? >=20 > gdb/ > sh-tdep.c (sh_register_convert_to_virtual) > (sh_register_convert_to_raw): Add a gdbarch parameter. Update > all callers. Just do a memcpy if not the little-endian case. >=20 > Index: sh-tdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /cvs/src/src/gdb/sh-tdep.c,v > retrieving revision 1.246 > diff -u -p -r1.246 sh-tdep.c > --- sh-tdep.c 22 Jul 2012 16:52:41 -0000 1.246 > +++ sh-tdep.c 30 Aug 2012 15:43:24 -0000 > @@ -342,15 +342,16 @@ sh_sh4_register_name (struct gdbarch *gd > "r0b0", "r1b0", "r2b0", "r3b0", "r4b0", "r5b0", "r6b0", "r7b0", > /* bank 1 51 - 58 */ > "r0b1", "r1b1", "r2b1", "r3b1", "r4b1", "r5b1", "r6b1", "r7b1", > + /* 59 - 66 */ > "", "", "", "", "", "", "", "", > /* pseudo bank register. */ > "", > - /* double precision (pseudo) 59 - 66 */ > + /* double precision (pseudo) 68 - 75 */ > "dr0", "dr2", "dr4", "dr6", "dr8", "dr10", "dr12", "dr14", > - /* vectors (pseudo) 67 - 70 */ > + /* vectors (pseudo) 76 - 79 */ > "fv0", "fv4", "fv8", "fv12", > - /* FIXME: missing XF 71 - 86 */ > - /* FIXME: missing XD 87 - 94 */ > + /* FIXME: missing XF */ > + /* FIXME: missing XD */ > }; > if (reg_nr < 0) > return NULL; > @@ -379,12 +380,13 @@ sh_sh4_nofpu_register_name (struct gdbar > "r0b0", "r1b0", "r2b0", "r3b0", "r4b0", "r5b0", "r6b0", "r7b0", > /* bank 1 51 - 58 */ > "r0b1", "r1b1", "r2b1", "r3b1", "r4b1", "r5b1", "r6b1", "r7b1", > + /* 59 - 66 */ > "", "", "", "", "", "", "", "", > /* pseudo bank register. */ > "", > - /* double precision (pseudo) 59 - 66 -- not for nofpu target */ > + /* double precision (pseudo) 68 - 75 -- not for nofpu target */ > "", "", "", "", "", "", "", "", > - /* vectors (pseudo) 67 - 70 -- not for nofpu target */ > + /* vectors (pseudo) 76 - 79 -- not for nofpu target */ > "", "", "", "", > }; > if (reg_nr < 0) > @@ -1521,16 +1523,16 @@ sh_register_reggroup_p (struct gdbarch * >=20=20 > /* 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=3D1', we want the double to be stored > + instance with 'set var $dr0=3D1', we want the double to be stored > like this:=20 > - fr0 =3D 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f=20 > - fr1 =3D 0x00 0x00 0x00 0x00 0x00 0x00 0x00=20 > + fr0 =3D 0x00 0x00 0xf0 0x3f=20 > + fr1 =3D 0x00 0x00 0x00 0x00=20 >=20=20 > This corresponds to little endian byte order & big endian word > order. However if we let gdb write the register w/o conversion, it > will write fr0 and fr1 this way: > - fr0 =3D 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > - fr1 =3D 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f > + fr0 =3D 0x00 0x00 0x00 0x00 > + fr1 =3D 0x00 0x00 0xf0 0x3f > because it will consider fr0 and fr1 as a single LE stretch of memory. >=20=20=20=20=20 > To achieve what we want we must force gdb to store things in > @@ -1539,16 +1541,23 @@ sh_register_reggroup_p (struct gdbarch * >=20=20 > In case the target is big endian, there is no problem, the > raw bytes will look like: > - fr0 =3D 0x3f 0xf0 0x00 0x00 0x00 0x00 0x00 > - fr1 =3D 0x00 0x00 0x00 0x00 0x00 0x00 0x00=20 > + fr0 =3D 0x3f 0xf0 0x00 0x00 > + fr1 =3D 0x00 0x00 0x00 0x00 >=20=20 > The other pseudo registers (the FVs) also don't pose a problem > because they are stored as 4 individual FP elements. */ >=20=20 > static void > -sh_register_convert_to_virtual (int regnum, struct type *type, > - char *from, char *to) > +sh_register_convert_to_virtual (struct gdbarch *gdbarch, int regnum, > + struct type *type, char *from, char *to) > { > + if (gdbarch_byte_order (gdbarch) !=3D BFD_ENDIAN_LITTLE) > + { > + /* It is a no-op. */ > + memcpy (to, from, register_size (gdbarch, regnum)); > + return; > + } > + > if (regnum >=3D DR0_REGNUM && regnum <=3D DR_LAST_REGNUM) > { > DOUBLEST val; > @@ -1562,9 +1571,16 @@ sh_register_convert_to_virtual (int regn > } >=20=20 > static void > -sh_register_convert_to_raw (struct type *type, int regnum, > - const void *from, void *to) > +sh_register_convert_to_raw (struct gdbarch *gdbarch, struct type *type, > + int regnum, const void *from, void *to) > { > + if (gdbarch_byte_order (gdbarch) !=3D BFD_ENDIAN_LITTLE) > + { > + /* It is a no-op. */ > + memcpy (to, from, register_size (gdbarch, regnum)); > + return; > + } > + > if (regnum >=3D DR0_REGNUM && regnum <=3D DR_LAST_REGNUM) > { > DOUBLEST val =3D extract_typed_floating (from, type); > @@ -1643,7 +1659,7 @@ sh_pseudo_register_read (struct gdbarch=20 > if (status =3D=3D REG_VALID) > { > /* We must pay attention to the endiannes. */ > - sh_register_convert_to_virtual (reg_nr, > + sh_register_convert_to_virtual (gdbarch, reg_nr, > register_type (gdbarch, reg_nr), > temp_buffer, buffer); > } > @@ -1685,7 +1701,7 @@ sh_pseudo_register_write (struct gdbarch > base_regnum =3D dr_reg_base_num (gdbarch, reg_nr); >=20=20 > /* We must pay attention to the endiannes. */ > - sh_register_convert_to_raw (register_type (gdbarch, reg_nr), > + sh_register_convert_to_raw (gdbarch, register_type (gdbarch, reg_n= r), > reg_nr, buffer, temp_buffer); >=20=20 > /* Write the real regs for which this one is an alias. */ Gr=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 489 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQSa3JAAoJENuKOtuXzphJv0EH/AmYuHPF4NEdcTJf3T+YreBx z59V61YLUyjkNhIR/jQcVCdbbsowGB6FRHNajcdHd+9fjiIJnT+ryrPv3q8Zgzmj klk6P0BGk+unl9IPlvsmIVj9jVDl582rXlpz8xydEi437I+nXdFGkyQZ4yjC2XRa DRq2JZqSCsra9xWMWNIvijMIwCGB4/FP4WOgqq06BF5WKzJI9d0MZvLr0KrQXHf8 /5SsddL+d1sIXOZXLzVbvtGlByOr47s5kAN18n74N9a2ttxn73NiaLAF7SVGYUtA Z6ldH5Ngxh4HZHYr+E0/EYZD11XLA9xaMkrFiNA9BK8c1d/5K4ENQamKGvKDkLM= =o/at -----END PGP SIGNATURE----- --=-=-=--