From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1334 invoked by alias); 14 Dec 2010 16:58:38 -0000 Received: (qmail 1321 invoked by uid 22791); 14 Dec 2010 16:58:36 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,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; Tue, 14 Dec 2010 16:58:31 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0FD091B400D; Tue, 14 Dec 2010 16:58:30 +0000 (UTC) From: Mike Frysinger To: Pedro Alves Subject: Re: [PATCH v2] gdbserver: bfin: new port Date: Tue, 14 Dec 2010 16:58:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.37-rc5; KDE/4.5.2; x86_64; ; ) Cc: gdb-patches@sourceware.org, Andrew Stubbs , toolchain-devel@blackfin.uclinux.org, Daniel Jacobowitz References: <1291886957-12003-1-git-send-email-vapier@gentoo.org> <201012141009.44333.vapier@gentoo.org> <201012141631.33866.pedro@codesourcery.com> In-Reply-To: <201012141631.33866.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6771907.pgvbBhFMdO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201012141157.49676.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/msg00241.txt.bz2 --nextPart6771907.pgvbBhFMdO Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-length: 1081 On Tuesday, December 14, 2010 11:31:33 Pedro Alves wrote: > On Tuesday 14 December 2010 15:09:43, Mike Frysinger wrote: > > if the gdbserver code can remain backwards compatible with the Linux AB= I, > > then i dont have a problem changing to a qXfer style. >=20 > I don't think there'd be a problem with that. gdbserver can continue > fetching whatever it needs from the kernel using the ptrace registers > api, but that'd remain hidden from gdb (or the remote protocol). Getting > rid of the fdpic pseudo registers from the core register set also > presumably unifies the gdb core register set with an eventual bare metal > bfin toolchain (btw, isn't there such a thing?) or any other eventual > non-fdpic bfin toolchain. thinking about it more, the gdb port atm doesnt support FDPIC. so if the o= nly=20 contentious point of the gdbserver code is the FDPIC handling, then i can=20 simply drop that and revisit when the Blackfin/FDPIC core code is merged. we do Blackfin bare metal every day. from the Blackfin side of things, it'= s=20 the same as doing Linux/FLAT. -mike --nextPart6771907.pgvbBhFMdO 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) iQIcBAABAgAGBQJNB6INAAoJEEFjO5/oN/WB32kP/Rpvm71ePkLRocugfNeWhY3R i9DzRjHQh1yvvEQs2ALQDm5fxiJlKPCf7kULuF4kpQ0gCL1mblE9UjjMJbzTuAqe 2vz/EeHRUisTakwm+NGUih+QfRhg2Z/fBoozBdeUx3HCmmZNs0PhrWqgDR3yIIHL j5JPtxz9kiAWE26ZBHKbV0Aza596a3+HLHdQSSG1EZU4RKr3P2OngQbEQLF4CgEA zJ0b+M7cCbBmd3WgwI+pxfwx4LmCSwhA9EG+hg2IG2hIPVUZzjF0hxxigV5aXK3B rtCaTOOhl52OQ/fi17X3nQqKXmYGnatjKwftRqdGv/yUTXUT/IcQF/TKKsbBPVXU 02GYYsJkTA/HPIQ8KUIeJus5gp/5sd3QsMnYsuaKhomuBSxzXZhtRg1OWH/NixeN /Lb3ItKWU4AiPG8zi5xiMauWVMaGLe1G1WmPmtUmSajg1bV7YH4qocQi699HffCY Hymb96oPPZCoKBxbO77xy0fsnuOSYLqjofbqK4ocLkM/RDHS/NUZCtl3vOthVF+n bZM6FHBwhfBtenQKKUZrB9GyAxWL6i32D4m3LLrZWQympwV+UPLcR8eSTO244D1F mbQ2sG5puy3YIvGg+uERGgFlgd/FRvetonyCf9Varis0avibhZYtqKuaPidHpZIW FCkQ/XR0E31WTa9zHMn2 =j9OQ -----END PGP SIGNATURE----- --nextPart6771907.pgvbBhFMdO--