On Wed, 9 May 2018 10:36:05 +0800 Alan Kao <alan...@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
