From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9381 invoked by alias); 23 Mar 2018 23:46:18 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 9366 invoked by uid 89); 23 Mar 2018 23:46:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:sk:x8-v6mr X-HELO: mail-pl0-f50.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+iJZuyots7id//BPUA/GD+bpm4J0keUf1TYbnzw5kTA=; b=gNP0WMtgpnlxTyMcFUU132oH3jPXf6VCVdu4mQf1HNxkjirN2WumNwPHMQqPpZ8IJQ USZpWEfz3HKl1WZCWei6x5UzEH86/Pexa4/wWieR8Knqf4qo3rmRm4jfG0T3N4YzSYo8 25Xl2seRG+dnqKx9zM2Vg3Xo7AUXAybRRImHyODXLfquisECCUWkrkIRn0Ti37eOS9Ig kjr1/0fp8f9Yc9YE5U/dB5iC90o7RHCb7cMZzp7vJSvyrhoR1tHBIczgpl7irbDQInkS H4opT+1xOQI6JnaONm3Q1AHfAz+EATuXBRr2BMxdDvI+9T3uidgWZCrth2JV6aVoUyEZ gIuA== X-Gm-Message-State: AElRT7ED+YAKYR5tfmNutqlFgnQD3pjChzZHrHvl+jZut4jfbGglbhHg jnOkEEmGZPvQPvxYotoY2zU= X-Google-Smtp-Source: AG47ELvxn0Qce+MbZEtaDpKz9X3pNmKkR9TALMKxTxRcpv5Q7zaJrZtltUxThGWHeDwLf20EzH+jOg== X-Received: by 2002:a17:902:9a48:: with SMTP id x8-v6mr18340915plv.135.1521848773662; Fri, 23 Mar 2018 16:46:13 -0700 (PDT) Date: Fri, 23 Mar 2018 23:46:00 -0000 From: Alan Modra To: Zack Weinberg Cc: GNU C Library Subject: Re: [RFC PATCH] Introduce pt-compat-stubs and use it to replace pt-vfork. (Architecture maintainer feedback wanted.) Message-ID: <20180323234608.GT3812@bubble.grove.modra.org> References: <20180321010551.9611-1-zackw@panix.com> <20180322234708.GS3812@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2018-03/txt/msg00540.txt.bz2 On Fri, Mar 23, 2018 at 03:32:09PM -0400, Zack Weinberg wrote: > On Thu, Mar 22, 2018 at 7:47 PM, Alan Modra wrote: > > ELFv1 code would look like: > > > > .section .opd,"aw",@progbits > > .global __pstub_vfork > > .type __pstub_vfork,@function > > __pstub_vfork: > > .quad 0f,.TOC.,0 > > > > .text > > 0: > > addis 11,2,1f-0b@ha > > addi 11,11,1f-0b@l > > Is this really correct? 1f-0b here is the offset from the beginning > of the function to the global it wants to reference in .data, but r2 > is the TOC pointer, not the beginning of the function. No, it's broken, sorry. Not enough editing when copying the ELFv2 code.. addis 11,2,1f@toc@ha addi 11,11,1f@toc@l ld 11,0(11) or better, since we do have the required relocs in this case addis 11,2,1f@toc@ha ld 11,1f@toc@l(11) Hmm, I also missed a ".p2align 3" when emitting the address to .data, and didn't write a proper OPD entry. :-( You could also put the function pointer in .toc which would be better for relro and huge ELFv1 shared libraries (not the case here but nicer example code for others to copy), or in .data.rel.ro. Revised ELFv1 code .section .opd,"aw",@progbits .global __pstub_vfork .type __pstub_vfork,@function __pstub_vfork: .quad 0f,.TOC.@tocbase,0 .text 0: addis 11,2,1f@toc@ha ld 11,1f@toc@l(11) ld 12,0(11) mtctr 12 ld 2,8(11) bctr .size __pstub_vfork,.-0b .section .toc,"aw",@progbits .p2align 3 1: .quad __libc_vfork ELFv2 code .text .global __pstub_vfork .type __pstub_vfork,@function __pstub_vfork: 0: addis 12,12,1f-0b@ha addi 12,12,1f-0b@l ld 12,0(12) mtctr 12 bctr .size __pstub_vfork,.-0b .section .data.rel.ro,"aw",@progbits .p2align 3 1: .quad __libc_vfork In reply to your other email, the third load is the static chain and can be omitted for C. I also happen to have been working on inline plt call support for powerpc ld, which will give you the ability to write stubs that support lazy linking. -- Alan Modra Australia Development Lab, IBM