From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4654 invoked by alias); 22 Mar 2018 23:47:17 -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 4638 invoked by uid 89); 22 Mar 2018 23:47:16 -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=knew, powerpc64, elf64-ppc.c, UD:elf64-ppc.c X-HELO: mail-pf0-f175.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=bR8RuB9zK0xnWUYSgmm3uep2wc9jE3d7MyWFEH3H/mk=; b=XWBatjYUZwzOAlxSe7qaVgC6TaO8l4R6tqXE7VW7WXM0Ky1uWAkOl/EYYCt+jemYJU 8+bY6U6VRJqo1KxI0TPMluqwybgr/+398otuSjwEjbXXCmI50Ph4D/U9CzXu7UnD6bz2 s3sJ82FFy11T5jlBR7wSgm5Q/58+czO7AZ34N9L/XGm82MmMDXo9oy/PV0Au3OuxHdAH hEk4AT115r3XN6ZEsS9nHc4MaBbgcNxEHpHSaJ99Ikpb5CsozDz9QjIwOD636Sc7i81C xBlJmp5MhtWwa/O5+aombAMl+cf9s9s9IPimvfvdQYEFJ5mrVLUmaSq+gEkLsiKkuNbv d0dQ== X-Gm-Message-State: AElRT7HrUKbyojG8TdWPrKGvCMPkP8+2hteLK7V7J2ZD94SyH0ho9cSS 4TEmbT91QsnkwkzrnLMXdJE= X-Google-Smtp-Source: AG47ELuLA8PBtWY0MsJKo5Jd7Hr9S/Azp2trFVw9JM2JyJELJq2p7gAtyQ5tSaz//2ffYkTjJe/UOw== X-Received: by 10.99.138.202 with SMTP id y193mr19203345pgd.224.1521762433475; Thu, 22 Mar 2018 16:47:13 -0700 (PDT) Date: Thu, 22 Mar 2018 23:47:00 -0000 From: Alan Modra To: Zack Weinberg Cc: libc-alpha@sourceware.org Subject: Re: [RFC PATCH] Introduce pt-compat-stubs and use it to replace pt-vfork. (Architecture maintainer feedback wanted.) Message-ID: <20180322234708.GS3812@bubble.grove.modra.org> References: <20180321010551.9611-1-zackw@panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180321010551.9611-1-zackw@panix.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2018-03/txt/msg00530.txt.bz2 On Tue, Mar 20, 2018 at 09:05:51PM -0400, Zack Weinberg wrote: > I believe I have managed to > turn the trick for all currently-supported targets *except* powerpc64, > where I cannot find a way around a linker sanity check. The object > file contains > > 0000000000000000 <.__pstub_vfork>: > 0: 48 00 00 00 b 0 <.__pstub_vfork> > 0: R_PPC64_REL24 __libc_vfork > 4: 60 00 00 00 nop > > and the linker throws this error: > > nptl/libpthread_pic.a(pt-compat-stubs.os): In function `__pstub_vfork': > .../pt-compat-stubs.S:56:(.text+0x0): call to `__libc_vfork@@GLIBC_PRIVATE' > lacks nop, can't restore toc; recompile with -fPIC > > You can see that there *is* a nop after the call. Yes, the error message isn't the best in this case. At one stage GNU ld did allow code like you're writing. ie. a useless nop to be replaced with a toc restore insn that won't ever be executed. It was a way for an assembly programmer to say they knew what they were doing, please don't complain "can't restore toc". I took that feature out after getting reports of crashes due to bad toc pointer values.. > GNU ld lumps > several different circumstances into this error message, one of which > is just that R_PPC64_REL24 to a symbol outside the current module has > been applied to a plain branch (as opposed to branch-and-link) > instruction. *Normally* this would be unsafe, but in this specific > case, I believe it would work fine: __pstub_vfork is never called from > within libpthread, so __libc_vfork will ultimately return to a > TOC-restoration shim within __pstub_vfork's own caller. Yes, if you can guarantee no local calls to __pstub_vfork then the trick should work OK. > There's > some code in bfd/elf64-ppc.c that makes it sound like there might be a > way to bypass the sanity check, > > if (stub_entry->stub_type == ppc_stub_plt_call > && !htab->opd_abi > && htab->params->plt_localentry0 != 0 > && is_elfv2_localentry0 (&h->elf)) > { > /* The function doesn't use or change r2. */ > can_plt_call = TRUE; > } > > but I can't figure out how to make that condition be true. Any help > would be appreciated. No, that code won't apply. You'd need to link with --plt-localentry and __libc_vfork isn't localentry:0 anyway. 937: 00000000000e5f64 52 FUNC GLOBAL DEFAULT [: 8] 10 __libc_vfork@@GLIBC_PRIVATE Do you need lazy linking of the __libc_vfork PLT entry? If not, you could just implement the stub as an indirect call to __libc_vfork. For ELFv2, something like: .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 .data 1: .quad __libc_vfork 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 ld 11,0(11) ld 12,0(11) mtctr 12 ld 2,8(11) ld 11,16(11) bctr .size __pstub_vfork,.-0b .data 1: .quad __libc_vfork Note the addi and ld look like they ought to be combined into one insn, but we lack a REL16_LO_DS reloc to make that kosher. -- Alan Modra Australia Development Lab, IBM