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

Thomas Huth thuth at redhat.com
Wed Sep 16 01:12:52 AEST 2015

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>



More information about the SLOF mailing list