From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29126 invoked by alias); 19 Dec 2011 18:27:16 -0000 Received: (qmail 29115 invoked by uid 22791); 19 Dec 2011 18:27:15 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_CP 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; Mon, 19 Dec 2011 18:27:00 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id BBE531B400D; Mon, 19 Dec 2011 18:26:59 +0000 (UTC) From: Mike Frysinger To: "Joseph S. Myers" Subject: Re: [patch] handle unaligned arm abs relocs Date: Mon, 19 Dec 2011 18:27:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.1.0-atsc; KDE/4.6.5; x86_64; ; ) Cc: libc-ports@sourceware.org References: <201112121920.17908.vapier@gentoo.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart23239994.qiYhs7AveW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112191326.59465.vapier@gentoo.org> X-IsSubscribed: yes Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00031.txt.bz2 --nextPart23239994.qiYhs7AveW Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 1141 On Monday 19 December 2011 12:45:30 Joseph S. Myers wrote: > On Mon, 12 Dec 2011, Mike Frysinger wrote: > > + /* Support relocations on mis-aligned offsets. */ > > + memcpy (&reloc_value, reloc_addr_arg, sizeof (reloc_value)); > > + reloc_value +=3D value; > > + memcpy (reloc_addr_arg, &reloc_value, sizeof (reloc_value)); >=20 > It seems from the discussion that it would be useful to see exactly what > code ends up getting generated for these memcpy calls. Is it a function > call or inlined? What about all the other memcpy calls in the dynamic > linker? For calls to memcpy that really are function calls, do they end > up going through the PLT, or do they end up as direct calls to the copy of > memcpy in the dynamic linker (given that it's linked with a version script > that hides memcpy along with all the other libc functions it uses, so it > shouldn't be necessary for calls to go through the PLT)? i was in the process of implementing Richard's suggestion for using a struc= t=20 and gcc attributes. but i'm hitting unrelated arm build failures which i'm= =20 trying to resolve before moving on ... -mike --nextPart23239994.qiYhs7AveW 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) iQIcBAABAgAGBQJO74HzAAoJEEFjO5/oN/WB7IcQAKwWJ5hCIyP+yPvz6QgXPvaR j7rZNDYhHws187IjSo12Jvi5q+RA1iFOZTETlUaovCS6kt9hXrCMhzF9GqMVi7L/ U8ck0IcnjhrJOdBfp2deS65B/qyhos0coHzhBkJvo26dbS13wgUE9QtL5cfObsFW CBq0wQkQxAMGpl6wWmAgxoeFlI2M2BxwukuPSHhW+npvPGjFqByozRwVedIijdcF Q6l80npou7pUawoLzYPklPO/GymThHD7DRKpnL95h+GOTSsRzq/NmbJ1PH3uXE82 5WCUQ4wKfpxO02CPE1LkEeZBrKjDIZ7GhW9n8pIXMTYf3HRsve6XgUoYM/HXUYvg 5ec19NKd2LtbmcYx8Z+5RcpkKp1OoiE/wntBjJTsz+eslJCxf8iOLtURF+0jBX58 MJ+XJhgznxTmd5069Vo3EBm9922kGqUCSZVU0R5BPJEcI2cScz4GBN7QjcKg1g5t lqjPS/i/KqWhk7uRPzkWK2k4DChJCcUGaP84Sd1FgPBkqmTlyLVtGY77TSIU39L4 Rjh7IZmlF//XJkDFderXJow+ijuoCKoP7b6+xPhvO1lG5jJvF+wXxvi5M9F6oCmz DQeA9tOgdmzSfBns/kB4WhnJV4wz7hjTogxHn6WuB7G0ZOKgy1EBjlS5GdSuFmI/ cjtIoNdxa/XqylMDsQkv =OnT8 -----END PGP SIGNATURE----- --nextPart23239994.qiYhs7AveW--