[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8191aa4a-3bd7-5de7-1ad2-73b851128ff3@linux.ibm.com>
Date: Wed, 20 Jan 2021 17:07:11 +0100
From: Peter Oberparleiter <oberpar@...ux.ibm.com>
To: Johannes Berg <johannes@...solutions.net>,
linux-um@...ts.infradead.org
Cc: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
Arnd Bergmann <arnd@...db.de>, Jessica Yu <jeyu@...nel.org>,
Johannes Berg <johannes.berg@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] init/module: split CONFIG_CONSTRUCTORS to fix module gcov
on UML
On 19.01.2021 12:18, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@...el.com>
>
> On ARCH=um, loading a module doesn't result in its constructors
> getting called, which breaks module gcov since the debugfs files
> are never registered. On the other hand, in-kernel constructors
> have already been called by the dynamic linker, so we can't call
> them again.
>
> Get out of this conundrum by splitting CONFIG_CONSTRUCTORS into
> CONFIG_CONSTRUCTORS_KERNEL and CONFIG_CONSTRUCTORS_MODULE, both
> of which are enabled by default if CONFIG_CONSTRUCTORS is turned
> on, but CONFIG_CONSTRUCTORS_KERNEL depends on !UML so that it's
> not used on ARCH=um.
>
> Also remove the "if !UML" from GCOV selecting CONSTRUCTORS now,
> since we really do want CONSTRUCTORS, just not kernel binary
> ones.
>
> Signed-off-by: Johannes Berg <johannes.berg@...el.com>
Do you expect other users for these new config symbols? If not it seems
to me that the goal of enabling module constructors for UML could also
be achieved without introducing new config symbols.
For example you could suppress calling any built-in kernel constructors
in case of UML by extending the ifdef in do_ctors() to depend on both
CONFIG_CONSTRUCTORS and !CONFIG_UML (maybe with an explanatory comment).
Of course you'd still need to remove the !UML dependency in
CONFIG_GCOV_KERNEL.
> ---
> Tested with a kernel configured with CONFIG_GCOV_KERNEL, without
> the patch nothing ever appears in /sys/kernel/debug/gcov/ (apart
> from the reset file), and with it we get the files and they work.
>
> I have no idea which tree this might go through, any suggestions?
So far Andrew Morton was kind enough to pick up gcov-kernel related
changes, so that route might be an option.
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
Powered by blists - more mailing lists