[SLOF] [PATCH] slof: Change call_c() function to a proper assembler function

Segher Boessenkool segher at kernel.crashing.org
Wed Sep 16 00:15:01 AEST 2015

On Tue, Sep 15, 2015 at 10:36:21AM +0200, Thomas Huth wrote:
> Using inline assembly for the call_c() function does not work
> properly: Recent versions of the GCC compiler save some registers
> to negative offsets on the stack before executing the inline
> assembler code (to the so-called "red zone",

Not just recent versions; this happened ten years ago as well.
It was harmless when calling just RTAS (or other things with known
behaviour on entry), but now CALL-C is used for more generic things.

> which is OK according
> to the ABI), since the compiler does not know that this assembler
> code jumps to another function. However that other function might
> also put some values on the stack, which can destroy the saved
> values, causing weird effects or crashes.
> To be on the save side, move the jump code to a proper assembler
> file instead, so we do not have to make any bogus assumptions
> for the inline assembly anymore.
> This fixes the issue with "Cannot open file : fbuffer.fs" etc.
> messages that occured with GCC versions >= 4.9
> Signed-off-by: Thomas Huth <thuth at redhat.com>

Acked-by: Segher Boessenkool <segher at kernel.crashing.org>
(if you take those tags?)

> +	# Call another function via pointer in r6
> +	# (arguments can be provided in r3 to r5)
> +	# Destination function should jump back to lr
> +C_ENTRY(call_c)
> +	mtctr	r6
> +	bctr

Much prettier :-)


More information about the SLOF mailing list