libffi & powerpc
Hi there,
I'm running an embedded platform based on a powerpc 405EP CPU and a
gcc 4.1.0 cross-toolchain. My initial problem was that gcj compiled
binaries crash at runtime when interpreting java bytecode ("Illegal
instruction" message).
After many investigations, it looks like the problem comes from the
libffi library : I've run the libffi testsuite on my embedded paltform
and many of the tests show the same "Illegal instruction" message. For
instance, the "cls_uint" test crashes at the following line (from the
cls_uint.c file) :
res = (*((cls_ret_uint)pcl))(2147483647);
My knowledge about the powerpc architectures is very limited, but I've
seen mailing lists threads talking about "EABI" that I don't quite
understand but my intuition is that it could be related. For instance,
could it be that my cross toolchain is not compiled with the right
EABI (does this question make sense??) ?
Any ideas or thoughts about this problem ?
Thanks in advance for your replies.
Regards,
Patrick Olinet
Re: libffi & powerpc
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
stfd %f1, 48(%r1)
I don't understand anything to powerpc assembly, but after a google
search, "stfd" means "store floating-point double". But the PPC405
doesn't have any FPU, so I guess that's why it throws an "illegal
instruction".
I've compiled again my cross toolchain with the "--with-float=soft"
option, hoping that it would emulate FPU instruction, but this
unfortunately doesn't help... I'm nevertheless not sure that this
option is the right one...
Any thoughts ? Is there a bug in libffi in that it doesn't support
powerpc CPU without FPU ?
Regards,
Patrick
On 5/8/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
Patrick Olinet writes:
> Hi there,
>
> I'm running an embedded platform based on a powerpc 405EP CPU and a
> gcc 4.1.0 cross-toolchain. My initial problem was that gcj compiled
> binaries crash at runtime when interpreting java bytecode ("Illegal
> instruction" message).
>
> After many investigations, it looks like the problem comes from the
> libffi library : I've run the libffi testsuite on my embedded paltform
> and many of the tests show the same "Illegal instruction" message. For
> instance, the "cls_uint" test crashes at the following line (from the
> cls_uint.c file) :
>
> res = (*((cls_ret_uint)pcl))(2147483647);
>
> My knowledge about the powerpc architectures is very limited, but I've
> seen mailing lists threads talking about "EABI" that I don't quite
> understand but my intuition is that it could be related. For instance,
> could it be that my cross toolchain is not compiled with the right
> EABI (does this question make sense??) ?
>
> Any ideas or thoughts about this problem ?
Run it in gdb. When gdb stops with SIGILL, do
x/i $pc
Andrew.
Re: libffi & powerpc
> I've compiled again my cross toolchain with the "--with-float=soft" > option, hoping that it would emulate FPU instruction, but this > unfortunately doesn't help... I'm nevertheless not sure that this > option is the right one... If your entire toolchain is compiled with --with-float=soft, then you should use the same options when compiling your code. > I thought that fpu emulation worked by trapping cpu exceptions when a fpu instruction is being executed and then emulating this instruction on software level. Isn't the mechanism implemented by the "--with-float=soft" option ? Patrick
Re: libffi & powerpc
> I thought that fpu emulation worked by trapping cpu exceptions when a > fpu instruction is being executed and then emulating this instruction > on software level. Yes. > Isn't the mechanism implemented by the "--with-float=soft" option ? No. FPU emulation requires no special compile-time options. The whole idea is that it runs the same code as native FP. In contrast, soft-float generates inline subroutine calls for all floating-point operations. ok, I get it. So, is there a way to add fpu emulation emulation to my platform without having to change anything to my native binary code ? Patrick
Re: libffi & powerpc
Finally, I've tried it the dirty way, ie by commenting out all the
"stfd" instructions at the beginning of the ppc_closure.S file and
things seem to work !!!
"stfd" are used to save fpu registers and were always executed, even
if no float/double arguments were involved in the call and if no fpu
is present.
Of course, I'm still unable to use float/double with the libffi but I
don't need it so I don't think I'm going to dig into this. As far as I
understand, calls to the soft float ABI would be required to fix this.
What worries me a bit is that "stfd" instructions are used to save fpu
registers states before the call (it's my guess) and I would expect
them to be restored afterwards, probably with "lfd" assembly
instructions (that I would need to comment out as well). But I can't
see such instructions...
Any thoughts about that ?
And should I report a new bug for this libffi/powerpc problem ?
And thanks again to all of you for your help.
Patrick
On 5/14/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 14, 2007, at 8:46 AM, Patrick Olinet wrote:
> Running with gdb, it looks like the problem comes from the
> ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
Maybe something like:
#ifndef _SOFT_FLOAT
> stfd %f1, 48(%r1)
#endif
but then, you might have to have something like:
#define CPP_SPEC \
"%{msoft-float: -D_SOFT_FLOAT} \
(picked at random from lynx.h) in the .h file for your port.
:-) But I'm sure there would be more work to do.
Re: libffi & powerpc
ok, I've created PR31937 related to the libffi bug and I've also submitted a quick patch to the gcc-patches mailing list Patrick On 5/16/07, Mike Stump <[EMAIL PROTECTED]> wrote: On May 15, 2007, at 2:20 AM, Patrick Olinet wrote: > Finally, I've tried it the dirty way, ie by commenting out all the > "stfd" instructions at the beginning of the ppc_closure.S file and > things seem to work !!! Wonderful. If you could, would you submit the patch to gcc- patches... I suspect it is better than nothing, and it might be trivial enough to go in without paperwork. Additionally, it might provide a basis for another contributor to build upon, as they then only have to do half the work. Thanks. > What worries me a bit is that "stfd" instructions are used to save > fpu registers states before the call (it's my guess) and I would > expect them to be restored afterwards, probably with "lfd" assembly > instructions (that I would need to comment out as well). But I > can't see such instructions... > Any thoughts about that ? Sure, don't worry about it, there is no matching instruction. You just can't do functions that return float/double/long double from my quick reading. > And should I report a new bug for this libffi/powerpc problem ? We prefer to have a bug report for each bug... :-)
