From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3777 invoked by alias); 15 May 2013 18:51:56 -0000 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 Received: (qmail 3750 invoked by uid 89); 15 May 2013 18:51:52 -0000 X-Spam-SWARE-Status: No, score=-9.4 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 15 May 2013 18:51:51 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id AC07E33BDD7; Wed, 15 May 2013 18:51:49 +0000 (UTC) From: Mike Frysinger To: lgustavo@codesourcery.com Subject: Re: [RFC, gdbserver] Avoid defining linux_read_offsets when the target does not need it Date: Wed, 15 May 2013 18:51:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.8.3; KDE/4.6.5; x86_64; ; ) Cc: "'gdb-patches@sourceware.org'" References: <519370AE.50908@codesourcery.com> <201305151312.46470.vapier@gentoo.org> <5193CEE3.4040506@codesourcery.com> In-Reply-To: <5193CEE3.4040506@codesourcery.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6257715.mHobEBHsyq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201305151451.52667.vapier@gentoo.org> X-Virus-Found: No X-SW-Source: 2013-05/txt/msg00557.txt.bz2 --nextPart6257715.mHobEBHsyq Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 2061 On Wednesday 15 May 2013 14:07:31 Luis Machado wrote: > On 05/15/2013 07:12 PM, Mike Frysinger wrote: > > On Wednesday 15 May 2013 12:26:06 Luis Machado wrote: > >> On 05/15/2013 06:06 PM, Mike Frysinger wrote: > >>> On Wednesday 15 May 2013 07:25:34 Luis Machado wrote: > >>>> We have a target that uses loadmaps as opposed to the above mechanis= m. > >>>> It is just another ptrace request, but it doesn't use > >>>> linux_read_offsets at all. > >>>=20 > >>> you mean FDPIC ? gdb already supports that and uses a different set = of > >>> ptrace requests for that. ideally, gdb nor gdbserver should not be > >>> tied to a specific file format (what format it happened to be compiled > >>> for). instead, gdbserver should support all formats and then gdb > >>> detects the format and changes its requests based on that. > >>=20 > >> Not FDPIC, but DSBT. I agree gdb/gdbserver should be format-agnostic, > >> but it grew like this. Let's not extend the uglyness though. > >=20 > > i thought someone already committed support for DSBT, and i helped merge > > some of the FDPIC differences. it was for the c6x port iirc. >=20 > That is correct, but there are a few differences in the loadmap format > between targets. My idea is to clean that up and make it more generic > without having to use #if blocks inside linux-low.c. as long as the functionality isn't based on the format gdbserver itself is= =20 compiled as, sounds fine. i believe we cleaned up all the DSBT logic so th= at=20 it isn't fighting with FLAT (i know on Blackfin we have a single gdbserver = that=20 can support FLAT or FDPIC). glancing at the code, we do fail slightly in that it's currently DSBT||FDPI= C,=20 but in practice that hasn't mattered as no one has implemented both formats= =20 for the same architecture. personally, i'd be interested in why DSBT was conceived in the first place= =20 instead of using the existing FDPIC. are the minor differences on purpose = ?=20=20 by accident ? or why people are using a different format from either DSBT = or=20 FDPIC ... -mike --nextPart6257715.mHobEBHsyq 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.17 (GNU/Linux) iQIcBAABAgAGBQJRk9lIAAoJEEFjO5/oN/WB4UIQAKvjDolMaCqPw/I+ptaJga66 KUNxuCQjvFE5gZvD9gcCxH4wlBB6IvC0MdDsW4xYXw2cuk8lLi7e9ru0qHBxN2Us i/9E0z7ohcW7jnZ0cTtu2DadB66RoOKtJBhnhQkB2NFZZcHePGrLGqgapfZaDCTB hjp6q3VVWICasE9D6EVjjPrngvwdUxhKWbSwzAMYZ5penUGwEHg9kLIwsxw01FrI OqcCxo7NXsVG+635H9x0SuHHHHEkfzM83eY2jIURAQVpqYG/hzhcKYIMmj3C1XUu AISPtHB9ss4508s6b1moRiSoSGGG+D8NtyUHawm3iF14GjDOpWGdkF6Cw6TobGoN mK/Lud6BJxKk6CMu67wSO3q5EsZ+Izo7CmP1QNXz6bYFcI1NtiBRAKFPtVD4lJ39 wXq2MtTY+Rx+bKXrpbQ7YgIaM8TPkAH3mOY15y+kubAsOn4e9fN7KR13AYs9gjSG BlLQPbiogmmXFwGTydbnE9Tb6HmniolmAfq+wqwtMbk4v6IeKDemzko1E6Yyis2n bJm8fve89ujef4HEofcRs8UexWiaHvipaPdrygKg9iOQJCtBEQxkXx4w87QUORCw ixh668oiGHg8rAOdpyd2lgNmd5kW7FqvTGFWu0S9yBcYYU/4E91L9aaunq6Kkdmz +LmzdL5/8jWlPwPh03JV =w9I6 -----END PGP SIGNATURE----- --nextPart6257715.mHobEBHsyq--