[llvmlinux] [arch/x86/kernel/head64.c] In function `early_make_pgtable': undefined reference to `mcount'
sedat.dilek at gmail.com
Mon Jul 15 09:25:33 UTC 2013
On Mon, Jul 15, 2013 at 9:54 AM, PaX Team <pageexec at gmail.com> wrote:
> On 13 Jul 2013 at 14:57, Sedat Dilek wrote:
>> >> # CONFIG_FTRACE is not set
>> [ CCing pageexec ]
> [btw, i've been subscribed since the beginning ;)]
>> Unfortunately, it is the opposite:
>> With CONFIG_FTRACE=n (disabled) I am able to build a kernel (with the
>> kernel-config I normally use for my Linux-next builds).
>> But disabling it means dispense with a lot of tracing-support, this is no good.
> i haven't tried building with any of the tracers in a long time but what
> i do know is that at runtime the kernel will fail because the stack walker
> code has various assumptions about the function call depth and will
> dereference bad memory when you enable this under clang (that's what the
> CALLER_ADDR* defines try to work around).
> another issue i remember is that clang applies the instrumentation needed
> by ftrace/etc in a different way, in particular functions get instrumented
> before inlining, so you'll get multiple calls to mcount from functions that
> contain inlined bodies and that's certainly not the behaviour the rest of
> the kernel infrastructure expects (i had a hackish workaround for this some
> years ago but i think it didn't get accepted).
> then there's the whole issue of clang/llvm not supporting the 'asm goto' gcc
> extension which is used for efficient instrumentation.
> all in all, forget instrumentation based tracing support for now, it will
> require quite some work.
Cool, that's really good explanations.
So, CONFIG_FTRACE should be disabled at all or is
(CONFIG_FUNCTION_TRACER=n plus CONFIG_DYNAMIC_FTRACE=n) sufficient.
The latter makes the "mcount" issue go away.
Speaking of the changes to x86-ftrace.h in 0033 (see ).
So, these workarounds can be dropped and CONFIG_FTRACE=n
(alternatively: CONFIG_FUNCTION_TRACER=n plus CONFIG_DYNAMIC_FTRACE=n)
from config_x86_64 in ?
And all this should be $somewhere documented.
I am willing to do that. In general there should be a file like
KNOWN-ISSUE or WORKAROUNDS in llvmlinux-topdir.
- Sedat -
More information about the LLVMLinux