All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Arend van Spriel" <arend@broadcom.com>
To: "Steven Rostedt" <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: x86_64: undefined symbol 'mcount' in 3.7-rc1
Date: Wed, 31 Oct 2012 22:56:24 +0100	[thread overview]
Message-ID: <50919E88.8060900@broadcom.com> (raw)
In-Reply-To: <1351709060.4004.91.camel@gandalf.local.home>

On 10/31/2012 07:44 PM, Steven Rostedt wrote:
> On Wed, 2012-10-17 at 22:23 +0200, Arend van Spriel wrote:
>> Hi Steven,
>>
>> I have nightly test machines upgraded to 3.7-rc1 and on the 64-bit
>> platform I get MODPOST warning on 'mcount'.
>>
>> It is conditionally exported in x8664_ksyms_64.c:
>> #ifdef CONFIG_FUNCTION_TRACER
>> /* mcount is defined in assembly */
>> EXPORT_SYMBOL(mcount);
>> #endif
>>
>> #ifdef CONFIG_FUNCTION_TRACER
>> #ifdef CC_USING_FENTRY
>> # define MCOUNT_ADDR           ((long)(__fentry__))
>> #else
>> # define MCOUNT_ADDR           ((long)(mcount))
>> #endif
>> #define MCOUNT_INSN_SIZE       5 /* sizeof mcount call */
>>
>> I have built the kernel on x86 machine with gcc 4.6.3 and the modules
>> are built during the test execution on test machine which has gcc 4.4.5.
>> Reading commit below
>>
>> commit d57c5d51a30152f3175d2344cb6395f08bf8ee0c
>> Author: Steven Rostedt <srostedt@redhat.com>
>> Date:   Wed Feb 9 13:32:18 2011 -0500
>>
>>       ftrace/x86: Add support for -mfentry to x86_64
>>
>> I suppose the gcc version mismatch is causing my problem. Is that a
>> correct assumption?
>
> Yes.
>
> gcc 4.6.0 added a new option to gcc called '-mfentry'. The kernel build
> checks to see if this option is supported and if so it will use it. What
> this option does (when added to -pg), will not do the mcount calling but
> instead call fentry. The two have different semantics and are not
> compatible. When you built your kernel, the build process detected that
> -mfentry is supported and used that.
>
> Now when you built your modules with gcc 4.4.5, -mfentry was not
> supported and it used the mcount feature instead. In general, it's not a
> good idea to use two different gcc's to build the kernel and modules.
>
> But if you really need to, then you should disable function tracing of
> your modules, where the -pg and -mfentry wont be used.
>
> -- Steve

Thanks Steve(n)

I just upgraded the test machine to have the same gcc as the machine 
building the kernels.

Gr. AvS


      reply	other threads:[~2012-10-31 21:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-17 20:23 x86_64: undefined symbol 'mcount' in 3.7-rc1 Arend van Spriel
2012-10-31 18:44 ` Steven Rostedt
2012-10-31 21:56   ` Arend van Spriel [this message]

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=50919E88.8060900@broadcom.com \
    --to=arend@broadcom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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.