From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 8F3DD21671 for ; Thu, 9 May 2024 15:38:08 +0200 (CEST) Received: (qmail 23897 invoked by uid 550); 9 May 2024 13:38:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28463 invoked from network); 9 May 2024 13:17:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715260613; x=1715865413; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DmKbqFPNfBm3B8blsJvMAzsyNQwLkPg2rBEZSvQ6Kbo=; b=fFs4/8pjpv/OAo2+78jJEI6z0VAeYnsQwragurK9cWZ8WwQxctE+MDuZPsqRxEL1Pj PCWN/FWj9Opv91873TpjzAzwq0SqgY27YiIwABI4XltlC558cfPgerxE5Asj5CcRYjcY IF9MQQignyWUgNg6kL040VaoPwY2dilCH3VpQz/dc0I5Iqu2atgH2ZK+3B1d7RVX/Y2R zP0guRVnhWiQZOfhjCOmjVYKN8DWWxA326PF7ohJl4cLxAFR/ex+Dj7MN6WVmquL+2Is PvYRbkhVyDKLFoRQMbprcxrv1kx7SMHvIdlo78Of5+LjtB+yIJF5Sgx3Ss65E93vgMpf ZvBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715260613; x=1715865413; 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=DmKbqFPNfBm3B8blsJvMAzsyNQwLkPg2rBEZSvQ6Kbo=; b=HbMubLM0+jM98lA8LgG4fMzNVcBsagTh8lMEPT7b/Ly9CLvOXGVgQIrWtFBcZ3pzRG ewyexgVrzRiod56j1u7I+gkcuw0ozDghNwk2mbx3eIJwBRRMM9xaqulbTiYWloSHJfw+ 8fsPI3bcH8fW+iLGuoDADM1zUHFIVMRWXwd3EYCHPACclOlHlIHkZ7IV1ExvpvvuFqVi Gm2a9QQaL9qpgNC9PACWLeUPurm1tZXzFsyEDN6W81KCTolhmoNGBSD+e64Xa8I4kWPt Xz86AWud9xCOb6GwHfbq3KhLONTAIxf5uiTxAa/DvNiydNFTe6u1AmSkUwVACxqitD5r Gg1g== X-Gm-Message-State: AOJu0YzkFNJ4rUC5tM6Xis2Ya9vQZzF0NUZsDd6VqsOPgOCmPLJI9a49 2lewJSOruuxv2F60mupZ8fYSJ3rfMiOnbQy5aadV8SF9ZgeuBv4CwPa4acQo/QYKMAwfb+FsLX+ DocThFQnkdg5xFn5J6lO4e8wJrOyItg== X-Google-Smtp-Source: AGHT+IHxyMy3l01HtNT4nbMnuqygIZQFiIdm0RcaMOQEC2P9/qDEpmV1pkUxSA8lCXnY0PUhVs+PFhSLBqAeGnhazBU= X-Received: by 2002:a05:6808:302c:b0:3c7:210a:bffe with SMTP id 5614622812f47-3c98d906bd5mr1152479b6e.12.1715260613257; Thu, 09 May 2024 06:16:53 -0700 (PDT) MIME-Version: 1.0 References: <20240509123516.GQ10433@brightrain.aerifal.cx> In-Reply-To: <20240509123516.GQ10433@brightrain.aerifal.cx> From: Maxim Blinov Date: Thu, 9 May 2024 14:16:44 +0100 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] IFUNC support Hi Rich, thanks for your reply, > It sounds like you have an XY problem: wanting target_clones to work. The way I got into the subject of relocs and IFUNCs, is that clang for musl RISC-V outputs binaries that generate these relocs, and one of the binaries was a test case with resolve_multiver in it. either the compiler or musl was wrong, and i initially guessed (incorrectly) that musl was at fault. > If GCC was built correctly targeting musl, it should not support ifunc > generation at all; you shouldn't end up with unknown relocations in an > output binary because the compiler should never have emitted them. That's my conclusion aswell. so far in my testing when building something with target_clones, or resolve_multiver, I see: - gcc for musl, x86_64: errors out - gcc for musl, riscv: generates binary with IFUNCs - clang for musl, x86_64: generates binary with IFUNCs - clang for musl, riscv: generates binary with IFUNCs For the LLVM side, I've opened an issue against LLVM about this (although I'm still not 200% sure its not a misconfiguration on my end.), link: https://github.com/llvm/llvm-project/issues/91313. LLVM currently appears to generate IFUNCs regardless. i admit i haven't yet properly dug around in a debugger to figure out why. For the gcc side, the reason i believe is as below: gcc x86_64 does the right thing: gcc/configure.ac imports gcc/config.gcc, which has logic[1] that turns off IFUNC support if we're targeting a triple that ends in `musl`. The resultant compiled gcc will error out if you try to use the feature. This is applied to all triples ending in `musl`, so in theory that should be the end of discussion. but gcc for *RISC-V* doesn't, because the logic for checking whether or not we have support for IFUNCS is overridden *after* gcc/config.gcc has been parsed, in gcc/configure.ac [2], by: - assembling a test assembly file with a `.type foo, %gnu_indirect_function`, - linking, - objdumping the binary and greping for `R_RISCV_IRELATIVE` well, i suppose outsourcing the logic to gnu ld is not unreasonable, but does it mean that gnu ld targeting anything ending in `musl` should throw up at the sight of `gnu_indirect_function`? [1]: https://github.com/gcc-mirror/gcc/blob/2790195500ec523cad9c7292816540e2fc19f456/gcc/config.gcc#L3670-L3684 [2]: https://github.com/gcc-mirror/gcc/blob/2790195500ec523cad9c7292816540e2fc19f456/gcc/configure.ac#L3057-L3107