From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24714 invoked by alias); 15 May 2013 17:12:47 -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 24700 invoked by uid 89); 15 May 2013 17:12:46 -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 17:12:45 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id ECBC433DE43; Wed, 15 May 2013 17:12:43 +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 17:12: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> <201305151206.57607.vapier@gentoo.org> <5193B71E.30402@codesourcery.com> In-Reply-To: <5193B71E.30402@codesourcery.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2660599.s0o0QsvEVc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201305151312.46470.vapier@gentoo.org> X-Virus-Found: No X-SW-Source: 2013-05/txt/msg00549.txt.bz2 --nextPart2660599.s0o0QsvEVc Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 1490 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: > >> uClibc-based targets can load their programs in an offset in memory, a= nd > >> this information has historically been communicated to gdbserver via > >> ptrace with the following options: PT_TEXT_ADDR, PT_DATA_ADDR and > >> PT_TEXT_END_ADDR. > >=20 > > well, not to be pedantic, but this is for FLAT programs, not uClibc >=20 > Ok. uClibc has been used here due to its gdbserver-specific #if guard > explicitly checking for UCLIBC and mmu-lessness. because no other C lib supports FLAT currently :) > >> We have a target that uses loadmaps as opposed to the above mechanism. > >> It is just another ptrace request, but it doesn't use linux_read_offse= ts > >> 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).= =20 > > 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. i thought someone already committed support for DSBT, and i helped merge so= me=20 of the FDPIC differences. it was for the c6x port iirc. -mike --nextPart2660599.s0o0QsvEVc 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) iQIcBAABAgAGBQJRk8IOAAoJEEFjO5/oN/WBRJQP/1Mr980uYGDvlKtKKP4GWaCH /NcJ1CWvcCos3Joz6JhQJ2/T7yKTUTcZrS+VLqHxJaJmxN9XqopeiZ7HtG2CPHmW Jf9aPlFLP841jMY5wnEH8nCFPB3aa+/cTtZAFV4W994HztwdBuax3nW4VMQDvel9 8XqMpsS6jhKt655/u6MaQzv/zkh/+JqxM19kb3au1l8HDLM9JLp3dHTKo7Cuk5iC bogEHCnuZ/godw8ts1/oml6VOrXRwKA3GQfREHa9d7cIL3yUiORX0LXjVIaKpuRr y5iYT7WPibG88P/WWuXQRZD8QzR7cBQqRmqV5OiCvaLdkcAllHhmXkt5Y4HcZ+LH S5gctaIsGpuut30EmOy4FHQhvPwQFk/5wLJdjXPvXzDUXykrwy82P92zjtknUaLc t0gDFCmEXhJX+97gBxg3n31hie9ZOiR0/w9j/88KWtUsAhD9ptGCtH5hPVF4U7Ov qoDhnatD+k87dQifMhFnQ8Bdn4S7f7t+iN6VwYrSgJXXwOf9BHq1xKMIucorZHCu AmfTIj6c9M1AJumBGDGHz3a+tUVOiAxFvT/aryoWbgIUe3Wgg9LxX6gO0/6DPfMD ScsJs88PAYmGIawsQjBuIyUZDTBhz/HH70rAp4RVtKNQbXNLff1sq/M4uFmtr6RB CSSmFtDqjBPThl+forMs =qaqB -----END PGP SIGNATURE----- --nextPart2660599.s0o0QsvEVc--