From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 9ECBB3875B49 for ; Wed, 14 Dec 2022 21:45:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9ECBB3875B49 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x22c.google.com with SMTP id g14so8035516ljh.10 for ; Wed, 14 Dec 2022 13:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=A3OObUWfFpffbVnbI8dgh/Gt+G5UQKOrWGhdFYy8HP4=; b=geg1s7YljdgMpUDx+T4cwkm+8l+BP+WrSjm/Oyl0WIURfqLnDGYb1nroarpnKrM75U SsUuswTnheHU3g4veLC5NcaaZW1+XXCSzAkilqrbZ31kXOEPUkaFoMt43VXLLUou6C/1 w01NRZZkv/PLjvgMCQuCQWSfUXClvuWYb6Pk1tQuFtIcjpxFB7E8OHrVaH0+JMI8or87 wJ6iWsSLbhfcG69iT4CzKS6r5gMZ+1abR30L+wyOm2Ci2HqYe0KhT+gur8fDppy/k7VD D5rlkVFMEZpZG+5UDaUzmgxA/fq8/U7zqr0ZGMith+AQeIV/jMEXcfAOEhMDt+YlBxCG esvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=A3OObUWfFpffbVnbI8dgh/Gt+G5UQKOrWGhdFYy8HP4=; b=BfE3R9vNK+hkAnXHN+iU43pHGWgd0ZYKvmA9abMyIN46M+Bc6K3DkKlg4mSYNEwRWc tpxibi5iG0kFksJohPStvKyjNVfNIag6vWczL60bMsI2VYncnx+XdpMsu3VE0c38olAU PfeWM+1yEEcpKEfwDTSL2EC9V0HECc+vKh2Zuht8wNzMDARrjhk3dCKSCbc5sJqiFuql kDLiCrBocM49Tfwg45BMVu8GreBvxP5Fkb3MG4H46+PQs+65HrunaZYZiCqM0zwhBoUz X8wtQMmwcnh58+F+3d11RnGkT3csuVmvJhOQvHKMNlIMUZtuJUsh/BskUCW5V0ZI5Rdd WuQg== X-Gm-Message-State: ANoB5pn8MVC2TOCkvRPffWpxqQ5OYK55QmUI2OwX7BSYvkVDVvWuvtrI +zkbHxP2XPxg653bzVIA6aCCwQ8akDcFq1ykeO30PCvb7bM= X-Google-Smtp-Source: AA0mqf4xOvmxY5TXMUJPwgqphaVP7+5K0s/87MKiHIxKDtt4cYuyCtmT8i245I8GivD5MowbP+F+YAs9H9PGhA5mXsc= X-Received: by 2002:a2e:b60a:0:b0:279:be05:96b9 with SMTP id r10-20020a2eb60a000000b00279be0596b9mr12041118ljn.250.1671054338040; Wed, 14 Dec 2022 13:45:38 -0800 (PST) MIME-Version: 1.0 References: <87y1rke9ub.fsf@oldenburg.str.redhat.com> In-Reply-To: <87y1rke9ub.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Wed, 14 Dec 2022 13:44:57 -0800 Message-ID: Subject: Re: Named local symbols in the ELF dynamic symbol table To: Florian Weimer Cc: binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3016.4 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Dec 6, 2022 at 9:11 AM Florian Weimer via Binutils wrote: > > The symbol table of /lib/ld-linux-ia64.so.2 starts like this: > > Symbol table [ 3] '.dynsym' contains 65 entries: > 33 local symbols String table: [ 4] '.dynstr' > Num: Value Size Type Bind Vis Ndx Name > 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UNDEF > 1: 00000000000318c0 160 FUNC LOCAL DEFAULT 10 _dl_error_free > 2: 00000000000234c0 16 FUNC LOCAL DEFAULT 10 __GI__dl_debug_state > 3: 0000000000029f80 368 FUNC LOCAL DEFAULT 10 _dl_tls_get_addr_soft > 4: 000000000002be00 1728 FUNC LOCAL DEFAULT 10 _dl_open > 5: 0000000000001550 64 FUNC LOCAL DEFAULT 10 _start > 6: 0000000000031540 784 FUNC LOCAL DEFAULT 10 _dl_runtime_profile > 7: 0000000000031440 208 FUNC LOCAL DEFAULT 10 _dl_runtime_resolve > 8: 00000000000312c0 384 FUNC LOCAL DEFAULT 10 _dl_close > 9: 0000000000018240 10720 FUNC LOCAL DEFAULT 10 _dl_lookup_symbol_x > 10: 000000000003ab40 80 FUNC LOCAL DEFAULT 10 _rtld_catch_error > > The interesting aspect is that these symbols are named, but are not > covered by the GNU_HASH table (because they are local). > > Is there a way to get the same effect on other targets? I want to > preserve the names of the functions that IFUNC resolvers return, > eventually improving diagnostics around IFUNC resolution. It would best > if I wouldn't have to bloat the entire symbol table for that. > Are you interested in R_X86_64_IRELATIVE symbols or something else? -- H.J.