From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25739 invoked by alias); 20 Aug 2013 00:38:06 -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 25730 invoked by uid 89); 20 Aug 2013 00:38:05 -0000 X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 Received: from multi.imgtec.com (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 20 Aug 2013 00:38:04 +0000 From: Jack Carter To: "Joseph S. Myers" CC: "libc-ports@sourceware.org" Subject: RE: [RFC][PATCH] MIPS ifunc for glibc Date: Tue, 20 Aug 2013 00:38:00 -0000 Message-ID: <4CEFBC1BE64A8048869F799EF2D2EEEE01AAEA08@BADAG02.ba.imgtec.org> References: <4CEFBC1BE64A8048869F799EF2D2EEEE01AAE1FA@BADAG02.ba.imgtec.org>, In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01192__2013_08_20_01_38_02 X-SW-Source: 2013-08/txt/msg00017.txt.bz2 Joseph, Good comments. See inline. Thanks for looking at this! Jack ________________________________________ From: Joseph Myers [joseph@codesourcery.com] Sent: Sunday, August 18, 2013 1:38 PM To: Jack Carter Cc: libc-ports@sourceware.org Subject: Re: [RFC][PATCH] MIPS ifunc for glibc On Sat, 17 Aug 2013, Jack Carter wrote: > > This is the initial MIPS ifunc patch for glibc. This patch should be > > applied in conjunction with the binutils patch. >=20 > Do you have an ABI document specifying all the relevant semantics, for all > three ABIs? All three abis, o32, n32, 64 should behave the same. I have only tested o32= and thus this patch just vouches for that abi. The others were to follow i= n subsequent patches. This is what I had in the accompanying binutils patch: All ifunc functions are represented in .iplt section stubs and=20 in the .igot.plt section table. Each igot.plt entry has an R_MIPS_IRELOCATE relocation record against it with the initial igot entry having link time address of the ifunc routine and=20 after the relocation action, the final runtime target routine address. The only change to the traditional MIPS GOT was to use the .iplt stub address for the defined ifunc function instead of the function address. This should allow seamless multigot support *************************************** If an iplt is needed: Generate iplt stubs (.iplt) Generate igot table (.igot.plt) Generate IRELATIVE relocations for igot Iplts are needed for a.outs only. Non-shared a.outs:=20 Always goes through the iplt with IRELATIVE relocations against the igot. Shared a.outs (both fPIC and not): All a.out references are direct with got entries containing ifunc addresses that have IRELATIVE relocations against them. The dynamic linker will catch the IRELATIVE relocations and do the fixup based = on the GOT contents =20=20=20=20=20=20=20=20 Dso references are through the iplt with IRELATIVE relocations against the igot and the dynsym entries being the iplt address and the symbol type changed STT_FUNC. The dynamic linker will update the igot table in the a.out in the same manner as it does the GOT. Dsos: No iplt, igot or IRELATIVE relocations. =20=20=20=20=20=20=20=20 The GOT and .dynsym will have the ifunc values and the dynsym type will remain STT_GNU_IFUNC. The dynamic linker will detect that=20 the symbol is an STT_GNU_IFUNC and do the fixup based on the defini= ng dynsym address. In all cases the contents of the igot is the ifunc address with an R_MIPS_IRELATIVE relocation against it. In all cases the contents of the got for the ifunc functions are the ifunc addresses. *************************************** Is this enough? If not, could you point me to an example I could model afte= r? > 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, ret= urning the address to said function.=20 Does the rough ABI I gave above answer your question? If I missed any conditions, could you be specific? > > + case R_MIPS_IRELATIVE: > > + { > > + ElfW(Addr) value; > > + > > + /* The address for the got entry storing the address for the */ > > + /* ifunc routine is in this relocation. To get the address of */ > > + /* the function to use on this machine the ifunc routine is run */ > > + /* and its return value is the address which is then put back */ > > + /* into the got entry. */ > Ordinary multi-line comment, please. This was just missed. Thanks for catching it. -- Joseph S. Myers joseph@codesourcery.com