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=-3.7 required=3.0 tests=AWL,BAYES_00,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 8D4E71F8C8 for ; Thu, 23 Sep 2021 22:01:20 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7D303385842D for ; Thu, 23 Sep 2021 22:01:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7D303385842D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1632434479; bh=pTqWf5XororQYBrMUoALs/vuYoNGakBKjbAfdg8YUbo=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=dXbcgl19Lmh+rut19HJNEci7vuILNFQnaezkovEIv5L2h+aNa6Skeslk5DmMci/8K 1SzHq+NWJEM77rOXYleIziI+M9cN76gOSaAKUM/USDcK9wHN9dhsyjYHKbuSbWrVck Tt/sopCAk4SyTe0LyrTjeY47JqdfJGFU00LxVMxY= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id CCCC43858D34 for ; Thu, 23 Sep 2021 22:00:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CCCC43858D34 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-455-kQlp27q8M7Wbqt7zV_oRVQ-1; Thu, 23 Sep 2021 18:00:56 -0400 X-MC-Unique: kQlp27q8M7Wbqt7zV_oRVQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4F4C7824FA7; Thu, 23 Sep 2021 22:00:55 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.176]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 90A786091B; Thu, 23 Sep 2021 22:00:51 +0000 (UTC) To: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Subject: Re: PING^2: [PATCH] elf: Avoid nested functions in the loader (all ports) [BZ #27220] 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> Date: Fri, 24 Sep 2021 00:00:49 +0200 In-Reply-To: <20210922194450.mqwskdcrjyxfpd6f@google.com> (=?utf-8?B?IkY=?= =?utf-8?B?xIFuZy1ydcOsIFPDsm5nIidz?= message of "Wed, 22 Sep 2021 12:44:50 -0700") Message-ID: <875yurlzou.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: Fangrui Song via Libc-alpha , Joseph Myers Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * 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/goo= gle/grte/v5-2.27/master > commits could be avoided by fixing Clang instead) > > * https://reviews.llvm.org/rGc841b9abf039ec0457752cd96f7e4716c1c7a323 "[M= C][ELF] Don't create relocations with section symbols for STB_LOCAL ifunc" > * https://reviews.llvm.org/D64283 PowerPC64 -mabi=3Dieeelongdouble (the h= eavy lift work is on IBM's side) > * https://reviews.llvm.org/rGf931290308abd0eebecae385cd32ca3a25ddd9be [Po= werPC] 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 function= s 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). > 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. Thanks, Florian