For whatever reason LLVM does not allow LTO (Link Time Optimization) if
FTRACE_MCOUNT_USE_RECORDMCOUNT is enabled.
This allows disabling just this option instead of disabling all FTRACE
options.
Signed-off-by: Alexey Kardashevskiy <[email protected]>
---
Or disabling FTRACE is the right thing to do if HAS_LTO_CLANG=y?
Came from arch/Kconfig:
config HAS_LTO_CLANG
def_bool y
depends on CC_IS_CLANG && LD_IS_LLD && AS_IS_LLVM
depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
depends on ARCH_SUPPORTS_LTO_CLANG
depends on !FTRACE_MCOUNT_USE_RECORDMCOUNT <======
depends on !KASAN || KASAN_HW_TAGS
depends on !GCOV_KERNEL
---
kernel/trace/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index a5eb5e7fd624..87d82d2b0b0b 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -704,7 +704,8 @@ config FTRACE_MCOUNT_USE_OBJTOOL
depends on FTRACE_MCOUNT_RECORD
config FTRACE_MCOUNT_USE_RECORDMCOUNT
- def_bool y
+ bool "Enable FTRACE_MCOUNT_USE_RECORDMCOUNT"
+ default y
depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
depends on !FTRACE_MCOUNT_USE_CC
depends on !FTRACE_MCOUNT_USE_OBJTOOL
--
2.30.2
+ Sami, Kees
Do you guys remember why we don't support
FTRACE_MCOUNT_USE_RECORDMCOUNT with LTO?
https://patchwork.kernel.org/project/linux-kbuild/patch/[email protected]/?
On Thu, Feb 10, 2022 at 5:43 PM Alexey Kardashevskiy <[email protected]> wrote:
>
> For whatever reason LLVM does not allow LTO (Link Time Optimization) if
> FTRACE_MCOUNT_USE_RECORDMCOUNT is enabled.
>
> This allows disabling just this option instead of disabling all FTRACE
> options.
>
> Signed-off-by: Alexey Kardashevskiy <[email protected]>
> ---
>
> Or disabling FTRACE is the right thing to do if HAS_LTO_CLANG=y?
>
> Came from arch/Kconfig:
>
> config HAS_LTO_CLANG
> def_bool y
> depends on CC_IS_CLANG && LD_IS_LLD && AS_IS_LLVM
> depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
> depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
> depends on ARCH_SUPPORTS_LTO_CLANG
> depends on !FTRACE_MCOUNT_USE_RECORDMCOUNT <======
> depends on !KASAN || KASAN_HW_TAGS
> depends on !GCOV_KERNEL
>
>
> ---
> kernel/trace/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index a5eb5e7fd624..87d82d2b0b0b 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -704,7 +704,8 @@ config FTRACE_MCOUNT_USE_OBJTOOL
> depends on FTRACE_MCOUNT_RECORD
>
> config FTRACE_MCOUNT_USE_RECORDMCOUNT
> - def_bool y
> + bool "Enable FTRACE_MCOUNT_USE_RECORDMCOUNT"
> + default y
> depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
> depends on !FTRACE_MCOUNT_USE_CC
> depends on !FTRACE_MCOUNT_USE_OBJTOOL
> --
> 2.30.2
>
--
Thanks,
~Nick Desaulniers
On Fri, 11 Feb 2022 12:43:13 +1100
Alexey Kardashevskiy <[email protected]> wrote:
> For whatever reason LLVM does not allow LTO (Link Time Optimization) if
> FTRACE_MCOUNT_USE_RECORDMCOUNT is enabled.
>
> This allows disabling just this option instead of disabling all FTRACE
> options.
What FTRACE options are you talking about?
>
> Signed-off-by: Alexey Kardashevskiy <[email protected]>
> ---
>
> Or disabling FTRACE is the right thing to do if HAS_LTO_CLANG=y?
>
> Came from arch/Kconfig:
>
> config HAS_LTO_CLANG
> def_bool y
> depends on CC_IS_CLANG && LD_IS_LLD && AS_IS_LLVM
> depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
> depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
> depends on ARCH_SUPPORTS_LTO_CLANG
> depends on !FTRACE_MCOUNT_USE_RECORDMCOUNT <======
> depends on !KASAN || KASAN_HW_TAGS
> depends on !GCOV_KERNEL
>
>
> ---
> kernel/trace/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index a5eb5e7fd624..87d82d2b0b0b 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -704,7 +704,8 @@ config FTRACE_MCOUNT_USE_OBJTOOL
> depends on FTRACE_MCOUNT_RECORD
>
> config FTRACE_MCOUNT_USE_RECORDMCOUNT
> - def_bool y
> + bool "Enable FTRACE_MCOUNT_USE_RECORDMCOUNT"
> + default y
I don't think this does what you think it does.
This is not something that should be user selectable. What exactly are
you trying to accomplish here?
-- Steve
> depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
> depends on !FTRACE_MCOUNT_USE_CC
> depends on !FTRACE_MCOUNT_USE_OBJTOOL
On Fri, Feb 11, 2022 at 4:11 PM Nick Desaulniers
<[email protected]> wrote:
>
> + Sami, Kees
>
> Do you guys remember why we don't support
> FTRACE_MCOUNT_USE_RECORDMCOUNT with LTO?
It's because recordmcount cannot distinguish between calls and other
references to mcount/fentry, which is a problem with LTO where we have
to process the entire vmlinux.o and cannot ignore individual
translation units. Instead of resorting to workarounds, Peter was kind
enough to implement a smarter mcount pass in objtool, which we now use
on x86_64 with LTO.
Alexey, which architecture are you trying to fix here?
Sami
On Wed, 16 Feb 2022 12:19:14 +1100
Alexey Kardashevskiy <[email protected]> wrote:
> On 2/12/22 13:47, Steven Rostedt wrote:
> > On Fri, 11 Feb 2022 12:43:13 +1100
> > Alexey Kardashevskiy <[email protected]> wrote:
> >
> >> For whatever reason LLVM does not allow LTO (Link Time Optimization) if
> >> FTRACE_MCOUNT_USE_RECORDMCOUNT is enabled.
> >>
> >> This allows disabling just this option instead of disabling all FTRACE
> >> options.
> >
> > What FTRACE options are you talking about?
>
> LTO_CLANG_THIN => HAS_LTO_CLANG => !FTRACE_MCOUNT_USE_RECORDMCOUNT =>
>
> FTRACE [=y] && !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY [=n] &&
> !FTRACE_MCOUNT_USE_CC [=n] && !FTRACE_MCOUNT_USE_OBJTOOL [=n] &&
> FTRACE_MCOUNT_RECORD [=y]
So basically, turn off FUNCTION_TRACER and STACK_TRACER.
>
> A bunch.
>
>
> >
> >>
> >> Signed-off-by: Alexey Kardashevskiy <[email protected]>
> >> ---
> >>
> >> Or disabling FTRACE is the right thing to do if HAS_LTO_CLANG=y?
> >>
> >> Came from arch/Kconfig:
> >>
> >> config HAS_LTO_CLANG
> >> def_bool y
> >> depends on CC_IS_CLANG && LD_IS_LLD && AS_IS_LLVM
> >> depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
> >> depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
> >> depends on ARCH_SUPPORTS_LTO_CLANG
> >> depends on !FTRACE_MCOUNT_USE_RECORDMCOUNT <======
> >> depends on !KASAN || KASAN_HW_TAGS
> >> depends on !GCOV_KERNEL
> >>
> >>
> >> ---
> >> kernel/trace/Kconfig | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> >> index a5eb5e7fd624..87d82d2b0b0b 100644
> >> --- a/kernel/trace/Kconfig
> >> +++ b/kernel/trace/Kconfig
> >> @@ -704,7 +704,8 @@ config FTRACE_MCOUNT_USE_OBJTOOL
> >> depends on FTRACE_MCOUNT_RECORD
> >>
> >> config FTRACE_MCOUNT_USE_RECORDMCOUNT
> >> - def_bool y
> >> + bool "Enable FTRACE_MCOUNT_USE_RECORDMCOUNT"
> >> + default y
> >
> > I don't think this does what you think it does.
>
> Sounds like it.
>
> > This is not something that should be user selectable. What exactly are
> > you trying to accomplish here?
>
> I am trying to
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index b779603978e1..91c122224f83 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -153,6 +153,8 @@ config PPC
> select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
> select ARCH_WANT_LD_ORPHAN_WARN
> select ARCH_WEAK_RELEASE_ACQUIRE
> + select ARCH_SUPPORTS_LTO_CLANG if PPC64
> + select ARCH_SUPPORTS_LTO_CLANG_THIN if PPC64
>
>
> to get LTO working on powerpc64le with minimal change to
> ppc64le_defconfig which has all these FTRACE_xxx enabled.
Well, you can add a dependency against FUNCTION_TRACER. As that's what
turns on the RECORD_MCOUNT, as RECORD_MCOUNT is needed by it.
-- Steve
On 2/15/22 03:10, Sami Tolvanen wrote:
> On Fri, Feb 11, 2022 at 4:11 PM Nick Desaulniers
> <[email protected]> wrote:
>>
>> + Sami, Kees
>>
>> Do you guys remember why we don't support
>> FTRACE_MCOUNT_USE_RECORDMCOUNT with LTO?
>
> It's because recordmcount cannot distinguish between calls and other
> references to mcount/fentry, which is a problem with LTO where we have
> to process the entire vmlinux.o and cannot ignore individual
> translation units. Instead of resorting to workarounds, Peter was kind
> enough to implement a smarter mcount pass in objtool, which we now use
> on x86_64 with LTO.
So can x86_64 have both FTRACE_MCOUNT_USE_RECORDMCOUNT and LTO?
> Alexey, which architecture are you trying to fix here?
powerpc64le.
>
> Sami
On 2/12/22 13:47, Steven Rostedt wrote:
> On Fri, 11 Feb 2022 12:43:13 +1100
> Alexey Kardashevskiy <[email protected]> wrote:
>
>> For whatever reason LLVM does not allow LTO (Link Time Optimization) if
>> FTRACE_MCOUNT_USE_RECORDMCOUNT is enabled.
>>
>> This allows disabling just this option instead of disabling all FTRACE
>> options.
>
> What FTRACE options are you talking about?
LTO_CLANG_THIN => HAS_LTO_CLANG => !FTRACE_MCOUNT_USE_RECORDMCOUNT =>
FTRACE [=y] && !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY [=n] &&
!FTRACE_MCOUNT_USE_CC [=n] && !FTRACE_MCOUNT_USE_OBJTOOL [=n] &&
FTRACE_MCOUNT_RECORD [=y]
A bunch.
>
>>
>> Signed-off-by: Alexey Kardashevskiy <[email protected]>
>> ---
>>
>> Or disabling FTRACE is the right thing to do if HAS_LTO_CLANG=y?
>>
>> Came from arch/Kconfig:
>>
>> config HAS_LTO_CLANG
>> def_bool y
>> depends on CC_IS_CLANG && LD_IS_LLD && AS_IS_LLVM
>> depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
>> depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
>> depends on ARCH_SUPPORTS_LTO_CLANG
>> depends on !FTRACE_MCOUNT_USE_RECORDMCOUNT <======
>> depends on !KASAN || KASAN_HW_TAGS
>> depends on !GCOV_KERNEL
>>
>>
>> ---
>> kernel/trace/Kconfig | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
>> index a5eb5e7fd624..87d82d2b0b0b 100644
>> --- a/kernel/trace/Kconfig
>> +++ b/kernel/trace/Kconfig
>> @@ -704,7 +704,8 @@ config FTRACE_MCOUNT_USE_OBJTOOL
>> depends on FTRACE_MCOUNT_RECORD
>>
>> config FTRACE_MCOUNT_USE_RECORDMCOUNT
>> - def_bool y
>> + bool "Enable FTRACE_MCOUNT_USE_RECORDMCOUNT"
>> + default y
>
> I don't think this does what you think it does.
Sounds like it.
> This is not something that should be user selectable. What exactly are
> you trying to accomplish here?
I am trying to
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b779603978e1..91c122224f83 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -153,6 +153,8 @@ config PPC
select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WEAK_RELEASE_ACQUIRE
+ select ARCH_SUPPORTS_LTO_CLANG if PPC64
+ select ARCH_SUPPORTS_LTO_CLANG_THIN if PPC64
to get LTO working on powerpc64le with minimal change to
ppc64le_defconfig which has all these FTRACE_xxx enabled.
>
> -- Steve
>
>
>> depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
>> depends on !FTRACE_MCOUNT_USE_CC
>> depends on !FTRACE_MCOUNT_USE_OBJTOOL
>
Alexey Kardashevskiy wrote:
>
>
> On 2/15/22 03:10, Sami Tolvanen wrote:
>> On Fri, Feb 11, 2022 at 4:11 PM Nick Desaulniers
>> <[email protected]> wrote:
>>>
>>> + Sami, Kees
>>>
>>> Do you guys remember why we don't support
>>> FTRACE_MCOUNT_USE_RECORDMCOUNT with LTO?
>>
>> It's because recordmcount cannot distinguish between calls and other
>> references to mcount/fentry, which is a problem with LTO where we have
>> to process the entire vmlinux.o and cannot ignore individual
>> translation units. Instead of resorting to workarounds, Peter was kind
>> enough to implement a smarter mcount pass in objtool, which we now use
>> on x86_64 with LTO.
I had responded on a different thread about this:
http://lkml.kernel.org/r/[email protected]
We are working on enabling 'objtool check --mcount' on powerpc.
>
>
> So can x86_64 have both FTRACE_MCOUNT_USE_RECORDMCOUNT and LTO?
No. x86_64 now supports HAVE_OBJTOOL_MCOUNT, which enables
FTRACE_MCOUNT_USE_OBJTOOL. That allows LTO to be used.
- Naveen