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.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FSL_HELO_FAKE, 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 6F13D1F8C8 for ; Wed, 22 Sep 2021 19:45:16 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5B5AA385843E for ; Wed, 22 Sep 2021 19:45:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B5AA385843E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1632339915; bh=bjTQpqDmm1plFDX/4YwF20VWDMT7w/+GdG/x3CLs51A=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=yJPz4Vetv0z1EMDXKbpB7PcLsRxJ5yWeZsKPnRDdWW4N/Vq8W4INWYQdPIadnTvP9 s/w/QU0VzhhW8QLNxHRdelQzTiXeGMzKMkdIWPMMuJ2GRLHHevoUHRC77bD79K57pr Zj8T6dU97yvpG6PiIqF0fysGSt0AzXnNbdZDwZNc= Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id AAF343858D29 for ; Wed, 22 Sep 2021 19:44:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AAF343858D29 Received: by mail-pj1-x102f.google.com with SMTP id me5-20020a17090b17c500b0019af76b7bb4so5277217pjb.2 for ; Wed, 22 Sep 2021 12:44:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=bjTQpqDmm1plFDX/4YwF20VWDMT7w/+GdG/x3CLs51A=; b=k6805fFXgs5DMb54UA4SzMX2slztE4GhmojTPVL8HWIyUUZI3XcZjuDbdq1zVuUYcz DCgxl4e0w9HicFKBMiZ7iJyFV+cbWkQP86U2JG+9k33Frt+ZEXMmZr5gcyuYtgjri0ZH fGbA7ZmS4CzAYuexv5zXdfVfs5OjZ/ZdTOlJS5Z8YeBq17Cv5b/dYnCyxSKQjI8rdzEs T6cpnQoc0wL+i+DRlN4eVVwtmSF1WpRcidH40+EYj6HhwAKoySZR6ylDzRPEu4ql3kch SBqq5C3kA8rbmKDAQ3dcBFfcf8LX0KBnBEboJx62w0KzL/J7HbRc8Q+3NY87h8npaFKx bzPQ== X-Gm-Message-State: AOAM53171LKH6EoG0pXddBA3PmPxPohHoicCE1jwzWSlPMYqm12vnEgs RG3Iq00g+FeBwbJ3WWmEV+fGWw== X-Google-Smtp-Source: ABdhPJwvxHbrhWl/WyOcIajU14kKD2zCiJULuuCqQeKyO2t4jNHhvojkPJOu6sxG7pbA9NYJSx0O3A== X-Received: by 2002:a17:90a:5e03:: with SMTP id w3mr842512pjf.152.1632339894601; Wed, 22 Sep 2021 12:44:54 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:565:9e5f:566b:b3f3]) by smtp.gmail.com with ESMTPSA id w30sm6845927pjj.30.2021.09.22.12.44.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 12:44:54 -0700 (PDT) Date: Wed, 22 Sep 2021 12:44:50 -0700 To: Joseph Myers Subject: Re: PING^2: [PATCH] elf: Avoid nested functions in the loader (all ports) [BZ #27220] Message-ID: <20210922194450.mqwskdcrjyxfpd6f@google.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: Florian Weimer , Fangrui Song via Libc-alpha Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 2021-09-22, Joseph Myers wrote: >On Wed, 22 Sep 2021, Fāng-ruì Sòng via Libc-alpha wrote: > >> I went ahead and filed https://sourceware.org/bugzilla/show_bug.cgi?id=28376 >> "[meta] Build glibc with Clang" >> to collect miscellaneous small fixes. > >Note also that issues regarding use of glibc installed headers should >probably be handled separately (with a separate meta-bug to depend on >them; we already have a few such bugs open, e.g. 26287). The key >difference there is that installed headers should support a wide range of >compilers, including old versions. Whereas for issues building glibc, the >conclusion in some cases may well be that a change should be made to >Clang, and only new versions with that fix supported, rather than working >around a limitation in existing Clang versions. Sure! Changes need to be assessed where they belong to, Clang or glibc. 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=glibc.git;a=shortlog;h=refs/heads/google/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=ieeelongdouble (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 = __GI_memcpy"); * https://reviews.llvm.org/D88712 respect asm label for built-in functions 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.) 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. I hope glibc can be lenient in such a situation where Clang fixes may not be feasible. >> About the global variables (cur_*): they are in elf/dl-reloc.c >> >> - /* String table object symbols. */ >> - const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]); >> + cur_l = l; >> + cur_scope = scope; >> + cur_strtab = (const void *) D_PTR (cur_l, l_info[DT_STRTAB]); >> >> removing them requires more parameters to ELF_DYNAMIC_RELOCATE and >> RESOLVE_MAP. >> Is that the direction you are imagining? > >Yes. Explicit parameters (whether individual parameters or in a struct) >seems cleaner than using global state to pass parameters. Thanks for the confirmation. I will take a stab.