Skip to main content

cvm receives signal 4

13 replies [Last post]
hallenberg
Offline
Joined: 2007-01-05
Points: 0

Hi,

I'm currently trying to compile CDC foundation profile b27 for ARM 926 (OMAP 5912 based custom board). But when I run cvm it receives signal 4 (Illegal instruction):

# bin/cvm
Process #957 received signal 4, suspending
[3] + Stopped (signal) bin/cvm
#

If I compile with CVM_DEBUG = true it "works", the call to cvm looks good but it's not able to open any file provided in the classpath. Any ideas on what I might be missing? Maybe my toolchain is old? I'm using arm-linux-gcc 3.4.2, but it has worked just fine for everything else (kernel/PhoneME feature/you name it).

/ Tomas

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cjplummer
Offline
Joined: 2006-10-16
Points: 0

You probably are compiling with -mhard-float (which may be you compiler's default), and I don't believe the OMAP 5912 supports this. You an confirm this by using gdb to find out what the offending instruction is. Where did you get your toolchain from? What compiler options are you passing?

Chris

hallenberg
Offline
Joined: 2007-01-05
Points: 0

Yes, I am using -mhard-float. Cvm doesn't compile at all using -msoft-float (the linker can't link to libc since libc is compiled using hard-floats). I don't have gdb at the moment for the ARM platform, but I suppose I'll need it sometime in the future anyhow...

I don't know exactly where the tool-chain is from, since I didn't install it. I do know that compiling a simple testprogram that does floating point calculations works just fine. I'm not passing any special compiler options at all, I'm building directly from the linux-arm-generic path. The only thing I modified in GNUmakefile was the path to arm-linux-gcc and I also added CVM_JAVA_TOOLS_PREFIX.

hallenberg
Offline
Joined: 2007-01-05
Points: 0

I added CVM_FORCE_HARD_FLOAT = true and now it works. If I get performance problems I guess I'll look into switching to soft floats. IIRC the linux kernel is doing the floating point emulation now, with traps and whatnot.

cjplummer
Offline
Joined: 2006-10-16
Points: 0

> I added CVM_FORCE_HARD_FLOAT = true and now it works.
> If I get performance problems I guess I'll look into
> switching to soft floats. IIRC the linux kernel is
> doing the floating point emulation now, with traps
> and whatnot.

Hmm. I don't see how this would solve a signal 4. If you are using the linux-arm-generic/GNUmakefile, it looks like the only thing CVM_FORCE_HARD_FLOAT=true does is add the following:

CVM_DEFINE += -DCVM_FORCE_HARD_FLOAT

Although I don't see how this could fix a signal 4. Can you try adding the above to your GNUmakefile and removing CVM_FORCE_HARD_FLOAT=true just to verify this is what helped.

thanks,

Chris

hallenberg
Offline
Joined: 2007-01-05
Points: 0

Nopes. That's not it.

It works with CVM_FORCE_HARD_FLOAT = true, but if I change that to CVM_DEFINE += -DCVM_FORCE_HARD_FLOAT the signal 4 problems reappear.

The only rows added/changed in GNUmakefile:
CVM_JAVA_TOOLS_PREFIX = /opt/j2sdk1.4.2_13/bin/
CVM_FORCE_HARD_FLOAT = true
CVM_TARGET_TOOLS_PREFIX = arm-linux-

I tried adding J2ME_CLASSLIB = foundation as well, and it doesn't (and shouldn't?) affect the signal 4 behaviour.

cjplummer
Offline
Joined: 2006-10-16
Points: 0

> Nopes. That's not it.
>
> It works with CVM_FORCE_HARD_FLOAT = true, but if I
> change that to CVM_DEFINE += -DCVM_FORCE_HARD_FLOAT
> the signal 4 problems reappear.
>

