Skip to contentSkip to conversation

x86_64: undefined symbol 'mcount' in 3.7-rc1

DISCUSSION Arend van Spriel 2 participants 3 messages Oct 17, 2012 – Oct 31, 2012

lore
Share & tools
lore
#0 lore raw

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 <[email protected]>
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?

Gr. AvS

8,389 lines not shown · raw message

Part of this message is not shown here. View the raw message.

#1 lore raw
Quoted 23 lines · Arend van Spriel

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

Quoted 8 lines

commit d57c5d51a30152f3175d2344cb6395f08bf8ee0c

Author: Steven Rostedt <[email protected]>
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

#2 lore raw
Quoted 42 lines · Steven Rostedt
Quoted 23 lines · Arend van Spriel

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

Quoted 8 lines

commit d57c5d51a30152f3175d2344cb6395f08bf8ee0c

Author: Steven Rostedt <[email protected]>
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.

Quoted 8 lines

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