From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id BE3533858C2C for ; Mon, 27 Mar 2023 16:54:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BE3533858C2C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x22c.google.com with SMTP id bj20so6852736oib.3 for ; Mon, 27 Mar 2023 09:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1679936082; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=qyh356bc9q6wUMgCmrAtxYr+qqQYSCRw+Fel2PcnvCc=; b=bQLwHeoNB8Yx1Vx1/rlAKo1GaYG2e3FCKzC5jC5mF5XUdJAH9/fDt/iAwnkQjqZ//h QnxSCtEleBrratDmRihZN4CtPDN0u/81aZKAC7XmK7Qbim3m5UMmJEkW51H9jXaL6SCx GVFgXwEI0An7WZEOsn7+ge2piUrt90i1ij8Z0vYZG/9+KtTRRCxX7gJoRXpnW5eI0HOe w1SlCcvDD3/hJHNyj6qeMzF379cIhZYAbJSesb7PfrUxNd1+WKoPwgjWamFEgW5YHbbm VfRTlJpon4j6G804giX2pJTW23IQAzAs/OPe9JuoIAawv51quwipkxncV61fsHne6PSD ZUeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679936082; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qyh356bc9q6wUMgCmrAtxYr+qqQYSCRw+Fel2PcnvCc=; b=lxC5/w81otUNDJcu9QgK9WghUSW3vCCZYkk5/p1qzOLh8P89Lh7kkUbEnKxTSlUPEJ IWeK71NArZ5PG/vM0A0y+oSfz34UAvXmO3732J7bEa8i6vNkOL7Rno3oOZgaZPvU5c2m 1hWyg7nqbgDC9cDVfsT7/Tqr0dP4bH6TcGGOV3A4TOob2A+Np6MRxdwSZNwAHeISVG5M QwoB5bIOJugJiAU67epGViLRvnk51L6YstaJo5HDRG7HminiVW2wHu4rAU54eohDK6Yx UsH0sWqqD1/Qmelg1BLYUQFSBZ8VI+u0nEnotEZa1U8tkgGwgKPxtd/dBsx88pjPsI6+ nx9w== X-Gm-Message-State: AO0yUKXrXzf3nmRBlz71e/n+qHngyP9lhgl0t67LfcBwaZIkq6Y8LEjO Vv8FKbtzF6q+k1a9g4TKgmxdbA== X-Google-Smtp-Source: AK7set8dVbUNGfTFn+0O4CgGQwlYcpLz/WeSNvYPla8vSzBFQ3VZWlEmsOymw+PVUmSUQZuwsL68Bw== X-Received: by 2002:a05:6808:12:b0:387:1bf:26c5 with SMTP id u18-20020a056808001200b0038701bf26c5mr5815997oic.16.1679936081525; Mon, 27 Mar 2023 09:54:41 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:60f9:9d7f:7b90:a6ae:401d? ([2804:1b3:a7c1:60f9:9d7f:7b90:a6ae:401d]) by smtp.gmail.com with ESMTPSA id a14-20020a056808098e00b00383ef58c15bsm1160381oic.28.2023.03.27.09.54.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Mar 2023 09:54:40 -0700 (PDT) Message-ID: Date: Mon, 27 Mar 2023 13:54:37 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] LoongArch: ldconfig: Ignore EF_LARCH_OBJABI_V1 in shared objects Content-Language: en-US To: Xi Ruoyao , Carlos O'Donell , libc-alpha@sourceware.org Cc: caiyinyu , Wang Xuerui References: <20230326111334.9920-1-xry111@xry111.site> <6f174ed1b3a54a83a8b0ff77fc0a50ceff2475a9.camel@xry111.site> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <6f174ed1b3a54a83a8b0ff77fc0a50ceff2475a9.camel@xry111.site> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,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 27/03/23 11:57, Xi Ruoyao wrote: > On Mon, 2023-03-27 at 09:44 -0400, Carlos O'Donell wrote: >> On 3/26/23 07:13, Xi Ruoyao via Libc-alpha wrote: >>> Binutils 2.40 sets EF_LARCH_OBJABI_V1 for shared objects: >>> >>>     $ ld --version | head -n1 >>>     GNU ld (GNU Binutils) 2.40 >>>     $ echo 'int dummy;' > dummy.c >>>     $ cc dummy.c -shared >>>     $ readelf -h a.out | grep Flags >>>     Flags:                             0x43, DOUBLE-FLOAT, OBJ-v1 >>> >>> We need to ignore it in ldconfig or ldconfig will consider all shared >>> objects linked by Binutils 2.40 "unsupported".  Maybe we should stop >>> setting EF_LARCH_OBJABI_V1 for shared objects, but Binutils 2.40 is >>> already released and we cannot change it. >>> --- >>>  sysdeps/unix/sysv/linux/loongarch/readelflib.c | 2 +- >>>  1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/sysdeps/unix/sysv/linux/loongarch/readelflib.c b/sysdeps/unix/sysv/linux/loongarch/readelflib.c >>> index bcaff86b36..ceba355959 100644 >>> --- a/sysdeps/unix/sysv/linux/loongarch/readelflib.c >>> +++ b/sysdeps/unix/sysv/linux/loongarch/readelflib.c >>> @@ -40,7 +40,7 @@ process_elf_file (const char *file_name, const char *lib, int *flag, >>>   >>>    ret = process_elf64_file (file_name, lib, flag, isa_level, soname, >>>                                 file_contents, file_length); >>> -  flags = elf64_header->e_flags; >>> +  flags = elf64_header->e_flags & ~EF_LARCH_OBJABI_V1; >> >> Are such objects ABI compatible? > > This flag was designed for indicating the relocation type usage in a .o > file: > > If EF_LARCH_OBJABI_V1 is set, it's allowed to use relocation types with > ID in [64, 100], but it's prohibited to use relocation types with ID in > [22, 46]. > > If EF_LARCH_OBJABI_V1 is not set, it's allowed to use relocation types > with ID in [22, 46], but it's prohibited to use relocation types with ID > in [64, 100]. > > A linker may only support the .o files with EF_LARCH_OBJABI_V1 unset > (for example, GNU ld 2.38), or only support the .o files with > EF_LARCH_OBJABI_V1 set (for example, LLD under review at > https://reviews.llvm.org/D138135), or support both (for example, GNU ld > 2.40). > > If a linker supports both, it's OK to link a EF_LARCH_OBJABI_V1 .o file > together with a non-EF_LARCH_OBJABI_V1 .o file into an executable or > shared object. > > But none of relocation type ID in [22, 46] or [64, 100] is runtime > relocation. I. e. those relocation types should not show up in a shared > object at all (if one shows up, the linker is buggy). So > EF_LARCH_OBJABI_V1 makes no difference for shared objects. Since the boat is already sailed with 2.40, I think the proposed patch is fine (it would be better if you indeed fix it on 2.41). I would just like to add a comment on why this is required: /* The EF_LARCH_OBJABI_V1 flag indicate which set of static relocations the object might use and it only considered during static linking, it does not reflect in runtime relocations. However some binutils version might set it on dynamic shared object, so clear it to avoid see the SO as unsupported. */ > >> Why isn't this handled below via SUPPORTED_ELF_FLAGS? > > If we add this into SUPPORTED_ELF_FLAGS, we'll need > > switch (flags & SUPPORTED_ELF_FLAGS) > { > case EF_LARCH_ABI_SOFT_FLOAT: > + case EF_LARCH_ABI_SOFT_FLOAT | EF_LARCH_OBJABI_V1: > *flag |= FLAG_LARCH_FLOAT_ABI_SOFT; > break; > case EF_LARCH_ABI_DOUBLE_FLOAT: > + case EF_LARCH_ABI_DOUBLE_FLOAT | EF_LARCH_OBJABI_V1: > *flag |= FLAG_LARCH_FLOAT_ABI_DOUBLE; > break; > default: > return 1; > } > > I don't think it's better... But if really you prefer this way I can > send a v2. >