[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a78d080c-1d32-c47c-b5b5-b5f809faacb5@suse.cz>
Date: Fri, 19 May 2017 11:17:24 +0200
From: Jiri Slaby <jslaby@...e.cz>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: mingo@...hat.com, tglx@...utronix.de, hpa@...or.com,
x86@...nel.org, linux-kernel@...r.kernel.org,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>, xen-devel@...ts.xenproject.org
Subject: Re: [PATCH v3 04/29] x86: assembly, use ENDPROC for functions
On 05/17/2017, 03:23 PM, Jiri Slaby wrote:
>> So the initial CFI state is different between the two types of
>> "functions". And there are a lot of other differences. C-type
>> functions have to follow frame pointer conventions, for example. So
>> your FUNC_START macro (and objtool) would have to somehow figure out a
>> way to make a distinction between the two. So it would probably work
>> out better if we kept the distinction between C-type functions and other
>> code.
>
> Ok, that makes a lot of sense.
A quick question:
Do you consider these to be C-type functions?
ENTRY(function_hook)
ret
END(function_hook)
or this?
ENTRY(native_load_gs_index)
pushfq
DISABLE_INTERRUPTS(CLBR_ANY & ~CLBR_RDI)
SWAPGS
movl %edi, %gs
SWAPGS
popfq
ret
END(native_load_gs_index)
Both are called from C, but they do not setup frame pointer etc.
thanks,
--
js
suse labs
Powered by blists - more mailing lists