[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a46ca787df9a44c8b4fbc17ab6b69247ab38400.camel@sipsolutions.net>
Date: Mon, 10 May 2021 13:37:53 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Lambert <lambertdev@...com>,
Peter Oberparleiter <oberpar@...ux.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
Arnd Bergmann <arnd@...db.de>, Jessica Yu <jeyu@...nel.org>,
linux-um@...ts.infradead.org, "Lambert." <lambertdev@...mail.com>
Subject: Re: [PATCH v2] init/gcov: allow CONFIG_CONSTRUCTORS on UML to fix
module gcov
Hi,
> Hi Johannes and Peter, sorry to bother but I have one question
> on this change. The do_ctors() won’t be executed for UML
> because *the constructors have already been called for ELF*.
>
> *__ctors_start* and *__ctors_end* symbols. See link:
> https://elixir.bootlin.com/linux/v5.12.2/source/include/asm-generic/vmlinux.lds.h#L676
>
> In my environment, UML+GCC 10, I can't find __gcov_init executed
> before kernel starts. So I did some trace and found glibc
> __libc_csu_init
> will only execute constructors between *__init_array_start*and
> *__init_array_end*.
> Which means if do_ctors() is not executed for UML, no elsewhere will
> the constructors be executed.
>
> Shall we remove the *!defined(CONFIG_UML)* for GCC, or I just missed
> some steps to make the GCOV work for UML?
No, that doesn't seem like the right solution.
Perhaps then with that toolchain (or configuration thereof) we need to
provide __init_array_start/end labels?
Or ... maybe that actually just needs to be removed, so that the
toolchain gets to choose?
Hmm. Pretty sure it worked for me, I think also with gcc 10, but not
sure exactly where I tested.
johannes
Powered by blists - more mailing lists