From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2433 invoked by alias); 18 Mar 2014 08:39:05 -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 2412 invoked by uid 89); 18 Mar 2014 08:39:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-we0-f176.google.com Received: from mail-we0-f176.google.com (HELO mail-we0-f176.google.com) (74.125.82.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 18 Mar 2014 08:39:03 +0000 Received: by mail-we0-f176.google.com with SMTP id x48so5421178wes.7 for ; Tue, 18 Mar 2014 01:39:00 -0700 (PDT) X-Received: by 10.180.163.206 with SMTP id yk14mr13372339wib.5.1395131939907; Tue, 18 Mar 2014 01:38:59 -0700 (PDT) Received: from localhost ([2.28.235.12]) by mx.google.com with ESMTPSA id v6sm32588885wif.0.2014.03.18.01.38.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Mar 2014 01:38:58 -0700 (PDT) From: Richard Sandiford To: Jack Carter Mail-Followup-To: Jack Carter ,"binutils\@sourceware.org" , "libc-alpha\@sourceware.org" , "macro\@codesourcery.com" , rdsandiford@googlemail.com Cc: "binutils\@sourceware.org" , "libc-alpha\@sourceware.org" , "macro\@codesourcery.com" Subject: Re: Description of MIPS/IRIX multigot References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6FB67C@BADAG02.ba.imgtec.org> Date: Tue, 18 Mar 2014 08:39:00 -0000 In-Reply-To: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6FB67C@BADAG02.ba.imgtec.org> (Jack Carter's message of "Mon, 17 Mar 2014 22:39:33 +0000") Message-ID: <87mwgnhpem.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-03/txt/msg00176.txt.bz2 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