From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16785 invoked by alias); 17 Mar 2014 22:39:44 -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 16672 invoked by uid 89); 17 Mar 2014 22:39:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_05,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.114) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Mar 2014 22:39:41 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id DA972ED61D8E1; Mon, 17 Mar 2014 22:39:33 +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; Mon, 17 Mar 2014 22:39:37 +0000 Received: from BADAG03.ba.imgtec.org (192.168.146.115) by klmail02.kl.imgtec.org (192.168.5.97) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 17 Mar 2014 22:39:37 +0000 Received: from BADAG02.ba.imgtec.org ([fe80::612d:e977:c603:32d6]) by badag03.ba.imgtec.org ([::1]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 15:39:34 -0700 From: Jack Carter To: "binutils@sourceware.org" , "libc-alpha@sourceware.org" CC: "rdsandiford@googlemail.com" , "macro@codesourcery.com" Subject: Description of MIPS/IRIX multigot Date: Mon, 17 Mar 2014 22:39:00 -0000 Message-ID: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6FB67C@BADAG02.ba.imgtec.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2014-03/txt/msg00174.txt.bz2 I am retiring in a few days and I don't believe SGI/MIPS ever published=20 the IRIX multigot description. My work with the current GCC/MIPS=20 multigot solution has strengthened my opinion that IRIX had it right.=20 Probably because I am a linker guy and had to suffer with debugging=20 multigot issues with a lot of big iron applications and dsos ;-) In the MIPS/IRIX point of view the GOT (GlobalOffsetTable) only held=20 elements that were symbol related. Data for other GP relative elements=20 remained in their own sections. A GP region would span 64K bytes of=20 memory. GP relative sections are so marked with SHF_GPREL. Example of=20 such sections are: * .got * .sbss * .sdata * .lit4 * .lit8 If there were more GP relative section data than could fit in one 64K regio= n, Multiple GP regions were created. Each GP region had its own dynamic section describing elements that the=20 dynamic linker needed to know. The initial dynamic section had all the=20 standard dynamic tags such as : * DT_NEEDED * DT_RELA * DT_RELSZ * etc. It also had one or more DT_MIPS_AUX_DYNAMIC tags pointing to the=20 "auxiliary dynamic sections describing the other GP regions. These=20 dynamic sections had the following records: * DT_MIPS_GP_VALUE:=20 The GP value for this GP region * DT_MIPS_HIPAGENO:=20 This member contains the number of page table entries=20 in the GOT. It is used by profiling tools and is optional. * DT_MIPS_LOCAL_GOTNO:=20 Number of local GOT entries * DT_MIPS_LOCALPAGE_GOTIDX: Index of first page table entry for a segment.There will be one per=20 segment, in the same order as the segments in the segment table. They=20 are mandatory if there are page table entries for any segment, and the=20 value for a segment without any page table entries must be zero. * DT_MIPS_LOCAL_GOTIDX: This member contains the index in the GOT of the first entry for a=20 local symbol. It is mandatory if there are local symbol entries. * DT_MIPS_HIDDEN_GOTIDX:=20 This member contains the index in the GOT of the first entry for a=20 hidden symbol. It is mandatory if there are hidden symbol entries. * DT_MIPS_PROTECTED_GOTIDX: This member contains the index in the GOT of the first entry for a=20 protected symbol. It is mandatory if there are protected symbol entries. The first dynamic section, the one pointed to by PT_DYNAMIC, behaves=20 closely as we currently know and love with implicit dynamic link time=20 relocation. The auxiliary dynamic sections listed in the initial dynamic section, have only explicit relocations with the exception of the local page entries. Those entries are implicitly relocated by adding the dso=20 load offset if any. I wouldn't be surprised if all the "local" entries=20 were not implicitly relocated, but that limits what kind of relocations=20 one wants to apply. Both the initial and auxiliary dynamic sections have the auxiliary tags.=20 That is, the initial dynamic section has DT_MIPS_GP_VALUE, DT_MIPS_LOCAL_GOTNO, etc.. We had the convention of ordering the GOT regions as: 1 Reserved words 2 Page offsetsLocals: Regular locals symbol as well as STV_INTERNAL symbol= s. 3 Hidden: These are not local since they can be passed by address. 4 Protected 5 Global I'm sure we would at this time have added TLS Why do it this way? Transparency and debugging. * 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.=20 Visibility like Protected, hidden and global are separated and=20 specifically pointed to. This helped post linkage instrumentation tools like pixie do the right thing.=20 * The GOT is just another section in a GP region. When you dump the section headers you will see the other=20 sections associated with this GP one after the other, not hidden within=20 the confines of .got. Since we always started with the dynamic section=20 in the GP region, my pretty printer could display the different groups=20 of sections per GP region aided by the SHF_GPREL flag value. * Debugging. Maybe only a handful of people in the world care about debuggi= ng=20 multigot issues, but it is a major boost to be able to dump with the=20 pretty printer the detailed contents of each of the GOTs and to see the=20 full picture. When I dumped a multigot object with my pretty printer I=20 saw each of the GP values for each GP region and the contents of each of the GOTs by category. One thing I believe we lacked was the count or end of each of the GOT parti= tions. We had it for some like HIPAGENO, but not all. This is needed if you wanted= to=20 add a new partition and the heuristic of where HIDDEN ended was not just Wh= ere=20 PROTECTED began. Yes I know, you can get it working without all of the above information, bu= t why make a tough job tougher? Anyway, It is now out in public in case anyone else wants to ever adopt it = for MIPS :-) Cheers, Jack