From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 1BBC33858C83 for ; Mon, 27 Mar 2023 14:58:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1BBC33858C83 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1679929078; bh=8buXyJS4LxXHDLZELWXuH0ybnUo5kp+fbPZjhxziECc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=F44Z6/1MTJX+RlV3dftBQyqGbD7oZTJ5uIPFQK9ah63ZgGCagRycGNlRR7IuKFjpY mlKwxcdu3SM2wKIvWFdnY9boNReHhEXnC6pWKB61hP0zZ2lQoM8/V34Whf1AevUbJ9 UA/e9wJNOSkihAgtOxnuNewn0FBb2zUr9Kw88pvg= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id E62C065C75; Mon, 27 Mar 2023 10:57:57 -0400 (EDT) Message-ID: <6f174ed1b3a54a83a8b0ff77fc0a50ceff2475a9.camel@xry111.site> Subject: Re: [PATCH] LoongArch: ldconfig: Ignore EF_LARCH_OBJABI_V1 in shared objects From: Xi Ruoyao To: Carlos O'Donell , libc-alpha@sourceware.org Cc: caiyinyu , Wang Xuerui , Adhemerval Zanella Netto Date: Mon, 27 Mar 2023 22:57:56 +0800 In-Reply-To: References: <20230326111334.9920-1-xry111@xry111.site> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.0 MIME-Version: 1.0 X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,LIKELY_SPAM_FROM,SPF_HELO_PASS,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 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: > >=20 > > =C2=A0=C2=A0=C2=A0 $ ld --version | head -n1 > > =C2=A0=C2=A0=C2=A0 GNU ld (GNU Binutils) 2.40 > > =C2=A0=C2=A0=C2=A0 $ echo 'int dummy;' > dummy.c > > =C2=A0=C2=A0=C2=A0 $ cc dummy.c -shared > > =C2=A0=C2=A0=C2=A0 $ readelf -h a.out | grep Flags > > =C2=A0=C2=A0=C2=A0 Flags:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x43, DOUBLE-FLOAT, OBJ-v1 > >=20 > > We need to ignore it in ldconfig or ldconfig will consider all shared > > objects linked by Binutils 2.40 "unsupported".=C2=A0 Maybe we should st= op > > setting EF_LARCH_OBJABI_V1 for shared objects, but Binutils 2.40 is > > already released and we cannot change it. > > --- > > =C2=A0sysdeps/unix/sysv/linux/loongarch/readelflib.c | 2 +- > > =C2=A01 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/sysdeps/unix/sysv/linux/loongarch/readelflib.c b/sysdeps/u= nix/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, > > =C2=A0 > > =C2=A0=C2=A0 ret =3D process_elf64_file (file_name, lib, flag, isa_leve= l, soname, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file_contents, file_length)= ; > > -=C2=A0 flags =3D elf64_header->e_flags; > > +=C2=A0 flags =3D elf64_header->e_flags & ~EF_LARCH_OBJABI_V1; >=20 > 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.=20 > 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 |=3D FLAG_LARCH_FLOAT_ABI_SOFT; break; case EF_LARCH_ABI_DOUBLE_FLOAT: + case EF_LARCH_ABI_DOUBLE_FLOAT | EF_LARCH_OBJABI_V1: *flag |=3D 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. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University