All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: John Stultz <john.stultz@linaro.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
	Matthias Maennich <maennich@google.com>,
	Lucas De Marchi <lucas.de.marchi@gmail.com>,
	stable <stable@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] modpost: move the namespace field in Module.symvers last
Date: Wed, 1 Apr 2020 10:00:34 +0200	[thread overview]
Message-ID: <20200401080033.GA12505@linux-8ccs> (raw)
In-Reply-To: <CALAqxLWZ8aET=gHpYUi_v0ez-gDT5nPEnAEb+2uxebFU8D9RXg@mail.gmail.com>

+++ John Stultz [31/03/20 15:09 -0700]:
>On Tue, Mar 31, 2020 at 2:58 AM Jessica Yu <jeyu@kernel.org> wrote:
>> +++ John Stultz [30/03/20 23:25 -0700]:
>> >On Mon, Mar 30, 2020 at 10:49 PM John Stultz <john.stultz@linaro.org> 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.

No problem, thank for reporting back!

Jessica

      reply	other threads:[~2020-04-01  8:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 17:01 [PATCH v2] modpost: move the namespace field in Module.symvers last Jessica Yu
2020-03-12  7:17 ` Lucas De Marchi
2020-03-14  2:11 ` Masahiro Yamada
2020-03-17  0:24   ` Masahiro Yamada
2020-03-17 11:24   ` Jessica Yu
2020-03-31  5:49 ` John Stultz
2020-03-31  6:25   ` John Stultz
2020-03-31  9:58     ` Jessica Yu
2020-03-31 22:09       ` John Stultz
2020-04-01  8:00         ` Jessica Yu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200401080033.GA12505@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.de.marchi@gmail.com \
    --cc=maennich@google.com \
    --cc=stable@vger.kernel.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.