| The first blog. Write down a recent bug. Fill in something for the bald blog.Recently, we have maintained a program that has been out of service for a long time, including applications, library files, and a Linux Device Driver. A long time ago, the program was compiled using ARM-Linux-GCC 3.4.3. Recently, when we used arm-Linux-GCC 4.1.1 for compilation, we found that the program could not run. After trying, we found that the program could not run normally after compiling the program in the form of shared library. If the library and the application static linking are combined, the correct result can be obtained.I have been thinking about it for a long time. Several people had to study arm's documentation to find the answer. It is also a hard task. Finally, I found the answer in an arm document. R12, once regarded as general register, is no longer just a general register. In the new specification, it is called intra-procedure-call scratch register. The following is an excerpt from some documents: Register R12 (IP) may be used by a linker as a scratch register between a routine and any subroutine it CILS (for details, see § 5. 3.1.1, use of IP by the linker ). it can also be used within a routine to hold intermediate values between subroutine CILS Both the arm-and thumb-state BL instructions are unable to address the full 32-bit address space, so it may be necessary for the linker to insert a veneer between the calling routine and the called subroutine. veneers may also be needed to support arm-thumb inter-working or dynamic linking. any veneer inserted must preserve the contents of all registers cannot IP (R12) and the condition code flags; A conforming program must assume that a veneer that alters IP may be inserted at any branch instruction that is exposed to a relocation that supports inter-working or long branches. That is to say. Now, if the Assembly Code contains BL commands and R12 is used as a general register, the R12 value may be modified by the veneer program inserted by the linker. Of course, if the source code is pure C code, arm-Linux-GCC 4.1.1 itself will not make such a mistake. However, due to some assembly code in the program I maintained, the assembly code I wrote earlier did not estimate this factor. This is why this strange problem is triggered. Oh, right. Send a reference to the document.[1] "procedure call standard for the ARM architecture", 19th January, 2007, Richard Earnshaw. |
|
