svn commit: r234014 - head/lib/libc/arm/gen

Juli Mallett jmallett at FreeBSD.org
Mon Apr 9 08:03:56 UTC 2012


On Sun, Apr 8, 2012 at 21:14, Andrew Turner <andrew at fubar.geek.nz> wrote:
> We can implement it as a naked function but we will need to store all
> registers other than r0 and pc which seems a waste.
>
> The problem implementing it in an assembly file is we are unable to use
> ARM_TP_ADDRESS is defined as:
> #define ARM_TP_ADDRESS (ARM_VECTORS_HIGH + 0x1000)
>
> Where ARM_VECTORS_HIGH is defined as:
> #define ARM_VECTORS_HIGH 0xffff0000U
>
> I could remove the U from ARM_VECTORS_HIGH however I'm not sure on the
> implications of that change.

Oh, is that all?  :)  It's easy to have an ifdef that adds the u
suffix in C and not in assembly.  That's perfectly appropriate in this
case.  If you want to be fancy you can use a macro which adds the U to
the constant in C and not in assembly, and use it in other places, but
that's usually unnecessary.  In the kernel we sometimes use assym to
get around this sort of thing, but that's fully unnecessary.

Look at powerpc/include/vmparam.h for an example of a header where we
do this currently (VM_MAXUSER_ADDRESS specifically.)  This is the
right thing to do by far over using C as a wrapper for assembly in
this way.

>> How do you know GCC won't allocate r2 to be used as a temporary in
>> between the assembly and the return?
>
> The compiler is free to use r2 with the current code. I have attached a
> patch that fools the compiler into thinking we are using r1-r3 by
> placing them in the clobber list.

If this file is ever compiled with the correct ABI, then, it will do
excessive saves and restores of r1-r3, I think.


More information about the svn-src-head mailing list