Sorry, I had a typo (copy-n-paste from xemacs was't working for me). It should be CVM_DEFINES.

Chris

hallenberg
Offline
Joined: 2007-01-05
Points: 0

Confirmed. Using CVM_DEFINES += -DCVM_FORCE_HARD_FLOAT works as well.

cjplummer
Offline
Joined: 2006-10-16
Points: 0

> Confirmed. Using CVM_DEFINES +=
> -DCVM_FORCE_HARD_FLOAT works as well.

Hmm. I can understand why it may crash (SIGSEGV) or give incorrect float results without this, but I don't see how it would cause a SIGILL. Have you tried debugging it to see which instruction is producing the SIGILL.

Also, can you send me the output of the following? I think I can make it so you don't need to set -DCVM_FORCE_HARD_FLOAT. We should be able to detect gcc predefined macros and do the right thing automatically.

gcc -dM -E test.c

test.c:
float foo(float f1, float f2)
{
return f1+f2;
}

Use your cross gcc. For pass in any flags you normally pass when compiling CVM. This would include things like -march, -mcpu, and -mhard-float if you are setting them.

Also, can you try one other experiment? In cdc/src/arm/javavm/include/jit/ccm_cpu.h, change the "#ifdef CVM_FORCE_HARD_FLOAT" to "#if 1" and no longer pass in -DCVM_FORCE_HARD_FLOAT and see if that works.

thanks,

Chris

hallenberg
Offline
Joined: 2007-01-05
Points: 0

The output of the first one is included below. As for the second question I'll have to get back to that when I have time to recompile cvm.

arm-linux-gcc -dM -E test.c
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __FLT_EVAL_METHOD__ 0
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __ARMEL__ 1
#define __GNUC_PATCHLEVEL__ 2
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.7976931348623157e+308L
#define __linux 1
#define __CHAR_UNSIGNED__ 1
#define __LDBL_MAX_EXP__ 1024
#define __linux__ 1
#define __SCHAR_MAX__ 127
#define __USER_LABEL_PREFIX__
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __DBL_DIG__ 15
#define __FLT_EPSILON__ 1.19209290e-7F
#define __APCS_32__ 1
#define __LDBL_MIN__ 2.2250738585072014e-308L
#define __unix__ 1
#define __DECIMAL_DIG__ 17
#define __gnu_linux__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __GNUC__ 3
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_HAS_INFINITY__ 1
#define __USING_SJLJ_EXCEPTIONS__ 1
#define __DBL_MAX_EXP__ 1024
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __GXX_ABI_VERSION 1002
#define __FLT_MIN_EXP__ (-125)
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DBL_HAS_QUIET_NAN__ 1
#define __REGISTER_PREFIX__
#define __NO_INLINE__ 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "3.4.2"
#define unix 1
#define __SIZE_TYPE__ unsigned int
#define __ELF__ 1
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 2.2204460492503131e-16L
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 2147483647L
#define __FLT_HAS_INFINITY__ 1
#define __unix 1
#define linux 1
#define __LDBL_MANT_DIG__ 53
#define __WCHAR_TYPE__ long int
#define __FLT_DIG__ 6
#define __INT_MAX__ 2147483647
#define __FLT_MAX_EXP__ 128
#define __DBL_MANT_DIG__ 53
#define __WINT_TYPE__ unsigned int
#define __LDBL_MIN_EXP__ (-1021)
#define __arm__ 1
#define __LDBL_MAX_10_EXP__ 308
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __ARM_ARCH_3__ 1
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MIN_10_EXP__ (-37)
#define __GNUC_MINOR__ 4
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 4.9406564584124654e-324L
#define __PTRDIFF_TYPE__ int
#define __LDBL_MIN_10_EXP__ (-307)
#define __LDBL_DIG__ 15

cjplummer
Offline
Joined: 2006-10-16
Points: 0

Ok, I see that VFP is not defined. I think the fix is to have the source auto-detect when hard-float is used, and it is not VFP. I'm working on a fix now, but I'll probably need you to verify it eventually.

Also, I noticed the following in you output:

#define __ARM_ARCH_3__ 1

You may want to try a -march or -mcpu setting to get __ARM_ARCH_5TE, which is what your processor is. You can try either of the following:

-march=arm5te
-mcpu=arm926

Chris

hallenberg
Offline
Joined: 2007-01-05
Points: 0

I tried replacing the #ifdef in the mentioned header file, but the signal 4 problem remained.

Using -march=armv5te seems like a good idea though, thanks.

cjplummer
Offline
Joined: 2006-10-16
Points: 0

> I tried replacing the #ifdef in the mentioned header
> file, but the signal 4 problem remained.
>
> Using -march=armv5te seems like a good idea though,
> thanks.

Yes, and I finally figured out why it gives a SIGILL. I've made changes that make it so you will no longer need to specify CVM_FORCE_HARD_FLOAT=true. I'll commit them once I get a code review done.

Chris

cjplummer
Offline
Joined: 2006-10-16
Points: 0

I just commited the fix for this in revision 6474. You should no longer need to to specify CVM_FORCE_HARD_FLOAT=true.

Chris