From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1]) by sourceware.org (Postfix) with ESMTPS id 7F9C33856944 for ; Tue, 8 Aug 2023 14:55:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7F9C33856944 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=1691506535; bh=vxo3EskEE6vfR0ufyY3e1tE+5CKYWW8JC3DZ8gvyx4o=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=jS4XDfk/4zN8OSnL7DFQwA9uZMQSCSNMx13Gb34jNUIovfpHZvXzbit8tBs03uIQs L/3dxHa3fsYFePVzAnzQl84eRulupuuGYbNIhtgJ5sC64isHIe8OLm9P/FXEacEoxF M2z0OU+Wl0VMv3d8lJZkhuWlXBHGxmfa1kFkOw5Y= 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 183B8659CA; Tue, 8 Aug 2023 10:55:33 -0400 (EDT) Message-ID: <4386e09a0e2f6aced1b1774a8d36796f98772913.camel@xry111.site> Subject: Re: Problems with relocations for a custom ISA From: Xi Ruoyao To: MegaIng , Michael Matz Cc: binutils@sourceware.org Date: Tue, 08 Aug 2023 22:55:30 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 MIME-Version: 1.0 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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, 2023-08-08 at 16:35 +0200, MegaIng via Binutils wrote: > Our idea was that the user can use a simple pseudo instruction to=20 > represent the > entire process of loading a symbol (or any immediate for that matter). > Maybe this is a misguided idea? I'd say it's a bad idea. A stack-based pseudo instruction reloc approach had been used for LoongArch. But the "pseudo instruction" has never been implemented completely (doing so is just impossible unless you rewrite the entire libbfd) so actually we could only handle some special cases, and this approach caused much more trouble than the benefit. Now we've made these nasty things deprecated and we will remove the support of them in a future Binutils release. See https://github.com/loongson/LoongArch-Documentation/issues/9 for the "much more trouble". > It would have to be 3-4 RELOC_BITS_0_4, RELOC_BITS_5_9=20 > RELOC_BITS_10_15 or something like that Yes, now we use some traditional reloc types for LoongArch like them.=20 And this approach works much better than the previous stack-based one.=20 We now really wish we'd never tried the stack-based approach at all. ELF allows 2^31-1 reloc types, so a larger reloc type set is not an issue. > but what about situations where nothing about the range of the value > is known You need to design some code models (sets of assumptions for the ranges), like other BFD ports do. If you really need the marginal performance gain by exploiting the range limitations, you can also implement linker relaxation. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University