Floating point exception ( SIGFPE ) on 'int main(){ return(0); }' Floating point exception ( SIGFPE ) on 'int main(){ return(0); }' c c

Floating point exception ( SIGFPE ) on 'int main(){ return(0); }'


This is going to sound like a really long shot...but can you try the following?

$ readelf -a fail

and look for a GNU_HASH dynamic tag? My guess is that the binary uses GNU_HASH, and your ld.so is too old to understand it. Support for the GNU hash section was added to glibc around 2006, and mainline distros began to be GNU-hash-only around 2007 or 2008. Your Centrino's glibc is from 2003, which predates GNU hashing.

If the ld.so doesn't understand GNU hash, it will try to use the old ELF hash section instead, which is empty. In particular, I suspect your crash is occurring at this line in elf/do-lookup.h:

for (symidx = map->l_buckets[hash % map->l_nbuckets];

Since the linker presumably doesn't understand GNU hashes, l_nbuckets would be 0, resulting in the crash. Note that map is a large structure with around 100 structure elements, and l_nbuckets is around the 90th member of the structure in newer ld.so (0x164 = 4*89, so in older ld.so it is probably precisely this member).

To see if this is conclusively the problem, build with -Wl,--hash-style=sysv or -Wl,--hash-style=both and see if the crash goes away.


Since it works on the ATOM but not on the older Celeron, I would think the problem could be with a compiler optimization generating code that the Celeron cannot execute. Try compiling with the flag -O0. Additionally, I would suggest adding -march=i686 to explicitly state the architecture. Also, to help isolate the problem I'd also suggest disabling linking to the C++ runtime and JAVA.

Did you build this test program once and run it on each device, or did you build a different executable for each device? If you are building one executable you may have differing versions of libc, libstdc++ on the two devices or on the devices vs your build machine.