From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 9C02D1F8C8 for ; Thu, 23 Sep 2021 22:15:26 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C51EB3858C3B for ; Thu, 23 Sep 2021 22:15:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C51EB3858C3B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1632435325; bh=k8KP1HVggmk5bnu9fIqKVQS2bGQ1H9CZZyG7r9dA3R8=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=kSBcCgDLVyNhfC4IRL7UVXADbCYzVbXGsR0f25jRTRwrvz1yuEgTBtlwGdubXg+6B UoGWVEv+YPB7hQlU30Qgrtrxju+K4wk7v9T6Kp76YCIevAmroJMjFn/v8ecfw4UbFI 8Z3cs4MB3o9Ey24AfTQ56HTRh6TY141DtugNT0yM= Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by sourceware.org (Postfix) with ESMTPS id 21A2A3858D34 for ; Thu, 23 Sep 2021 22:15:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21A2A3858D34 Received: by mail-yb1-xb35.google.com with SMTP id j195so1532027ybj.8 for ; Thu, 23 Sep 2021 15:15:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=k8KP1HVggmk5bnu9fIqKVQS2bGQ1H9CZZyG7r9dA3R8=; b=zLR1+W+cwZPnVwaEijx5CgdFuhNryQGzVmTvQ3ER865zahHl1Lz7SXyVt/DjjUCFar tCxWLMbZ8LQodPz7hqYRzM+/ZWL0tgZYQZANk2v8Vhpx0iKTkr4W2zPKX63XpXVutK3D 9zSrO/rmrhARel591jfivu/UgDTYZKCEO2fE3HtVqT0e+Qr0sjhW34w2pX/p5SFmOGwm RGKL7wtX0SMD1Sna64TwWJ4hJev60VvdTdHieYX8YVwoXEV3/XWKhZqa2uf3WRXYunqf TqPDGPVq/AVtPPX5WN+wNkBuQDipyfmQaWcPh4EtptVKf/40yXp6ZvFyMDqk9XrpfmmO yqeA== X-Gm-Message-State: AOAM533sLnKx9odW3OWWf/iCmOd5Ho1KqUCYoYVUzuwpUIin/j/+83Rg YNQrTuSL33xA+HNgmm0kn6wqgK7jdiSd0R7XiSU7xg== X-Google-Smtp-Source: ABdhPJxyBAZ6AFRh2r0EEBHz1x7FNQnveV8vO+qvlo3j2wAewkPaFdZa2lY4X+RKpW6xFudpr+YzeECeoMj+uQec5YY= X-Received: by 2002:a25:ad45:: with SMTP id l5mr8816735ybe.228.1632435305475; Thu, 23 Sep 2021 15:15:05 -0700 (PDT) MIME-Version: 1.0 References: <20210823043648.2648608-1-maskray@google.com> <87tuj255se.fsf@oldenburg.str.redhat.com> <20210904035235.giercjqdwzjukxb5@google.com> <96f589db-295c-2a1d-600f-28f9fb4b0eee@redhat.com> <20210922184037.7anyorvbtnd5j2fm@google.com> <20210922194450.mqwskdcrjyxfpd6f@google.com> <875yurlzou.fsf@oldenburg.str.redhat.com> In-Reply-To: <875yurlzou.fsf@oldenburg.str.redhat.com> Date: Thu, 23 Sep 2021 15:14:53 -0700 Message-ID: Subject: Re: PING^2: [PATCH] elf: Avoid nested functions in the loader (all ports) [BZ #27220] To: Florian Weimer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: =?utf-8?q?F=C4=81ng-ru=C3=AC_S=C3=B2ng_via_Libc-alpha?= Reply-To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: Fangrui Song via Libc-alpha , Joseph Myers Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Thu, Sep 23, 2021 at 3:01 PM Florian Weimer wrote: > > * F=C4=81ng-ru=C3=AC S=C3=B2ng: > > > For folks who don't know me, I have pushed many Clang fixes to make > > glibc builds better, e.g. > > (Some were from my observation that some > > https://sourceware.org/git/?p=3Dglibc.git;a=3Dshortlog;h=3Drefs/heads/g= oogle/grte/v5-2.27/master > > commits could be avoided by fixing Clang instead) > > > > * https://reviews.llvm.org/rGc841b9abf039ec0457752cd96f7e4716c1c7a323 "= [MC][ELF] Don't create relocations with section symbols for STB_LOCAL ifunc= " > > * https://reviews.llvm.org/D64283 PowerPC64 -mabi=3Dieeelongdouble (the= heavy lift work is on IBM's side) > > * https://reviews.llvm.org/rGf931290308abd0eebecae385cd32ca3a25ddd9be [= PowerPC] Parse and ignore .machine > > * https://reviews.llvm.org/D88625 better support for asm("memcpy =3D __= GI_memcpy"); > > * https://reviews.llvm.org/D88712 respect asm label for built-in functi= ons > > I very much appreciate that you have fixed those minor Clang > incompatibility problems that have been in a WONTFIX state for so long > (especially the last change). Thanks > > However, for > > > > void bar(); > > void foo() { bar(); } > > void bar() asm("bar1"); > > > > GCC happily redirects the bar call to bar1. > > Clang rejects this x.c:5:6: error: cannot apply asm label to function > > after its first use > > void bar() asm("bar1"); > > ^ ~~~~~~ > > > > The issue is really to fix on Clang's side. > > (I spent many hours in a weekend for investigation and made the > > conclusion. Basically Clang does "parse decl A; codegen decl A; parse > > decl B; codegen decl B; ..." When it sees the asm label, it is too late > > to change the previous codegen.) > > I think GCC used to call this function-at-a-time mode. > > > This just needs some declaration reordering (the number of lines doesn'= t > > even need to increase) which is probably not a big burden on glibc's > > side. > > This is a bit unfortunate. I want to rework how we deal with hidden > prototypes (for PLT/relocation avoidance), so that what glibc does > becomes much more contributor-friendly. In part I want to to this to > offset some of the maintenance cost I added with the preprocessor goo > for the libpthread merge. What I want to do is to parse the installed > headers and automatically generate the aliases in a consistent fashion. > With GCC, I could add the aliases in a separate (wrapper) header. To > support Clang, it looks like I would have to rewrite the header instead > of merely parsing it, which hopefully won't be too bad. > > Does Clang support #pragma redefine_extname? And can that be applied > *before* the declaration? (We can't do that with __asm__ because we > don't know the appropriate prototype at this point.) If there's nothing > that speaks against using #pragma redefine_extname, it might provide a > way to avoid ordering issues. `#pragma redefine_extname` works. Internally Clang translates it into an asm label. I'll give annotated example below to demonstrate where an asm label can be placed. A function can be redeclared multiple times. The requirement is that an asm label is added before the first use. typedef unsigned long size_t; // #pragma redefine_extname memcpy __GI_memcpy // before the first use, wor= ks extern void *memcpy(void *, const void *, size_t); #pragma redefine_extname memcpy __GI_memcpy // before the first use, works void *test_memcpy(void *dst, const void *src, size_t n) { return memcpy(dst, src, n); } // #pragma redefine_extname memcpy __GI_memcpy // after the first use, does not work As https://reviews.llvm.org/D88712 mentions, the asm label does not apply to Clang generated memcpy calls. Certain optimization passes can synthesize built-in function calls. It's really difficult to fix, also related to the function-at-a-time mode. > Thanks, > Florian > --=20 =E5=AE=8B=E6=96=B9=E7=9D=BF