From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id F0067389852D for ; Thu, 24 Dec 2020 20:51:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F0067389852D Received: by mail-pj1-x102d.google.com with SMTP id iq13so1576020pjb.3 for ; Thu, 24 Dec 2020 12:51:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=32isrQzrvsnQ2F1/SbWt+kNgjSdzuytpo18LjFYIsuc=; b=i9ZQheAQ3hjlcvG4kHmewl2OAm2ZN3Y2mXH4d3cHzmiDoL8EM3R4kfvBr3al9oTGIc D4Y8FDqMfrw5fBuPm2PGtGkqzU6bSuTKK+9CaWpId2lwSeRmmXZpgC56AYTeUC9ZnjDF yjXeCKbJBvpLGUzVMEZ+o7EXgO8M9Tvi9Fmd8TVFbDdSq/K8oKPA8KvchTe7eoA2wqfZ e2MgeQzEpXGLu5CSj+XHoRRzpzpbVMq5MxltTyVPkEKaGlyZhQiUlEWdVEHszQvnYQmv myRjB5oQAOzyX3DgUDLvVP6pPna0ZSQditb2u0AGczYT+Pb7kpdI5gQvxLpp2UY5E3i2 hk1w== X-Gm-Message-State: AOAM530FOEm00kuDLO2mC7Jd0IMHFtUPPzt8x9lGyo4pLCLWiNJPdGP6 FiF40dKTsx8TLoRWAX/KkdItxe815jA= X-Google-Smtp-Source: ABdhPJyDODMDWK/8RViQszk6fDX/7vlzmplNqIlqb+DVyYo3GbitOE7hfeKf4XKm9u0lB0bTvry9CA== X-Received: by 2002:a17:90a:6401:: with SMTP id g1mr5692435pjj.165.1608843098073; Thu, 24 Dec 2020 12:51:38 -0800 (PST) Received: from gnu-cfl-2.localdomain (c-69-181-90-243.hsd1.ca.comcast.net. [69.181.90.243]) by smtp.gmail.com with ESMTPSA id a26sm25670005pgd.64.2020.12.24.12.51.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Dec 2020 12:51:36 -0800 (PST) Received: by gnu-cfl-2.localdomain (Postfix, from userid 1000) id 9E6E51A03F0; Thu, 24 Dec 2020 12:51:35 -0800 (PST) Date: Thu, 24 Dec 2020 12:51:35 -0800 From: "H.J. Lu" To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [RFC PATCH 2/2] x86: Alternative implementation Message-ID: <20201224205135.GA3941053@gmail.com> References: <87tuscp45g.fsf@oldenburg2.str.redhat.com> <87mty4p3tm.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mty4p3tm.fsf@oldenburg2.str.redhat.com> X-Spam-Status: No, score=-3033.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 20:51:40 -0000 On Wed, Dec 23, 2020 at 11:15:01PM +0100, GNU C Library wrote: > This implementation uses a data symbol containing a pointer > to the bitmask array and an array length, not a function call. > The expectation is that this is the final link-time ABI for > this feature. (The run-time ABI will have to change once more, > to support use of this facility in IFUNC resolvers.) > > The __libc_vars initialization mechanism is used to set up > the copy in libc.so.6 before relocation, so that it can be used > by IFUNC resolvers. > > Usage of the C preprocessor is greatly reduced, making it easier > to wrap this functionality in other languages. > > This is still a preview. There are further cleanups possible, > including removal of the function symbol. The manual still needs > updating, and there are a few overlong lines. I'd like to receive > feedback if this is the direction in which we want to move. > > I think it should be possible to hack in IFUNC resolver support using a > custom dynamic section entry that points to a hidden __x86_cpu_array > variable. It would be cleaner to use a new run-time-only relocation for > the initialization. The dynamic section hack would not work with > --gc-sections, for instance. > It doesn't work: [hjl@gnu-cfl-2 build-x86_64-linux]$ readelf -rW math/libm.so Relocation section '.rela.dyn' at offset 0xe120 contains 13 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000140d88 0000000000000008 R_X86_64_RELATIVE f2b0 0000000000140d90 0000000000000008 R_X86_64_RELATIVE f270 0000000000140d98 0000000000000008 R_X86_64_RELATIVE 140d98 0000000000140fb0 0000000200000006 R_X86_64_GLOB_DAT 0000000000000000 _ITM_deregisterTMCloneTable + 0 0000000000140fb8 0000000300000012 R_X86_64_TPOFF64 0000000000000000 errno@GLIBC_PRIVATE + 0 0000000000140fc0 000003b200000006 R_X86_64_GLOB_DAT 00000000001410f0 _LIB_VERSION@GLIBC_2.2.5 + 0 0000000000140fc8 0000000a00000006 R_X86_64_GLOB_DAT 0000000000000000 __x86_cpu_array@GLIBC_2.33 + 0 0000000000140fd0 0000000b00000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0 0000000000140fd8 0000020800000006 R_X86_64_GLOB_DAT 00000000001410f8 signgam@@GLIBC_2.2.5 + 0 0000000000140fe0 0000021200000006 R_X86_64_GLOB_DAT 00000000001410f8 __signgam@@GLIBC_2.23 + 0 0000000000140fe8 0000000f00000006 R_X86_64_GLOB_DAT 0000000000000000 _ITM_registerTMCloneTable + 0 0000000000140ff0 0000001000000006 R_X86_64_GLOB_DAT 0000000000000000 __cxa_finalize@GLIBC_2.2.5 + 0 0000000000140ff8 0000001100000006 R_X86_64_GLOB_DAT 0000000000000000 stderr@GLIBC_2.2.5 + 0 Relocation section '.rela.plt' at offset 0xe258 contains 27 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000141018 0000000100000007 R_X86_64_JUMP_SLOT 0000000000000000 __strtold_nan@GLIBC_PRIVATE + 0 0000000000141030 0000000400000007 R_X86_64_JUMP_SLOT 0000000000000000 qsort@GLIBC_2.2.5 + 0 0000000000141038 0000000500000007 R_X86_64_JUMP_SLOT 0000000000000000 __strtod_nan@GLIBC_PRIVATE + 0 0000000000141040 0000000600000007 R_X86_64_JUMP_SLOT 0000000000000000 __strtof128_nan@GLIBC_PRIVATE + 0 0000000000141048 0000000700000007 R_X86_64_JUMP_SLOT 0000000000000000 __assert_fail@GLIBC_2.2.5 + 0 0000000000141050 0000000800000007 R_X86_64_JUMP_SLOT 0000000000000000 fputs@GLIBC_2.2.5 + 0 0000000000141060 0000000900000007 R_X86_64_JUMP_SLOT 0000000000000000 memset@GLIBC_2.2.5 + 0 0000000000141068 0000018f00000007 R_X86_64_JUMP_SLOT 000000000000f2c0 matherr@GLIBC_2.2.5 + 0 00000000001410a8 0000000c00000007 R_X86_64_JUMP_SLOT 0000000000000000 __strtof_nan@GLIBC_PRIVATE + 0 00000000001410b8 0000000d00000007 R_X86_64_JUMP_SLOT 0000000000000000 memmove@GLIBC_2.2.5 + 0 00000000001410d0 0000000e00000007 R_X86_64_JUMP_SLOT 0000000000000000 fwrite@GLIBC_2.2.5 + 0 00000000001410e8 0000000000000025 R_X86_64_IRELATIVE 46710 00000000001410e0 0000000000000025 R_X86_64_IRELATIVE 29df0 00000000001410d8 0000000000000025 R_X86_64_IRELATIVE 42430 00000000001410c8 0000000000000025 R_X86_64_IRELATIVE 33a60 00000000001410c0 0000000000000025 R_X86_64_IRELATIVE 44f20 00000000001410b0 0000000000000025 R_X86_64_IRELATIVE 48390 00000000001410a0 0000000000000025 R_X86_64_IRELATIVE 45420 0000000000141098 0000000000000025 R_X86_64_IRELATIVE 2da30 0000000000141090 0000000000000025 R_X86_64_IRELATIVE 482b0 0000000000141088 0000000000000025 R_X86_64_IRELATIVE 2d170 0000000000141080 0000000000000025 R_X86_64_IRELATIVE 257e0 0000000000141078 0000000000000025 R_X86_64_IRELATIVE 47c50 0000000000141070 0000000000000025 R_X86_64_IRELATIVE 25780 0000000000141058 0000000000000025 R_X86_64_IRELATIVE 4ea50 0000000000141028 0000000000000025 R_X86_64_IRELATIVE 298b0 0000000000141020 0000000000000025 R_X86_64_IRELATIVE 339f0 R_X86_64_IRELATIVE relocations depend on: 0000000000140fc8 0000000a00000006 R_X86_64_GLOB_DAT 0000000000000000 __x86_cpu_array@GLIBC_2.33 + 0 which is processed after R_X86_64_IRELATIVE. H.J.