grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] arm: fix u-boot port syscall interface va_arg handling (was


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [PATCH] arm: fix u-boot port syscall interface va_arg handling (was Re: [PATCH] [ARM] Enable boot module for arm)
Date: Sat, 16 Nov 2013 14:17:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

On 16.11.2013 14:00, Leif Lindholm wrote:
> On Sat, Nov 16, 2013 at 01:49:51PM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> On 16.11.2013 13:39, Leif Lindholm wrote:
>>> -   str     r9, transition_space + 8
>> You need to save r9. Otherwise GRUB will crash if compiled with clang.
> 
> Hmm, but this is a bug in clang in that case.
> 
> From an ABI perspective, grub_uboot_syscall is a veneer:
> the only visible side effect it is permitted to have is to corrupt r12.
> 
According to wikipedia:
"Subroutines must preserve the contents of r4 to r11 and the stack pointer."
So changing r9 sounds to me like this is actually U-Boot bug and
preserving it sounds like right way to handle it.
What's the harm in preserving r9? Is it used for something in calling?
> We need to additionally switch r8 between grub and u-boot copy because
> u-boot uses it for its global data pointer, and lr because we need to
> corrupt it to make u-boot return to this veneer to switch the r8 back
> again.
> 
> This veneer should not touch anything else - so if we need to
> temporarily work around a toolchain ABI bug, can we do this via an
> ifdef and a config option?
> 
If the bug is on clang side (I doubt it right now), there is no way to
handle it without side effects and we can invent a test for it, we can
reject buggy compilers (clang is secondary compiler)
> /
>     Leif
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]