LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Alan Kao <alankao@andestech.com>
Cc: Palmer Dabbelt <palmer@sifive.com>, Albert Ou <albert@sifive.com>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	Greentime Hu <greentime@andestech.com>,
	Zong Li <zong@andestech.com>
Subject: Re: [PATCH] riscv/ftrace: Fix the problem modules cannot find _mcount
Date: Tue, 8 May 2018 23:02:00 -0400	[thread overview]
Message-ID: <20180508230200.69fbf110@vmware.local.home> (raw)
In-Reply-To: <20180509023605.GB7303@andestech.com>

On Wed, 9 May 2018 10:36:05 +0800
Alan Kao <alankao@andestech.com> wrote:

> This EXPORT_SYMBOL and the _mcount body was inside a
> "#ifndef CONFIG_DYNAMIC_FTRACE" section, so if the config has dynamic ftrace
> disabled, _mcount is visible.
> 
> For the dynamic ftrace case, there is a code snippet in this file:
> 
> > ENTRY(ftrace_stub)
> > #ifdef CONFIG_DYNAMIC_FTRACE         
> >       .global _mcount
> >       .set    _mcount, ftrace_stub
> > #endif
> >        ret 
> > ENDPROC(ftrace_stub)  

I missed that, thanks.

> 
> Talking about some bigger issues here, there will be twofold.
> 
> 1. This patch lacks call-site collecting mechanism.
> 
> This feature requires a pattern check in recordmcount.pl.  With this,
> section __mcount_loc is properly constructed, and the call-sites will be
> registered during the loading stage.
> 
> However, the loading will then fail at the first try of make_nop, due to
> the instruction check.  This is thus the second issue.
> 
> 
> 2. The instruction check for kernel texts is not applicable to module texts.
> 
> The check expects a call instruction to _mcount, but here it is a call to
> the .plt section of the module.  After referencing the implementation of arm64,
> I think it would need much more work to have make_nop's and make_call's behavior
> right.

And powerpc64 I believe does something similar (which I think arm64
based it's work from).

> 
> 
> Quick summary: This patch ensures that a kernel build will not fail because of
> the _mcount-missing problem.  But ftrace cannot trace loading modules for now
> due to the stated reasons.

Probably why they had modules break to begin with ;-)

-- Steve

  reply	other threads:[~2018-05-09  3:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-08  3:21 Alan Kao
2018-05-08 13:11 ` Steven Rostedt
2018-05-09  2:36   ` Alan Kao
2018-05-09  3:02     ` Steven Rostedt [this message]
2018-06-04 20:30 ` Palmer Dabbelt
2018-06-04 20:30   ` [PATCH] riscv/ftrace: Export _mcount when FUNCTION_GRAPH_TRACER isn't set Palmer Dabbelt
2018-06-05  1:12     ` Alan Kao

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=20180508230200.69fbf110@vmware.local.home \
    --to=rostedt@goodmis.org \
    --cc=alankao@andestech.com \
    --cc=albert@sifive.com \
    --cc=greentime@andestech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mingo@redhat.com \
    --cc=palmer@sifive.com \
    --cc=zong@andestech.com \
    --subject='Re: [PATCH] riscv/ftrace: Fix the problem modules cannot find _mcount' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).