Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3932405ybb; Tue, 31 Mar 2020 15:11:07 -0700 (PDT) X-Google-Smtp-Source: APiQypLo1ntGoymg99aEwxlN4+7fGzu0j4he+Six/r8Erlr+IlVvbLb6+bFvW7aiiVGeNC0hmqFk X-Received: by 2002:aca:d705:: with SMTP id o5mr812905oig.67.1585692667468; Tue, 31 Mar 2020 15:11:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585692667; cv=none; d=google.com; s=arc-20160816; b=dayR+/OH1FKqlS1TU/dPXzL4iNNnScFSoNH0HvfEol/Cw6oOEbabAS5x0R6Rlp2FaL DCYggv6WkGqegKpGvN7uslWp77OuBt8W2kPfpV0rxzLDZv9aylfXJpZuRrwDcuFm7pwX lbLGXWcxvG/jwevsk3uw29SzVVUkwy5OOtGD0hUt39kUW/xMmojWao2H77xnmfYFSOqF chyytzps5SC1iSl+Jx8rZOzl7v9MfTmyfPjRZrzqlXutJy69yS4JDqAoW0NtJsAYIK+G ZGy5UckSz4MogLbrVWIkw9N41EqEBCK/w2uUj2rZHXD0wIPiuRfj8tgeQyXPo5UQJaA1 NsQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ifrIprtCmZCzS2rJSxbv6FFXsExlpwqRTV97NQIJ9rs=; b=RhscKCB9egGGyZbh7jWhw+UToKABA3nmNT+bjCmuDfoXD5iwDsKKkAGC7LLtaMKqBA zMfuPA5q/FIjbk8eUggvYEkxrYTItZmyHxxHgz+hGnPE8Y2lnQ6VI8bmx4Zcdb54tEXx LkE6WXTjQQRPR8nRU4L0bR6iKyktH6gSjxRagsQ/Smy/2zOpZIGEryOR1FhUInJuMo/j pN57fzG8bNZn5Rof+uAJqjA52EidhkCHrvrFB46/+a3BmljYN84vlxPyvTFFIvOxKo0J oJ5nCRuAA0USsAwo78skb23yGuEgmsboDcdkSK7CXEa29uuSX9B7Fh8hNS9oslJ6ZaZT dKSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=IgFFgsAW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 70si8408271otv.273.2020.03.31.15.10.55; Tue, 31 Mar 2020 15:11:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=IgFFgsAW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731364AbgCaWJl (ORCPT + 99 others); Tue, 31 Mar 2020 18:09:41 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:38332 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728428AbgCaWJl (ORCPT ); Tue, 31 Mar 2020 18:09:41 -0400 Received: by mail-ot1-f66.google.com with SMTP id t28so23826047ott.5 for ; Tue, 31 Mar 2020 15:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ifrIprtCmZCzS2rJSxbv6FFXsExlpwqRTV97NQIJ9rs=; b=IgFFgsAWYaFEytOk8+1XW190BObyf7+0lOQae8kvvO91eG2YNPGCGIYDcNIgf8OD5c bbzyop+Ku5KhHsy0IwV12gH+siQ4xtMhSnbz01VygvXCE/pZwMLp1dv8yTX3DpoRRrbj aq+PShu3V8Rf1ggxGBtgAgMCIC40cy4erilzdOe7u4t2pmkxnzt53kuE9t9Ookgayq6u zZflX3MboDDfQAo1FermwmveXvPRUp8rm1jAhl1zctqw6fw0Z+5+hYRcTlsJX39MZpBt iGZUuWVvdQrz6g3XworAKW8B9XJQaUMb7R9l9cd35cM/w/g0U4TWdzrFyrqGixkH1McU PSLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ifrIprtCmZCzS2rJSxbv6FFXsExlpwqRTV97NQIJ9rs=; b=n+Tw/LO11sAZhc46D1J7rdX9pS/gZg056EkD16XMpS/4G1uDlNF3lqAVZxgiZK8xwF xTqEVC3kwWFFIiNYxX7ZGT8i86Ijoe65r4oT4ufOZO2379e5pO8/Y0XAKRfO8VDyVuS2 +LHgVe0+GwvQsEBfdsZVNz8foWLMJ6Cprzx6HBFRC1Lh3PYOIrFYNFLOD7O59nXpAgYs oltL2Xq23Y+wMiQq+sUEDy0KNJoUIXIy0yUapuutapI+Cp+Pp4k4sitZ5InRng6xcVGw SZzr+OEd16Z13FT6/zp0xGnE+xQ1BBGI5KtpeDPAmQrTbqnof2+z3jMLag2haH9HB/ET SyyQ== X-Gm-Message-State: ANhLgQ1oouavrGc6DOMZJyO8nh3u1N2jsxPKnigp/Q0ww4wHdPm22uFL YRClLhusk80EoqEWgVlnlL/f4p/93x82NVWQnQaX4Q== X-Received: by 2002:a9d:1920:: with SMTP id j32mr13961381ota.221.1585692580240; Tue, 31 Mar 2020 15:09:40 -0700 (PDT) MIME-Version: 1.0 References: <20200311170120.12641-1-jeyu@kernel.org> <20200331095802.GA3026@linux-8ccs> In-Reply-To: <20200331095802.GA3026@linux-8ccs> From: John Stultz Date: Tue, 31 Mar 2020 15:09:27 -0700 Message-ID: Subject: Re: [PATCH v2] modpost: move the namespace field in Module.symvers last To: Jessica Yu Cc: Masahiro Yamada , Matthias Maennich , Lucas De Marchi , stable , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 31, 2020 at 2:58 AM Jessica Yu wrote: > +++ John Stultz [30/03/20 23:25 -0700]: > >On Mon, Mar 30, 2020 at 10:49 PM John Stultz wrote: > >> The only difference I can find is that the Module.symvers in the > >> external module project doesn't seem to have a tab at the end of each > >> line (where as Module.symvers for the kernel - which doesn't seem to > >> have any namespace names - does). > >> > >> Is there something I need to tweak on the external Kbuild to get > >> Module.symvers to be generated properly (with the empty tab at the > >> end) for this new change? > >> Or does the parser need to be a bit more flexible? > >> > > > >One extra clue on this: I noticed the external module Makefile had > >KBUILD_EXTRA_SYMBOLS="$(EXTRA_SYMBOLS)" in the $(MAKE) string, where > >EXTRA_SYMBOLS pointed to some files that no longer exist. I removed > >the KBUILD_EXTRA_SYMBOLS= argument, and magically, the generated > >Module.symvers now had tabs at the end of each line. > > > >I wonder if there some path in the KBUILD_EXTRA_SYMBOLS= handling that > >isn't generating the output in the same way? > > I'm afraid we're going to need some specifics on reproducing this > issue. Could you provide a reproducer or steps on how to reproduce? I > have not been able to trigger this problem even with > KBUILD_EXTRA_SYMBOLS pointing to an invalid path (I also tested with > valid paths). > > I tested with a skeleton external module that exports two functions, > one with a namespace and one without. I built this module against the > latest v5.6 kernel. The generated Module.symvers was correct - the > namespaced function had the namespace at the end and the other > function without a namespace had a tab at the end. > > I also tested with two external modules, one with a symbol dependency > on the other, so KBUILD_EXTRA_SYMBOLS usage is required here. The > generated Module.symvers was also correct here. > > The only advice I can offer at this time is that all external modules > must be built against the new kernel to generate a correctly formated > Module.symvers file. If you have any KBUILD_EXTRA_SYMBOLS pointing to > an outdated Module.symvers file for example, you will see the "FATAL: > parse error in symbol dump file" error. Well, my apologies. :( In the light of day, this isn't reproducing anymore. I'm a bit at a loss as to why I was tripping over it so regularly before, but I suspect something in the build is leaving a stale Modules.symvers around from before this patch landed. Terribly sorry for the noise. thanks -john