title: binary/ELF silently exits on different ARM system
body: <p>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:</p>
  
  <p>casey@arm:~/Unreal/System$ ./UCCLinux.bin.orig
  casey@arm:~/Unreal/System$</p>
  
  <p>I built my own UCCLinux.bin that uses the shared objects that are <em>unchanged</em> 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.</p>
  
  <p>There is also this search path on the working system that confuses me:
  SEARCH_DIR("/usr/armv7hl-suse-linux-gnueabi/lib")
  armv7*<em>h</em>*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.</p>
  
  <p>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.</p>
  
  <p>I have strace outputs from the file I built and the file that was given to me.</p>
  
  <p>Good:
  <a href="http://pastebin.com/ef8Svn1Q" rel="nofollow">http://pastebin.com/ef8Svn1Q</a></p>
  
  <p>Bad:
  <a href="http://pastebin.com/04fyP5xt" rel="nofollow">http://pastebin.com/04fyP5xt</a></p>
  
  <p>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.</p>
  
  <p>Relevant {to my knowledge} compiler options:</p>
  
  <p>-march=armv7-a -mtune=cortex-a9 -mfloat-abi=hard -mfpu=vfpv3-d16</p>
  
  <p>the FPU matches both cpus, and both are hardfloat armv7a.</p>
  
  <p>Any ideas?</p>
  
  <p>Edit: found some new info with Valgrind.</p>
  
  <p>-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</p>
  
  <p>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</p>
  
  <p>My distro has both hardfloat and softfloat libs, even though I thought they were mutually exclusive. </p>