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,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 B173D2170A for ; Thu, 29 Feb 2024 16:35:28 +0100 (CET) Received: (qmail 3229 invoked by uid 550); 29 Feb 2024 15:31:45 -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 3188 invoked from network); 29 Feb 2024 15:31:44 -0000 Date: Thu, 29 Feb 2024 10:35:31 -0500 From: Rich Felker To: Max Filippov Cc: musl@lists.openwall.com Message-ID: <20240229153531.GT4163@brightrain.aerifal.cx> References: <20240227232430.GM4163@brightrain.aerifal.cx> <20240228001303.GN4163@brightrain.aerifal.cx> <20240228183032.GO4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Initial xtensa/fdpic port review On Thu, Feb 29, 2024 at 04:03:02AM -0800, Max Filippov wrote: > On Wed, Feb 28, 2024 at 1:28 PM Max Filippov wrote: > > On Wed, Feb 28, 2024 at 10:30 AM Rich Felker wrote: > > > Is there a reason local, relative jumps/calls can't be done by > > > computing the address of a nearby label and using the offset relative > > > to that? That's how they (at least some types; I forget the details) > > > work on sh/fdpic. > > > > IIUC that would require the actual PC knowledge and there's no direct > > access to the PC on xtensa. > > I thought about it for a bit and although the current PC can easily > be fetched I don't see how it can work for multiple text segments > without a GOT entry. OTOH a link-time conversion of a call without > GOT to a call with GOT in case the target and the call site are in > the different text segments seems feasible. With multiple text segments, a cross-segment call cannot be relative to begin with. Because fdpic lets them float independently, it would have to go thru the GOT. Rather than having the linker convert calls *to* using GOT, I think the safe way to do things would be to have the compiler emit calls thru the GOT but linker relax them to avoid the GOT when they're in the same segment. But there's no reason this has to be done initially. I'm just thinking in terms of making sure the design doesn't preclude or make it difficult to do multiple segments in the future if desired. Rich