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=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE 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 A45AA2429A for ; Sun, 21 Jan 2024 23:28:31 +0100 (CET) Received: (qmail 11605 invoked by uid 550); 21 Jan 2024 22:26:27 -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 11567 invoked from network); 21 Jan 2024 22:26:27 -0000 Date: Sun, 21 Jan 2024 17:28:32 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20240121222831.GC4163@brightrain.aerifal.cx> References: <20230822173821.GW4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230822173821.GW4163@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Draft riscv64 TLSDESC implementation On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote: > The psABI work is not finalized, but based on the current status of > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think > the attached is a valid (but untested) implementation of TLSDESC for > riscv64. Actually activating it requires also adding the relocation > type macro to riscv64/reloc.h. > > If any rv folks could look it over and make sure I haven't made any > stupid asm errors or missed any obvious optimizations, that would help > to quickly get this merged when the psABI is finalized. > > Rich > .text > .global __tlsdesc_static > .hidden __tlsdesc_static > .type __tlsdesc_static,%function > __tlsdesc_static: > ld a0,8(a0) > jr t0 > > .global __tlsdesc_dynamic > .hidden __tlsdesc_dynamic > .type __tlsdesc_dynamic,%function > __tlsdesc_dynamic: > add sp,sp,-8 > sd t1,(sp) > sd t2,8(sp) > > ld t2,-8(tp) # t2=dtv > > ld a0,8(a0) # a0=&{modidx,off} > ld t1,8(a0) # t1=off > ld a0,(a0) # a0=modidx > sll a0,a0,3 # a0=8*modidx > > add a0,a0,t2 # a0=dtv+8*modidx > ld a0,(a0) # a0=dtv[modidx] > add a0,a0,t1 # a0=dtv[modidx]+off > sub a0,a0,tp # a0=dtv[modidx]+off-tp > > ld t1,(sp) > ld t2,8(sp) > add sp,sp,8 > jr t0 Any feedback on this? Offhand, it looks like adjusting sp by 8 is wrong and that should be 16. Anything else? Does anyone have recent enough tooling to test this?