Introduction and content of Floating Point Problems in QT Transplantation
Author: lanxinyuchs http://lanxinyuchs.iteye.com/blog/1037265
Floating Point Problems
Inter Xscale is a new high-performance, low-power microarchitecture compatible with the arm v5 te isa instruction set, but does not support floating point instruction sets. This is to reduce the size of the processor chip and reduce the power consumption. The XScale architecture does not implement expensive floating point computation components and division components. These operations are not commonly used in embedded applications. When this type of operation is required, it must be implemented through software. Floating-point operations are much more complex than integer operations. What is the problem if there are no floating-point operation units?
Of course there is a problem. Can a computer with invalid commands be used in your printf ("% f", 0.5?
Before describing the following questions, I would like to give you a few terms to easily describe them.
Toolchain: a series of tools for cross-compilation, including compilation, debugging, disassembly, and elf information reading.
Hard floating point toolchain: the tool chain compiler gcc's glibc standard library for floating point computing directly uses the processor's floating point commands.
Soft floating point toolchain: The floating point calculation in the glibc Standard C library of gcc compiler of the tool chain is replaced by an integer Algorithm Without floating point commands. The compiled target file does not contain floating point commands.
In fact, there are no problems. There are two solutions to solve such problems:
First, the Linux kernel supports built-in floating point simulators. Exceptions generated when floating point commands are caught by the kernel for conversion:
Reference the following content:
When configuring the kernel, You must select a floating point simulator NWFPE, as shown below:
-At least one math emulation must be selected │
│ NWFPE math emulation │
│ [] Support extended precision │
│ Fastfpe math emulation (experimental)
If there is no floating point simulator, an error occurs. For example:
Undefined instruction
In fact, even if nwfpe is used, the floating point problem of the system is not completely solved.
Nwfpe simulates the floating point by using undefined functions handler, that is, an undefined instruction exception (exception) occurs every time a floating point instruction is operated. In the handler of this exception, simulate a floating point instruction using a software method.
If there are many floating point operations in the software, isn't it necessary to constantly request the CPU to execute undefined instruction and then generate an exception?
Correct. In fact, this is the case when the kernel simulates floating point commands.
The consequence of doing so is to bring about extremely frequent exceptions, greatly increasing the interruption delay, in other words, reducing the real-time performance of the system. In addition, every time a floating point operation occurs, the exception occurs. It is difficult to imagine that it will bring huge performance overhead.
The kernel simulates floating-point commands to implement a large case switch. Generally, this branch won't hit the prediction. It will not only waste CPU clock, but also empty BTB, this further reduces the prediction hit rate of subsequent branches.
What should I do? What should I do? What should I do?
Don't worry ......
The second method is to use soft floating point, that is, to replace all floating point operations during compilation. The processor does not see any floating point commands.
Soft floating point support is provided by the cross tool chain and has nothing to do with Linux kernel. When a floating point operation is compiled using a soft floating point tool chain, the compiler replaces the floating point operation with an inline Floating Point Library so that the generated machine code does not include any floating point instruction, but it can complete the correct floating point operation. Because it is optimized during compilation, This method enables the CPU to execute continuous commands even when performing floating-point operations to reduce program split.
Using Soft floating point tool chain compilation results in faster floating point operations, which is an order of magnitude faster than nwfpe simulation.
How do we know whether the cross tool chain supports soft floating point? It's easy to add the-msoft-float CFLAGS when using the compilation command, for example
Arm-linux-gcc test. c-msoft-float-o test
If the toolchain supports soft floating point, you can generate executable documents. If an error occurs, sorry, this toolchain is not supported.
Whether the compilation chain supports floating point-msoft-float depends on whether its glibc Standard C library contains floating point commands. This parameter is not supported when most compilation links are built.
To identify whether an application or library is a soft floating point, use
Arm-linux-readelf-e test
You can print the elf document header information, and the software FP is in soft floating point format. Otherwise, no.
Flags: 0 × 202, has entry point, gnu eabi, software FP
The toolchain that comes with the UP-TECHPXA270 development we use fully supports soft floating points, and the default soft floating point, that is, the-msoft-float option is automatically added.
Here, we will share some of these issues.
During kernel compilation, the compilation chain is also required. Is this soft floating point compilation chain also used? No. In general, the kernel does not require floating-point operations. Floating-point operations are generally used for multimedia. Unless some module drivers are manually added to use floating point operations. Therefore, the soft floating point compilation chain is not used for Kernel compilation.
Two compilation links are included in the CD. One set is installed in the opt folder and the PATH is added to the PATH environment variable. This arm-linux toolset is the default toolchain.
There is also a set of included 2.6 source code
/Up-techpxa270/arm-linux-tools/gcc-3.4.6-glibc-2.3.6/
Careful friends may find that the two gcc versions are different.
When compiling the QT4 library, the compilation chain in the PATH cannot be compiled, but the compilation can be successful if this set is specified manually, however, commands are still invalid when running on the Development Board.
Why are there two toolchains? Why can't one set work? Is it because of the gcc version? Or what?
Do you still remember that the kernel just analyzed does not require floating point operations?
Open the Makefile file in the kernel source code.
/Up-techpxa270/kernel/linux-2.6.9/Makefile
Found in row 195
CROSS_COMPILE =/up-techpxa270/arm-linux-tools/gcc-3.4.6-glibc-2.3.6/arm-linux-
This specifies the path of the toolchain used to compile the kernel. According to the previous method, we test that this toolchain is hard floating point.
Lenovo's previous kernel analysis comes to the fore.
The kernel does not use floating point. Therefore, the kernel is compiled with a hard floating point compilation chain, which is manually specified in Makefile.
The application uses floating point and needs to use soft floating point tool chain for compilation. So add this soft floating point compilation chain to the PATH. You can use arm-linux-gcc directly during compilation.
The Analysis of floating point problems is now complete.
We can understand that QT4 compiled using the hard floating point compilation chain of the compiled kernel will contain floating point commands and will fail to run on Xscale. But why does QT4 compilation fail to use soft floating point compilation chains?
I carefully checked the configure options of QT4 and found that
-No-arm-fpa
This option. The arm processor has no floating point! This option must be enabled.
I will analyze it again. The graphics library belongs to multimedia. Generally, there are two algorithms for multimedia decoding and computation. One is based on the floating point and the other is based on the integer. Generally, the floating point algorithm is faster, so the floating point algorithm is usually used, QT4 is no exception. However, if floating point operations need to be simulated, they will never be faster than integers, so this option is necessary. In QT4, algorithms must be compiled by aggregation, so this option will appear.
Compile again and find that the compiler prompts a new error.
I carefully observed the error information and found that an error occurred while compiling the demo. It is a floating point conflict with the hidden target file included in the demo source file folder. Now, I understand it very well, you can use arm-linux-readelf-e to read the demo's hidden target file as a hard floating point, which naturally cannot be compiled successfully, as for why the Open Source QT source code contains a pre-compiled target file, this cannot be verified. If you are interested, please check it and send me an email after the study is completed. At this time, the compilation has come to an end, and all the libraries should have been compiled successfully, so running should not be a problem.
Copy the Library to the board and create environment variables (skipped here, not related to this article, specifically set the library directory, font directory, touch screen, if you do not know how to search for a dog or ask me), run example, OK, and no command is prompted ~
Opening a champagne celebration ~~~~ Suspect? Undefine symbol asof8eq934htpwer8gusa in /...... /...... /Lib/libQtNetwork. so.1
Still cannot run?
This is a problem with QT4. Is there no defined symbol? This error is not literal. In vc, this error occurs generally because some header files are not referenced, and some functions used in the source file cannot be connected to the target file in the link phase.
For a dynamic library, the function cannot be found during running. When the program is running and the functions in libQtNetwork. so need to be used, you can find them, but you cannot find them for a long time ......
Why? I used the lazy method. I went to libQtNetwork. so to find out where the function went.
Arm-linux-readelf-symbol libQtNetwork. so
You can read all the symbrs. Wow, there are so many, and there are thousands at least. What should I do ......
Arm-linux-readelf-symbol libQtNetwork. so | grep hasodifyq0384hieuhfaousef
How can I find the function symbol by redirecting the pipeline to the grep program? Place a dog to search ......
The result is that the missing function symbols are all more than 25 characters in the error message of the application running, and the list of read symbols is truncated at exactly 25 characters ...... Such a strange number? Why not 16 32? Unknown cause.
This is a strange question ......
But Tian Yi is amazing ...... I was surprised by the fact that I was not superstitious ......
I have learned C ++ standard template library C ++ STL. Should I have learned this little from my peers? First of all, C ++ has never learned any STL that has never been mentioned in almost any C ++ book.
As far as I know, STL leads to a catastrophic extended function name. Its template technology, after complicated processing by the compiler, changes the number of digits of the function name to avoid the need to duplicate the function name, compilation with C ++ also leads to a longer-loaded function when it is converted into C code.
I searched for the parameters in QT4 configure with my attempt.
./Configure-help | grep stl
QT4 configure parameters found are as follows:
-No-stl
My mom ...... It's a coincidence that I have little knowledge ...... The root cause of this strange problem will also be discovered ......
Now let's think about it. By default, the compilation chain truncates the function name by 25 characters. In the embedded system, using stl template technology should slow down the program, and stl is not necessary to speed up development.
Okay, Add.
In fact, I also compiled zlib ...... Alas, I don't want to talk about this. I need to change the Makefile ...... Low correlation
Therefore, qt4 Compilation
./Configure-no-arm-fpa-no-stl add other options-arch and so on
Copy four so databases, font library, and example again
Run
./Example-qws
Congratulations ~ Successfully pulled ~~~~~~~~~~~
At this point, all analyses are complete, and all analyses are smooth!