From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6531 invoked by alias); 18 Mar 2014 17:54:00 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 6501 invoked by uid 89); 18 Mar 2014 17:53:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.89.28.115) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Mar 2014 17:53:57 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 0E288D8743504; Tue, 18 Mar 2014 17:53:51 +0000 (GMT) Received: from KLMAIL02.kl.imgtec.org (192.168.5.97) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 18 Mar 2014 17:53:54 +0000 Received: from BADAG01.ba.imgtec.org (192.168.146.113) by klmail02.kl.imgtec.org (192.168.5.97) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 18 Mar 2014 17:53:54 +0000 Received: from BADAG02.ba.imgtec.org ([fe80::612d:e977:c603:32d6]) by BADAG01.ba.imgtec.org ([fe80::8c38:df2b:fd93:33d3%14]) with mapi id 14.03.0123.003; Tue, 18 Mar 2014 10:53:50 -0700 From: Jack Carter To: Richard Sandiford CC: "binutils@sourceware.org" , "libc-alpha@sourceware.org" , "macro@codesourcery.com" Subject: RE: Description of MIPS/IRIX multigot Date: Tue, 18 Mar 2014 17:54:00 -0000 Message-ID: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6FB8A6@BADAG02.ba.imgtec.org> References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6FB67C@BADAG02.ba.imgtec.org>,<87mwgnhpem.fsf@talisman.default> In-Reply-To: <87mwgnhpem.fsf@talisman.default> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2014-03/txt/msg00189.txt.bz2 Richard, I genuinely enjoyed working with you. Just one shot before fading in the sunset ;-) Almost all the IRIX multigot differences are in giving an organized structu= re to describing the got layout(s). It doesn't change much of what needs to= be done within. This is a philosophical view of how to add functionality. = Always be explicit in the ELF structures for describing what is there. Be o= rthogonal in how you do it. The gnu linker would behave much the same way, creating faux GOTs for each = of the input objects and adding them, along with the other gp relative sect= ions within the input object to the current aggregate gp region. There wouldn't be a "master" GOT that included all GOT entries. Just an ini= tial GOT that would follow the dynamic symbol table order matching conventi= on for global symbols followed by other gp regions each with a GOT that use= s exclusively relocations for non-page table entries. Each GP region repres= ents a 64 K byte range max. Doesn't matter any more. My bees and chickens aren't interested in multigot= even though I have tried to go over it with them on numerous occasions. An= d my wife still wonders after all these years why I keep talking about elfs= , dwarfs and pixies. Cheers, Jack ________________________________________ From: Richard Sandiford [rdsandiford@googlemail.com] Sent: Tuesday, March 18, 2014 1:38 AM To: Jack Carter Cc: binutils@sourceware.org; libc-alpha@sourceware.org; macro@codesourcery.= com Subject: Re: Description of MIPS/IRIX multigot Jack Carter writes: > I am retiring in a few days Congratulations! All the best for your retirement. And thanks for the write-up. > * It follows the ELF philosophy of packaging data in an orderly fashion. = The > different elements of the GOT are no longer just LOCAL and GLOBAL. > Visibility like Protected, hidden and global are separated and > specifically pointed to. This helped post linkage instrumentation tools > like pixie do the right thing. I don't buy this though. Visibility information is already given by the symbol table. There's no need to duplicate it in the GOT tags. > Yes I know, you can get it working without all of the above > information, but why make a tough job tougher? Heh, well, I know I'm going over old ground, but this sounds like it _is_ making a tough job tougher :-) We already support the same thing (bar lazy binding in secondary GOTs) for GNU/Linux, in a much simpler way and without having had to extend the ABI, or surprise generic ELF readers by having several .dynamic sections. The way that the original psABI tied global symbols to the GOT was a nice trick for saving space and providing a free cache, but when it comes to secondary GOTs, the advantage seems the other way: having a relocation per GOT entry is simpler, more safe-efficient and quicker at load time than adding extra .dynamic sections and duplicating part of the symbol table. The missing feature of lazy binding in secondary GOTs could be handled by relocations too; the net effect would still be simpler than having several .dynamics. So IMO, while the psABI got it right by having an efficient way of handling simple local and global entries, other targets got it right by allowing the GOT to be just a bunch of data that can be relocated like any other. This includes relocs that weren't envisaged at the time, like TLS and ifunc. So I think the guys who added MIPS TLS made the right call by having the TLS GOT entries be relocated normally. And I think it's the right call for ifunc too. I still think it would be good to allow these normally-relocated entries in the main part of the GOT though, rather than having to tack them on after all the ABI-mandated global GOT entries (including those that are needed only because there's a relocation against a particular global symbol). As we discussed before, all that needs is a new tag. Thanks, Richard