Run armel binary file on official armhf debian image

[PaceyIV]

I share a way to run armel binary file with the official armhf debian image.

Code Select Expand


$ sudo ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3


In Debian architecture terms ld-linux.so.3 is the armel dynamic linker (i.e. the
armv5 compatible one). If you have an armhf (i.e. armv7) system then you
will have /lib/ld-linux-armhf.so.3 instead.

Without ld-linux.so.3 you get confusing error messages like: "file not
found", "this is not a dynamic executable"

[Tele]

I share a way to run armel binary file with the official armhf debian image

Running armel binary on an armhf system is highly NOT recommended. I could say, you must not do that.

Armel binaries pass floating point values in integer registers while armhf binaries pass them in vfp registers.
Its not a linking problem to solve. They are incompatible, you cant mix them. This is not about a library to hack, but all of them on your system.

[PaceyIV]

You can look at this post https://groups.google.com/forum/#!topic/linux-sunxi/ywN3mqY-bZw

Without that link I was unable to run that binary file.

[Tele]

Yes I absolutely know that situation.
The linked googlegroups topic mistakenly states that armel and armhf are compatible.

No, they are not, and if your system libraries are built for armhf, then they dont't want to run armel, for reason, its not just an annoying bug to solve.

You were lucky, because your binary does not use floating point, that's all.
If it was using floating instructions, then it would have crushed, got frozen in a second.
An how do you know which binary uses fp, which one doesn't? You don't, you can't know that.

So you can't give that advice:
"here you go guys, this is the method how to run armel on armhf system"
This is misguiding, because you must not run armel on armhf and vica versa, its forbidden.

The only correct solution is recompiling your binary from sources, with a correct compiler
(arm-linux-gnueabi or arm-linux-gnueabihf) to get the appropriate binary or library.

[Tele]

I can show you a script here,
it's purpose to check if an unknown arm binary or library whether is armel or armhf.

Code Select Expand

atype() { if [ 1 -gt $# ] ; then echo "usage: $0 <eabi-executable>" ;
          else
             atype=`readelf -h $1 | grep Machine:` ;
             if [ "x$atype" = "x" ] ; then echo "'$1' is not an ELF" ;
             else mach=`echo $atype | grep ARM`;
                if [ "x$mach" = "x" ] ; then echo "'$1' is not an ARM executable" ;
                else atype=`readelf -A $1 | grep Tag_ABI_VFP_args`;
                   if [ "x$atype" != "x" ] ; then
                   echo "'$1' uses hard-float, vfp (armhf)"
                   else atype=`readelf -A $1 | grep NEON`;
                      if [ "x$atype" = "x" ] ; then echo "'$1' uses soft-float (armel)" ;
                      else echo "'$1' uses hard-float, neon (armhf)"
                      fi
                   fi
                fi
             fi
          fi }


For example:
if you copy-paste this in your ~/.bashrc (if you use bash shell) or ~/.profile (if you use bourne shell) file, then you will have a new command:

Code Select Expand


atype <binary file>

to check your arm binaries.
(readelf must be installed on the system -> sudo apt-get install binutils )

[PaceyIV]

Your script says that idevsutil uses soft-float (armel) and my debian uses hard-float, vfp (armhf).

idevsutil use floating point math.
While it uploading file to IDrive server it prints upload speed with two decimal points.
It uses time and date.

[Tele]

>> "While it uploading file to IDrive server it prints upload speed with two decimal points"

And you don't understand how could it work if I would be right. If.
Because it seems armel and armhf live together in peace.

A possible explanation:
there is no necessity to use fpu, when we are doing floating point math:

Code Select Expand


int a=10;
int b=4;
printf("%d/%d = %d.%d\n", a, b, a/b, 10*(a%b)/b);

the result will be

Code Select Expand


10/4 = 2.5

without using any floating point operation. This is a common trick to speed the things up, or we just don't want to link fp math library. Actually its not even a trick, this is how people divided 2 numbers 'with paper and pen' , manually, in the old times, before calculators. 10 times the reminder and divide again...until there is no reminder. Only integers here, no double or float.

Btw, I just told my opinions about mixing armel and armhf. You don't have to take it seriously if you don't want.
You think I'm wrong, or am I missing something? It seems illogical? Is something fishy ?

[PaceyIV]

Mmmmm

I don't say you wrong, I just want to understand. It's something that I don't know.

I'm trying to study that binary executable.
If I analyse all legible strings within the binary file with strings command I can see this:

Code Select Expand


<item offset="%.0f" size="%.0f" tottrf_sz="%.0f" tot_sz="%.0f" cum_size="%lld" per="%d%%" rate_trf="%.2f%s" remain_time="%d:%d:%d" trf_type="FILE IN SYNC" fname="%s"/>
kB/s
[%15.0f] [%15.0f] [%15.0f] [%15.0f] [%lld] [%3d%%] [%7.2f%s] [%4d:%02d:%02d] [FILE IN SYNC] [%s]


Network speed is print as floating point number, not decimal.

I also found the use of functions like __floatundidf, __adddf3,

http://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html


With this information can I say that this executable use soft floating point math?

[Tele]

I don't know that Pacey.
To be honest, I have never tried to call armhf functions from armel and vica versa.

..armel binaries pass floating point values in integer registers while armhf binaries pass them in vfp registers

I have read that in a book, or in a specification, I can't recall where.
And they said its perilous and forbidden, and I believed that. I have never checked it, whether its true or not.
I think I understand its why a "must not".

You are still looking for a disproof. Maybe you are right. At least you are much more precise than me, you want to understand it deeply. You will discover new things, I wont.
But don't waste your time on needless efforts, you are much smarter than that.

PS: I'm not sure, but printf("%f",f) probably does not use fp at all, because its just interpreting a storage as float and printing as chars to std, don't need to calculate anything by fp operation. But using float as variable, that is a suspicious thing. You don't use integer operations on a floating point variable.
I guess that program uses floating point although, but doesn't call the armhf math fp library, or any other function with float arguments, in a dynamic library. Its just a guess.
There is no guarantee that it never does that, just it didn't do that, so far.

[einmalfel]

Hi, all!

Pacey, please tell if you found something out about the subject. Under what conditions armel binaries could run on armhf disto?

AFAIK, binaries of armhf debian distribution indeed use FP registers to pass function arguments, as Tele said.
I think, your executable could run on armhf distro because of:
- compiler doesn't optimize printf args out to VFP registers as it is a variadic function
- the binary is linked statically with glibc
- the binary is built for armhf target with -msoft-floats

[MBR]

I never looked into a disassembled compiler output for ARMs, but the code like printf("%f",a/b); will IMHO probably work even when the binary is compiled as armel (soft-float) and run on armhf (hard-float), because there is no calling with passing floating point numbers in registers. The division itself is generated as "inline" assembly instruction and the printf() does not use registers for input parameters anyway, because it's a variadic function (a function  with indefinite number of arguments) and all the input arguments are passed via the stack. But "real" mathethematical functions, for example the square root, logarithms, trigonometrics and such, defined in math.h and linked with -lm (so the resulting binary is linked with libm.so), will not run across architectures, because the difference in argumment passing.