From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10087 invoked by alias); 20 Aug 2013 14:03:01 -0000 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 Received: (qmail 9973 invoked by uid 89); 20 Aug 2013 14:03:00 -0000 X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.2 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 20 Aug 2013 14:02:59 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VBmWP-0001kA-NS from joseph_myers@mentor.com ; Tue, 20 Aug 2013 07:02:57 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Aug 2013 07:02:58 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Tue, 20 Aug 2013 15:02:55 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VBmWM-0005ap-Mb; Tue, 20 Aug 2013 14:02:54 +0000 Date: Tue, 20 Aug 2013 14:03:00 -0000 From: "Joseph S. Myers" To: Jack Carter CC: "libc-ports@sourceware.org" Subject: RE: [RFC][PATCH] MIPS ifunc for glibc In-Reply-To: <4CEFBC1BE64A8048869F799EF2D2EEEE01AAEA08@BADAG02.ba.imgtec.org> Message-ID: References: <4CEFBC1BE64A8048869F799EF2D2EEEE01AAE1FA@BADAG02.ba.imgtec.org>, <4CEFBC1BE64A8048869F799EF2D2EEEE01AAEA08@BADAG02.ba.imgtec.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-08/txt/msg00018.txt.bz2 On Tue, 20 Aug 2013, Jack Carter wrote: > Is this enough? If not, could you point me to an example I could model after? What you have doesn't really look like an ABI document at all; it looks like an implementation sketch. I don't know what you mean by "a.outs" at all, let alone "Non-shared a.outs" and "Shared a.outs". Please use the appropriate terminology from the gABI and existing psABI documents. For example, if you mean ET_EXEC (which of course excludes PIEs, which are ET_DYN objects that can also be executed directory), then say so. If you mean a particular subset of ET_EXEC objects, be clear about what subset (again, in standard terms). If you mean some ET_EXEC and some ET_DYN objects, again, make that clear. The specification should ideally be sufficient for someone to write an interoperable static or dynamic linker without needing to refer to an existing implementation. As an example, you could always look at the existing MIPS o32 ABI document (from SCO, last updated 1996). Like many such documents, it is of limited current value for reliably describing any ABI in current use. But it indicates the sort of level of detail in such specifications, and thinking in terms of what text should be inserted where in the document is a good starting point for thinking about how to specify an ABI extension. Or see the non-PIC ABI specification . Among other things, the specification needs to state the values of any new relocations.... (Your text mentions both R_MIPS_IRELOCATE and R_MIPS_IRELATIVE but never gives them numeric values.) > > Why aren't you consistently passing the HWCAP value to resolver functions > > (it seems some places pass it but others don't)? If you don't pass it > > from the start, it could be problematic to change the ABI later to start > > passing it, as applications' IFUNC resolvers wouldn't know if they are > > being run with a glibc version that passes the HWCAP value to them or not. > > The ABI document should presumably specify what arguments get passed to > > the resolver function.... > > I am not sure what you mean by passing the HWCAP value to the resolver. > The resolver contains logic that determines the HWCAP and from that > picks the actual function that is most appropriate for the hardware > being run on, returning the address to said function. In elf_ifunc_invoke, you do > + return ((ElfW(Addr) (*) (unsigned long int)) (addr)) (GLRO(dl_hwcap)); but in other places you do e.g. > + value = ((ElfW(Addr) (*) (void)) value) (); and there is no apparent reason for the difference, or any comments explaining why it's OK not to pass the argument in some cases - how you can know that the resolver functions don't need the argument when called in those cases. > Does the rough ABI I gave above answer your question? No. It doesn't seem to say anything about what the type of the resolver function is and the significance of its arguments / return value. (Regarding the return value, I guess it should also be explicit how addresses of MIPS16 / microMIPS functions are returned.) -- Joseph S. Myers joseph@codesourcery.com