Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1188200

Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in aesni-intel_asm.S

Show all headers | View raw

On Mon, Jul 20, 2015 at 09:56:11AM +0200, Ingo Molnar wrote:
> > 
> > The reason I suggested to put FRAME in the macro name is to try to prevent it 
> > from being accidentally used for leaf functions, where it isn't needed.
> 
> Well, we could use LEAF_FUNCTION to mark that fact.
> 
> Wether a function written in assembly is a leaf function or not is a higher level 
> (and thus more valuable) piece of information whether we generate frame pointer 
> debuginfo or not.
> 
> > Also the naming of FUNCTION_ENTRY and FUNCTION_RETURN doesn't do anything to 
> > distinguish them from the already ubiquitous ENTRY and ENDPROC.  So as a kernel 
> > developer it seems confusing to me, e.g. how do I remember when to use 
> > FUNCTION_ENTRY vs ENTRY?
> 
> 'ENDPROC' is really leftover from older debuginfo cruft, it's not a valuable 
> construct IMHO, even if it's (sadly) ubiquitious.
> 
> We want to create new, clean, as minimal as possible and as clearly named as 
> possible debuginfo constructs from first principles.

Ok. So if I understand right, the proposal is:

Replace *all* x86 usage of ENTRY/ENDPROC with either:

FUNCTION_ENTRY(func)
FUNCTION_RETURN(func)

or

LEAF_FUNCTION_ENTRY(func)
LEAF_FUNCTION_RETURN(func)

Those sound fine to me.


I should point out that there are still a few cases where the more
granular FRAME/ENDFRAME and ENTRY/ENDPROC macros would still be needed.

For example, if the function ends with a jump instead of a ret.  If the
jump is a sibling call, the code would look like:

FUNCTION_ENTRY(func)
	...
	ENDFRAME
	jmp another_func
ENDPROC(func)


Or if it's a jump within the function to an internal ret:

FUNCTION_ENTRY(func)
	...
1:	...
	ENDFRAME
	ret
2:	...
	jmp 1b
ENDPROC(func)


Or if it jumps to some shared code before returning:

FUNCTION_ENTRY(func_1)
	...
	jmp common_return
ENDPROC(func_1)

FUNCTION_ENTRY(func_2)
	...
	jmp common_return
ENDPROC(func_2)

common_return:
	...
	ENDFRAME
	ret


So in some cases we'd still need the more granular macros, unless we
decided to make special macros for these cases as well.

-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in  aesni-intel_asm.S Josh Poimboeuf <jpoimboe@redhat.com> - 2015-07-20 16:00 +0200
  Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in  aesni-intel_asm.S Ingo Molnar <mingo@kernel.org> - 2015-07-20 19:30 +0200
    Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in  aesni-intel_asm.S Josh Poimboeuf <jpoimboe@redhat.com> - 2015-07-20 20:10 +0200
      Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in  aesni-intel_asm.S Josh Poimboeuf <jpoimboe@redhat.com> - 2015-07-22 14:00 +0200

csiph-web