From: Johannes Berg <johannes@sipsolutions.net>
To: Lambert <lambertdev@qq.com>, Peter Oberparleiter <oberpar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>, Jessica Yu <jeyu@kernel.org>,
linux-um@lists.infradead.org, "Lambert." <lambertdev@foxmail.com>
Subject: Re: [PATCH v2] init/gcov: allow CONFIG_CONSTRUCTORS on UML to fix module gcov
Date: Mon, 10 May 2021 13:37:53 +0200 [thread overview]
Message-ID: <2a46ca787df9a44c8b4fbc17ab6b69247ab38400.camel@sipsolutions.net> (raw)
In-Reply-To: <tencent_99073B61C8137C88B76C231139F94EFB3805@qq.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net>
To: Lambert <lambertdev@qq.com>, Peter Oberparleiter <oberpar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>, Jessica Yu <jeyu@kernel.org>,
linux-um@lists.infradead.org, "Lambert." <lambertdev@foxmail.com>
Subject: Re: [PATCH v2] init/gcov: allow CONFIG_CONSTRUCTORS on UML to fix module gcov
Date: Mon, 10 May 2021 13:37:53 +0200 [thread overview]
Message-ID: <2a46ca787df9a44c8b4fbc17ab6b69247ab38400.camel@sipsolutions.net> (raw)
In-Reply-To: <tencent_99073B61C8137C88B76C231139F94EFB3805@qq.com>
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
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2021-05-10 12:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-19 11:18 [PATCH] init/module: split CONFIG_CONSTRUCTORS to fix module gcov on UML Johannes Berg
2021-01-19 11:18 ` Johannes Berg
2021-01-20 16:07 ` Peter Oberparleiter
2021-01-20 16:07 ` Peter Oberparleiter
2021-01-20 16:09 ` Johannes Berg
2021-01-20 16:09 ` Johannes Berg
2021-01-20 16:20 ` Peter Oberparleiter
2021-01-20 16:20 ` Peter Oberparleiter
2021-01-20 16:20 ` [PATCH v2] init/gcov: allow CONFIG_CONSTRUCTORS on UML to fix module gcov Johannes Berg
2021-01-20 16:20 ` Johannes Berg
2021-01-20 17:04 ` Peter Oberparleiter
2021-01-20 17:04 ` Peter Oberparleiter
2021-01-20 17:38 ` Johannes Berg
2021-01-20 17:38 ` Johannes Berg
2021-05-08 13:50 ` Lambert
2021-05-10 11:37 ` Johannes Berg [this message]
2021-05-10 11:37 ` Johannes Berg
2021-05-10 13:31 ` lambertdev
2021-05-10 13:31 ` lambertdev
2021-05-14 13:55 ` Peter Oberparleiter
2021-05-14 13:55 ` Peter Oberparleiter
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=2a46ca787df9a44c8b4fbc17ab6b69247ab38400.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=jeyu@kernel.org \
--cc=lambertdev@foxmail.com \
--cc=lambertdev@qq.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=oberpar@linux.ibm.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.