0

I have an ELF that was compiled on a armv7a Cortex-A9 CPU. It runs fine there with no problems, but when it's moved onto an armv7a Cortex-A8 CPU the file silently exits as follows:

casey@arm:~/Unreal/System$ ./UCCLinux.bin.orig casey@arm:~/Unreal/System$

I built my own UCCLinux.bin that uses the shared objects that are unchanged from the Cortex A9 CPU, and execution works fine. This leads me to believe that there's nothing wrong with the shared objects, but something with the ELF itself. However, diffing ld --verbose/readelf shows only one small difference. On the version I built, it needs a different dependency. ld-linux-armhf.so.3, where as it's not present and replaced with libm.so.6; which I have.

There is also this search path on the working system that confuses me: SEARCH_DIR("/usr/armv7hl-suse-linux-gnueabi/lib") armv7*h*l, with no hf on gnueabi. I'm not sure if this implies anything for the SuSE build over Ubuntu, as they are both hardfloat, it may just be semantics.

ldd output on both systems match with the original file. Other than the change on that dependency and a few relatively minor comments, probably from different compilers on different distros, I am at a complete loss.

I have strace outputs from the file I built and the file that was given to me.

Good: http://pastebin.com/ef8Svn1Q

Bad: http://pastebin.com/04fyP5xt

I am completely at a loss as to why this happens, because all other small test programs I try work flawlessly. It's just this one file for some reason. A compile with mtune=cortex-a8 didn't change anything, and it would be a complete bummer if we had to distribute a build with "Oh by the way, you have to compile your own binary to even run the thing." Plus, I suspect there are some underlying problems that may arise with this.

Relevant {to my knowledge} compiler options:

-march=armv7-a -mtune=cortex-a9 -mfloat-abi=hard -mfpu=vfpv3-d16

the FPU matches both cpus, and both are hardfloat armv7a.

Any ideas?

Edit: found some new info with Valgrind.

-1929-- Reading syms from /home/casey/Unreal/System/UCCLinux.bin.orig (0x8000) --1929-- Reading syms from /lib/arm-linux-gnueabi/ld-2.15.so (0x4000000) --1929-- Considering /lib/arm-linux-gnueabi/ld-2.15.so .. --1929-- .. CRC mismatch (computed c6793f6a wanted 66aab705) --1929-- object doesn't have a symbol table

valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: memcpy valgrind: in an object with soname matching: ld-linux.so.3 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux.so.3

My distro has both hardfloat and softfloat libs, even though I thought they were mutually exclusive.

GenericHero
  • 1
  • 1
  • Can you add the following please?: - What distribution, which version, on each of the targets. - The actual output of ldd on the binary on each target, as opposed to your interpretation of it. – unixsmurf Apr 25 '13 at 22:49
  • Thanks for wanting to help out. Information is in pastebins below. Cortex-A9{good} http://pastebin.com/wzDL760w Cortex-A8{bad} http://pastebin.com/Xcry4PGU – GenericHero Apr 26 '13 at 05:43
  • You have a failure here, `A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22\4\24\1\25\1\27\3\30\1\31\1\32\2\33\3\34\1\"\1,\1"`. One version likes this, the other doesn't. What does `readelf -Ah Core.so` say and the same for some program you can run on the **Cortex-A8**. You can run `arm-none-linux-gnueabi-readelf` on your *dev* host of course. – artless noise Apr 26 '13 at 14:51
  • Cortex-A8 http://pastebin.com/9uKWau4z Cortex-A9 http://pastebin.com/sgkeWHLM Looks like no difference. arm-none-linux-gnueabi-readelf was not on the dev system. – GenericHero Apr 26 '13 at 19:33
  • Whoops, forgot to add a program I compiled myself. http://pastebin.com/ZcxFMEDR – GenericHero Apr 26 '13 at 21:42
  • I ghetto fixed the problem. It looks like it was searching for hardfloat libs in the soft float folder. A quick symlink of /lib/arm-linux-gnueabihf to /lib/arm-gnueabi fixed it. However, this is probably not an ideal solution. I don't know if this is a problem with Ubuntu/SuSE or somehow with the ELF itself. My bandaid patch of recompiling the ELF probably made it search the correct directories. – GenericHero Apr 27 '13 at 06:04

0 Answers0