From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80C32C2D0E5 for ; Fri, 27 Mar 2020 15:26:46 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2A46F20748 for ; Fri, 27 Mar 2020 15:26:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A46F20748 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 48pm0z5pwczDrFm for ; Sat, 28 Mar 2020 02:26:43 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=permerror (SPF Permanent Error: Unknown mechanism found: ip:192.40.192.88/32) smtp.mailfrom=kernel.crashing.org (client-ip=63.228.1.57; helo=gate.crashing.org; envelope-from=segher@kernel.crashing.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lists.ozlabs.org (Postfix) with ESMTP id 48plyg3ZBxzDrB5 for ; Sat, 28 Mar 2020 02:24:43 +1100 (AEDT) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 02RFOTOH014259; Fri, 27 Mar 2020 10:24:29 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 02RFOSQa014258; Fri, 27 Mar 2020 10:24:28 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 27 Mar 2020 10:24:28 -0500 From: Segher Boessenkool To: Fangrui Song Subject: Re: [PATCH v2] powerpc/boot: Delete unneeded .globl _zimage_start Message-ID: <20200327152428.GF22482@gate.crashing.org> References: <20200325164257.170229-1-maskray@google.com> <20200326221625.GA22482@gate.crashing.org> <20200326222612.zbbiyi75emq6npzn@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200326222612.zbbiyi75emq6npzn@google.com> User-Agent: Mutt/1.4.2.3i X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alan Modra , Nick Desaulniers , clang-built-linux@googlegroups.com, Joel Stanley , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Mar 26, 2020 at 03:26:12PM -0700, Fangrui Song wrote: > On 2020-03-26, Segher Boessenkool wrote: > >On Wed, Mar 25, 2020 at 09:42:57AM -0700, Fangrui Song wrote: > >>.globl sets the symbol binding to STB_GLOBAL while .weak sets the > >>binding to STB_WEAK. GNU as let .weak override .globl since binutils-gdb > >>5ca547dc2399a0a5d9f20626d4bf5547c3ccfddd (1996). Clang integrated > >>assembler let the last win but it may error in the future. > > > >GNU AS works for more than just ELF. The way the assembler language > >is defined, it is not .weak overriding .globl -- instead, .weak sets a > >symbol attribute. On an existing symbol (but it creates on if there is > >none yet). > > > >Clang is buggy if it does not allow valid (and perfectly normal) > >assembler code like this. > > https://sourceware.org/pipermail/binutils/2020-March/110399.html > > Alan: "I think it is completely fine for you to make the llvm assembler > error on inconsistent binding, or the last directive win. Either of > those behaviours is logical and good, but you quite possibly will run > into a need to fix more user assembly. This would be fine and consistent behaviour, of course. But it is not appropriate if you want to pretend to be compatible to GNU toolchains. Which is exactly why you want this kernel patch at all. And the kernel can (in this case) accommodate your buggy assembler, sure, but are you going to "fix" all other programs with this "problem" as well? Segher