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

Alexey Kardashevskiy aik at ozlabs.ru
Thu Sep 17 11:46:47 AEST 2015


On 09/16/2015 01:12 AM, Thomas Huth wrote:
> On 15/09/15 16:15, Segher Boessenkool wrote:
>> 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.
>
> That call to the romfs_lookup function is also there since ages ...
> so it's maybe rather that newer GCCs are now using the register which is
> clobbered - while older GCC versions did not touch it.
>
>>> 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>
>
> Thanks!

Thanks, applied.

Segher, and yes, we do take these tags :)


-- 
Alexey


More information about the SLOF mailing list