Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Sep 2020 15:11:54 -0700
From: Sami Tolvanen <>
To: Kees Cook <>
Cc: Masahiro Yamada <>, Will Deacon <>, 
	Peter Zijlstra <>, Steven Rostedt <>, 
	Greg Kroah-Hartman <>, "Paul E. McKenney" <>, 
	Nick Desaulniers <>, 
	clang-built-linux <>, 
	Kernel Hardening <>, 
	linux-arch <>, 
	linux-arm-kernel <>, 
	linux-kbuild <>, LKML <>,, X86 ML <>
Subject: Re: [PATCH v2 08/28] x86, build: use objtool mcount

On Thu, Sep 3, 2020 at 2:58 PM Kees Cook <> wrote:
> On Thu, Sep 03, 2020 at 01:30:33PM -0700, Sami Tolvanen wrote:
> > Select HAVE_OBJTOOL_MCOUNT if STACK_VALIDATION is selected to use
> > objtool to generate __mcount_loc sections for dynamic ftrace with
> > Clang and gcc <5.
> >
> > Signed-off-by: Sami Tolvanen <>
> Am I right to understand that this fixes mcount for Clang generally
> (i.e. it's not _strictly_ related to LTO, though LTO depends on this
> change)?

No, this works fine with Clang when LTO is disabled, because
recordmcount ignores files named "ftrace.o". However, with LTO, we
process vmlinux.o instead, so we need a different method of ignoring
__fentry__ relocations that are not calls.

In v1, I used a function attribute to whitelist functions that refer
to __fentry__, but as Peter pointed out back then, objtool already
knows where the call sites are, so using it to generate __mcount_loc
is cleaner.

> And does this mean mcount was working for gcc < 5?

Yes. I should have been clearer in the commit message. The reason I
mentioned gcc <5 is that later gcc versions support -mrecord-mcount,
which means they don't need an external tool for generating
__mcount_loc anymore.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.