From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108009 invoked by alias); 23 Mar 2018 16:11:44 -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 107994 invoked by uid 89); 23 Mar 2018 16:11:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=sk:amodra, sk:amodra@, amodra@gmail.com, amodragmailcom X-HELO: mailbackend.panix.com X-Gm-Message-State: AElRT7G3sVpnWqpq0dmvIf8rbB3NGNt6VMO1gGKf5JZDQMDTlvlGD1Bc ygpxzCteIQaTcakdxiljhrE6YW2AG1qPFsLISzI= X-Google-Smtp-Source: AG47ELs92A3THl0/5XchjaNZEwRaJhXTfY8dlqLgsOIieayQ4uB6Ovs7GzmQQLTQqLs8lDMO2YIHkIhgY76IDlM7njc= X-Received: by 2002:a9d:a49:: with SMTP id 67-v6mr507547otg.374.1521821499795; Fri, 23 Mar 2018 09:11:39 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180322234708.GS3812@bubble.grove.modra.org> References: <20180321010551.9611-1-zackw@panix.com> <20180322234708.GS3812@bubble.grove.modra.org> From: Zack Weinberg Date: Fri, 23 Mar 2018 16:11:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] Introduce pt-compat-stubs and use it to replace pt-vfork. (Architecture maintainer feedback wanted.) To: Alan Modra Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-03/txt/msg00536.txt.bz2 On Thu, Mar 22, 2018 at 7:47 PM, Alan Modra wrote: > > 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.. Yeah, this is subtle enough that I think that was probably the right call... ... > 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. Lazy linking would be _better_, since these stubs exist only for compatibility with old executables and shouldn't get called very often, but I think we can live with eager linking. It's probably not a measurable difference in the time it takes to load libpthread.so anyway. > For ELFv2, something like: ... Thanks, I was trying to work these out myself (see the message I sent to binutils@) and got stuck because the ABI spec uses pseudo-relocation notation that the assembler doesn't actually accept. It was also not clear to me that ELFv2 scrapped function descriptors; you wouldn't happen to know where there's a list of *changes* from v1 to v2, would you? > .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) Is this third load (to r11) from the function descriptor required? That's the static chain slot, which C doesn't use, I thought... zw