From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 397 invoked by alias); 15 Apr 2010 21:56:01 -0000 Received: (qmail 386 invoked by uid 22791); 15 Apr 2010 21:56:00 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=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; Thu, 15 Apr 2010 21:55:56 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 6DDEE1B400C; Thu, 15 Apr 2010 21:55:54 +0000 (UTC) From: Mike Frysinger To: Andrew Stubbs Subject: Re: [PATCH]: gdb: fdpic/frv: fix shared library loading Date: Thu, 15 Apr 2010 21:56:00 -0000 User-Agent: KMail/1.13.1 (Linux/2.6.33.2; KDE/4.4.1; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201004140259.39671.vapier@gentoo.org> <4BC72FC1.7020401@codesourcery.com> In-Reply-To: <4BC72FC1.7020401@codesourcery.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1271387879.icpYP1PLWr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201004151622.03290.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-04/txt/msg00481.txt.bz2 --nextPart1271387879.icpYP1PLWr Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 1958 On Thursday 15 April 2010 11:24:49 Andrew Stubbs wrote: > On 14/04/10 07:59, Mike Frysinger wrote: > > While I have no way of testing the FRV, the Blackfin FDPIC code is using > > this same base in a 100% copy& paste method since we implemented FDPIC > > the same way as the FRV guys (I'll address this in the future). This > > fix was required in order to handle shared libraries with Blackfin FDPIC > > properly, and I see no reason why it wouldn't also work for FRV (since > > the uClibc ldso FDPIC code is the same too and that's really what this > > is poking). >=20 > I'm currently working on FDPIC support for SH-2A uClinux, so I have been > poking at this same area myself. >=20 > The FRV code would not work for me out of the box - it's a little too > FRV specific, so I started work on another copy and paste, but thought > better of it. >=20 > What I've got now is the bones of a solib-fdpic.c which is intended to > be architecture independent. This should be possible since, so far, all > the FDPIC Linux implementations I've seen use the same basic ABI, and > the SH FDPIC will follow suit. sad, because ive already done the same thing and it's working for Blackfin= =20 FDPIC. but we've implemented FDPIC the same was as FRV. > The first major departure from solib-frv.c is that I've implemented a > new qXfer remote protocol packet to retrieve the load maps (a pseudo > register did not seem like a good plan). This should be target > independent also - I believe FRV has the same ptrace interface as SH, so > it should Just Work. i posted a Linux patch a while ago to move the FDPIC ptrace defines out of = the=20 arch-specific code and into the common ptrace code. it was acked by everyo= ne,=20 but i guess i need to push andrew to merge it. i dont have a problem with a pseudo register for the loadmaps ... seems lik= e a=20 simple/straightforward way of getting the info rather than having to extend= =20 the gdb protocol. -mike --nextPart1271387879.icpYP1PLWr 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.14 (GNU/Linux) iQIcBAABAgAGBQJLx3VrAAoJEEFjO5/oN/WBO9MP/2zr12iKZM9XTD9DJeTEFPzP yTqY8zbvXIXnqKNDFzkb96ungIYQnjgu2NRQlJ6/q1fsIU95vgl9pXH8b/lfEUKd 79Bl+I2QolnAB+KH2lNaMc4thjoy66j1FcAkY9Uw5HWe4bjZlzERCj2A+a165UCV gV6Cln2SLviHSgOxNgcRXSqetBZ7P0ByDUyWAbZbM3X93x6zqTqEM8W/XribZWCQ U8XETdi1X92+fY3kanTDyNN7cEGNX93W6wulh95Uh23647HJJIfZmbsXfGO5g0fp Webq90+F15V4Skr1osIfKWApmTkYV47cXsiEK37Ppf8ukYTdx/DbHrZymYawtsvt EH3khRKKsFuliDTtVBoeLu7pP1d7fmioabwL/jvY3l0MouIujOk235+9z4y0lFrf +f271uvMUlu3mpDUFS0wwaZiDeHYXGicmkBjGEMgp88bRsOgZbqbgETVlt0XjaAp gG4VEZ6BoJX5LsARc4L5ZDTIwHPMn9TQRezI+bRz5fTmIleLVCVpyPMcykS6+oA4 zLw42BdzSghU1YoYTy7sARGaCtCudDdAudux1jaZT9Ybr9e8ibLjTTUKyN6OyEvj yHVYCL9/Q+3L2OKZHqRJvQ1CYMJCFaBYd9umluHjTdCO9SlggZ8ZFS/Nm4dK47tB oFnJi9WPDQp1Z8gBUuZt =/Kr1 -----END PGP SIGNATURE----- --nextPart1271387879.icpYP1PLWr--