From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5713 invoked by alias); 10 Oct 2006 16:24:43 -0000 Received: (qmail 5696 invoked by uid 22791); 10 Oct 2006 16:24:42 -0000 X-Spam-Check-By: sourceware.org Received: from outbound-res.frontbridge.com (HELO outbound1-res-R.bigfish.com) (63.161.60.49) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Oct 2006 16:24:36 +0000 Received: from outbound1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-res-R.bigfish.com (Postfix) with ESMTP id DF5D0104BB8D; Tue, 10 Oct 2006 16:21:48 +0000 (UTC) Received: from mail2-res-R.bigfish.com (unknown [172.18.16.1]) by outbound1-res.bigfish.com (Postfix) with ESMTP id D147E104BB8A; Tue, 10 Oct 2006 16:21:48 +0000 (UTC) Received: from mail2-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail2-res-R.bigfish.com (Postfix) with ESMTP id BB5DB797CD3; Tue, 10 Oct 2006 16:21:48 +0000 (UTC) X-BigFish: VP Received: by mail2-res (MessageSwitch) id 1160497308606621_2494; Tue, 10 Oct 2006 16:21:48 +0000 (UCT) Received: from amdext4.amd.com (amdext4.amd.com [163.181.251.6]) by mail2-res.bigfish.com (Postfix) with ESMTP id 68EB3797CC5; Tue, 10 Oct 2006 16:21:48 +0000 (UTC) Received: from SAUSGW01.amd.com (sausgw01.amd.com [163.181.250.21]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k9AGLGul020078; Tue, 10 Oct 2006 11:21:47 -0500 Received: from 163.181.22.102 by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Tue, 10 Oct 2006 11:21:42 -0500 X-Server-Uuid: 8C3DB987-180B-4465-9446-45C15473FD3E Received: from sausexmb1.amd.com ([163.181.3.156]) by sausexbh2.amd.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 10 Oct 2006 11:21:42 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC: TLS improvements for IA32 and AMD64/EM64T Date: Tue, 10 Oct 2006 16:24:00 -0000 Message-ID: <1449F58C868D8D4E9C72945771150BDF521953@SAUSEXMB1.amd.com> In-Reply-To: From: "Menezes, Evandro" To: "Alexandre Oliva" cc: "Jan Beulich" , "Michael Matz" , discuss@x86-64.org, "Andreas Jaeger" , binutils@sources.redhat.com, libc-alpha@sources.redhat.com, "Meissner, Michael" , "H. J. Lu" X-WSS-ID: 6935171C1L85489529-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00065.txt.bz2 Oi, Alexandre.=20 > > Would you consider adding the calculations for the new relocations > > in order to improve their clarity? >=20 > I can try, although relaxations make it much trickier than it might > seem. Where possible. If it gets too hairy, the text should spill the beans inst= ead. =20 > > I remember some examples in your paper at the GCC Summit and adding > > them to section 3.5 would be swell too. >=20 > So we're talking *really* self-contained, eh? Fair enough, I'll take > a shot. I appreciate it. It sure makes this psABI much more solid. As is, it alre= ady refers to too many external ABIs, such as SY, i386 and C++, so I think = that it exhausted its credit for external references. :-) =20 > > From your paper at the GCC Summit it's quite clear that such > > additions to the psABI would be a fine idea. Perhaps HJ would like > > to consider the corresponding additions for the i386 psABI > > extension. >=20 > H.J., do you have the i386 psABI in source form somewhere I could get > it, to make the corresponding changes? Actually, it's about an extension to the i386 psABI and it's an idea still = in its infancy: http://sourceware.org/ml/binutils/2006-09/msg00342.html. > > So, there's no question about the technical part of your proposal. > > But, as you can infer from my comments above, I'd like to improve > > the clarity of the psABI so that one wouldn't have to go to specific > > implementations to figure out the details. What do you think? >=20 > Sounds like a reasonable goal. >=20 > > -+referenced symbol binds locally, the \texttt{DTPOFF} may=20 > be omitted. > > ++referenced symbol binds locally, the relocations=20 > \texttt{R_X86_64_64} and \texttt{R_X86_64_32} may be used instead. >=20 > No, in such cases the linker omits the relocation entirely, and fills > the corresponding stop with the value it can compute itself. Then how would you phrase it? > If you'd rather install a patch with these minor modifications and > keep the more detailed patch separate, let me know and I'll send you > what I have right away. That sounds like a fine idea. As I haven't heard comments in contrary, the= re seems to be an unspoken agreement that it should be added. Feel free to= send the patch with minor changes and if we don't hear anything against it= until the Oct 12 (GMT), I'll apply it. Thank you, --=20 _______________________________________________________ Evandro Menezes AMD Austin, TX