From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23805 invoked by alias); 8 Feb 2005 09:30:40 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 23647 invoked from network); 8 Feb 2005 09:30:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Feb 2005 09:30:31 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j189UVuD020815 for ; Tue, 8 Feb 2005 04:30:31 -0500 Received: from talisman.cambridge.redhat.com (talisman.cambridge.redhat.com [172.16.18.81]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j189USO06463 for ; Tue, 8 Feb 2005 04:30:28 -0500 Received: from talisman.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by talisman.cambridge.redhat.com (8.13.1/8.12.10) with ESMTP id j189UKU8025225 for ; Tue, 8 Feb 2005 09:30:20 GMT Received: (from rsandifo@localhost) by talisman.cambridge.redhat.com (8.13.1/8.12.10/Submit) id j189UF67025224; Tue, 8 Feb 2005 09:30:15 GMT X-Authentication-Warning: talisman.cambridge.redhat.com: rsandifo set sender to rsandifo@redhat.com using -f To: binutils@sources.redhat.com Subject: Re: TLS support for MIPS References: <20050207230014.GA32655@nevyn.them.org> From: Richard Sandiford Date: Tue, 08 Feb 2005 16:26:00 -0000 In-Reply-To: <20050207230014.GA32655@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 7 Feb 2005 18:00:14 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-02/txt/msg00122.txt.bz2 Daniel Jacobowitz writes: > OK? Comments, questions, things I failed to explain? Haven't had chance to read the patch in detail yet, but just in case it gets a quick review, I thought I'd beter respond to one thing straight away... I don't like the way you've overloaded the %hi(%other(...)) syntax to apply to single relocations. I think it should be reserved for true composite relocations (i.e. where the output file has both R_MIPS_HI16 and R_MIPS_OTHER entries). We already have separate operators for things like R_MIPS_CALL_HI16 and R_MIPS_CALL_LO16, namely %call_hi() and %call_lo()[*]. I think it'd be simpler and more consistent to have %dtpoff_hi() and %dtpoff_lo() instead. You'd then be able to get rid of hackery like: > + /* %dtpoff may only be used immediately inside %hi or %lo, with no > + other relocations. However, use inside %hi and %lo is valid even > + with the old ABI which permits only a single relocation. > + Similarly, %tpoff may be used inside %hi and %lo even with the > + old ABI, but may also be used on its own. Convert these uses to > + a single relocation and give an error for other uses. */ > + for (i = 0; i < reloc_index; i++) I really think there should be one operator per relocation. On the same topic, it would be nice if the %op() names and R_MIPS_THINGY names were a bit more consistent. The link between alpha's operator names and relocation names is much more obvious, for example. Richard [*] and in case there's any doubt, this is an IRIX convention, not something we dreamt up for GNU. ;)