From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2243 invoked by alias); 15 Dec 2010 18:16:25 -0000 Received: (qmail 2234 invoked by uid 22791); 15 Dec 2010 18:16:24 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_EG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Dec 2010 18:16:20 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2C8371B4119; Wed, 15 Dec 2010 18:16:18 +0000 (UTC) From: Mike Frysinger To: gdb-patches@sourceware.org Subject: Re: [PATCH v3] gdb: bfin: new port Date: Wed, 15 Dec 2010 18:16:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.37-rc5; KDE/4.5.2; x86_64; ; ) Cc: Pedro Alves , toolchain-devel@blackfin.uclinux.org References: <1291886957-12003-1-git-send-email-vapier@gentoo.org> <201012151649.32678.pedro@codesourcery.com> <201012151207.12141.vapier@gentoo.org> In-Reply-To: <201012151207.12141.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart51703176.e6kgXKC0bq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201012151315.26479.vapier@gentoo.org> X-IsSubscribed: yes 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: 2010-12/txt/msg00310.txt.bz2 --nextPart51703176.e6kgXKC0bq Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 4178 On Wednesday, December 15, 2010 12:07:11 Mike Frysinger wrote: > On Wednesday, December 15, 2010 11:49:32 Pedro Alves wrote: > > Thanks for the explanations. This makes it so that the ASTAT.CC bit > > can easily end up out of sync with the CC register in gdb's > > regcache then, right? E.g., "p $cc =3D 1; p $asat" will still show the > > $asat.cc as 0, IIUC. Does the kernel actually store CC on its > > own slot in the register stack? I ask because I see it commented out > > in bfin_regmap in gdbserver. If $cc was a pseudo-register _managed_ by > > gdb (computed from ASAT), then this out-of-sync-ness would never happen. >=20 > no, linux does not give CC dedicated space in the signal context. it does > look like setting $cc on the command line results in out-of-sync values > with $astat. i'll take a look at the pseudo helpers you referenced and > see if i cant figure out how they work. what do you think of this ? seems to work for me: (gdb) set $cc =3D 0 (gdb) printf "%x %x\n", $astat, $cc 2002002 0 (gdb) set $cc =3D 1 (gdb) printf "%x %x\n", $astat, $cc 2002022 1 (gdb) set $astat =3D 0 (gdb) printf "%x %x\n", $astat, $cc 0 0 (gdb) set $astat =3D 0x20 (gdb) printf "%x %x\n", $astat, $cc 20 1 -mike --- a/gdb/bfin-linux-tdep.c +++ b/gdb/bfin-linux-tdep.c @@ -88,7 +88,6 @@ static const int bfin_linux_sigcontext_reg_offset[BFIN_NU= M_REGS] =3D -1, /* %retn */ -1, /* %rete */ 21 * 4, /* %pc */ - -1, /* %cc */ }; =20 /* Signal trampolines. */ --- a/gdb/bfin-tdep.c +++ b/gdb/bfin-tdep.c @@ -116,16 +116,12 @@ /* The maximum bytes we search to skip the prologue. */ #define UPPER_LIMIT 40 =20 -#define RETS_OFFSET 4 +/* ASTAT bits */ +#define ASTAT_CC_POS 5 +#define ASTAT_CC (1 << ASTAT_CC_POS) =20 /* Initial value: Register names used in BFIN's ISA documentation. */ =20 @@ -683,6 +683,36 @@ bfin_register_name (struct gdbarch *gdbarch, int i) return bfin_register_name_strings[i]; } =20 +static void +bfin_pseudo_register_read (struct gdbarch *gdbarch, struct regcache *regca= che, + int regnum, gdb_byte *buffer) +{ + gdb_byte *buf =3D (gdb_byte *) alloca (MAX_REGISTER_SIZE); + + if (regnum !=3D BFIN_CC_REGNUM) + internal_error (__FILE__, __LINE__, + _("invalid register number %d"), regnum); + + regcache_raw_read (regcache, BFIN_ASTAT_REGNUM, buf); + buffer[1] =3D buffer[2] =3D buffer[3] =3D 0; + buffer[0] =3D !!(buf[0] & ASTAT_CC); +} + +static void +bfin_pseudo_register_write (struct gdbarch *gdbarch, struct regcache *regc= ache, + int regnum, const gdb_byte *buffer) +{ + gdb_byte *buf =3D (gdb_byte *) alloca (MAX_REGISTER_SIZE); + + if (regnum !=3D BFIN_CC_REGNUM) + internal_error (__FILE__, __LINE__, + _("invalid register number %d"), regnum); + + regcache_raw_read (regcache, BFIN_ASTAT_REGNUM, buf); + buf[0] =3D (buf[0] & ~ASTAT_CC) | ((buffer[0] & 1) << ASTAT_CC_POS); + regcache_raw_write (regcache, BFIN_ASTAT_REGNUM, buf); +} + static CORE_ADDR bfin_frame_base_address (struct frame_info *this_frame, void **this_cache) { @@ -783,7 +813,9 @@ bfin_gdbarch_init (struct gdbarch_info info, struct gdb= arch_list *arches) tdep->bfin_abi =3D abi; =20 set_gdbarch_num_regs (gdbarch, BFIN_NUM_REGS); - set_gdbarch_num_pseudo_regs (gdbarch, 0); + set_gdbarch_pseudo_register_read (gdbarch, bfin_pseudo_register_read); + set_gdbarch_pseudo_register_write (gdbarch, bfin_pseudo_register_write); + set_gdbarch_num_pseudo_regs (gdbarch, BFIN_NUM_PSEUDO_REGS); set_gdbarch_sp_regnum (gdbarch, BFIN_SP_REGNUM); set_gdbarch_pc_regnum (gdbarch, BFIN_PC_REGNUM); set_gdbarch_ps_regnum (gdbarch, BFIN_ASTAT_REGNUM); --- a/gdb/bfin-tdep.h +++ b/gdb/bfin-tdep.h @@ -74,13 +74,14 @@ enum gdb_regnum { BFIN_RETN_REGNUM, BFIN_RETE_REGNUM, =20 - /* Pseudo Registers */ + /* Pseudo Registers managed remotely. */ BFIN_PC_REGNUM, - BFIN_CC_REGNUM, =20 - /* LAST ENTRY SHOULD NOT BE CHANGED. */ - BFIN_NUM_REGS /* The number of all registers. */ + /* Pseudo Registers managed locally. */ + BFIN_CC_REGNUM }; +#define BFIN_NUM_REGS (BFIN_PC_REGNUM + 1) +#define BFIN_NUM_PSEUDO_REGS (1) =20 /* The ABIs for Blackfin. */ enum bfin_abi --nextPart51703176.e6kgXKC0bq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJNCQW+AAoJEEFjO5/oN/WB3PAQAKPAIgEh1MMa4y2MoS7S3JhH BRCCIuAxwvVmJsYMzX7n7DlyWU7AQDIcD/cLuJFbD3jSvyrvpR+ArKVVeE53GUsM nk2D1k+i6ekg1gvS4hTM4ttGjS+hPMvTZYi3e1en29RNb+5GSeq0O+4lIZnnoXU6 er1w/vj8SQkISHsRKGF5zcapToWmkhSxKmj7EJs2Lp9u7uI+zVyUKKHU62b0aJ66 9bPxjMQFd+khW7IdA861oD30OhyZSavTfyw7xOlFf3SKTdNArNrmPMMR6G7JLvEg FfVxpdzDDpT8RghyeRJyC7GE1p+0AJAhKMVGzM717fmKYfMaaMybu2+QprbfLA1S 1rS+8RoG+xuHBMehUEOgdVWZg274fyt/LpqStjAm2V/4Td4vNqB8eKCS6Fn0CjRU KfoZanfUBQvSWRV4zqPSXenhU/JMzvnJdtZaE55mHyYrWNPxC8dKuOGzO0V+pCHv wM0aJ+r50wEn3qoZyv7lbN7fyO8PMMBzqbGkuTjLS3oKoDfNVZ5/5ZG8/xX9+7aL qxqjhTzm+J3MH1pvZcuoxAclNZCwxAilEdNwQCNIzS/6AlDu65Fznf8ntgEejv5n QW3LNQUphX/BLAVmn+btBkXXw5YNvmXtFIrnsQemjl43NxbkRMakzy4KxIbQJxqb tq6tv4FJHBTgHApdk11V =ZpId -----END PGP SIGNATURE----- --nextPart51703176.e6kgXKC0bq--