[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170322072916.GB13904@gmail.com>
Date: Wed, 22 Mar 2017 08:29:16 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Jiri Slaby <jslaby@...e.cz>, mingo@...hat.com, tglx@...utronix.de,
hpa@...or.com, x86@...nel.org, linux-kernel@...r.kernel.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Pavel Machek <pavel@....cz>, linux-pm@...r.kernel.org,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>, xen-devel@...ts.xenproject.org
Subject: Re: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions
* Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
> > ENTRY(ftrace_caller)
> > /* save_mcount_regs fills in first two parameters */
> > @@ -184,11 +184,12 @@ GLOBAL(ftrace_epilogue)
> > GLOBAL(ftrace_graph_call)
> > jmp ftrace_stub
> > #endif
> > +SYM_FUNC_END(ftrace_caller)
> >
> > /* This is weak to keep gas from relaxing the jumps */
> > WEAK(ftrace_stub)
> > retq
> > -END(ftrace_caller)
> > +SYM_FUNC_END(ftrace_caller)
>
> This gives ftrace_caller() two ends.
Such errors too could be detected automatically via objtool or some other symbol
debug mechanism.
The reason it might be a good fit for objtool is to make the checking optional (no
need to burden a regular build with it), plus objtool already looks at the .o from
first principles - a symbol checking sub-functionality could analyze the symbol
names in the same pass.
If we want to complicate things with CFI then we absolutely should increase the
quality of our symbol names space.
Thanks,
Ingo
Powered by blists - more mailing lists