FAQ Content[DESCRIPTION]
Native Exception, referred to as NE, is the most common exception that occurs in C + + code, and for simple NE, we can infer the cause by the invocation logic that backtrace prints. But slightly more complex NE, such as memory corruption caused address access anomalies, such as a variable in the multi-layer function calls between the abnormal tampering, such as the function pointer uninitialized caused by abnormal jump and so on, just rely on log and backtrace become slightly powerless. For such cases, we need to have a deep understanding of architecture related knowledge and various related tools for the analysis of assembly language level. In view of the relative divergence of knowledge distribution, we will need to debug NE of the relevant knowledge listed here for reference learning. [SOLUTION]
First, the basic part of the study:
| ARM Architecture |
Reference documents ARM Architecture Reference Manual, in the arm of the official website can be found, can find armv5te version of the study, there is a need to refer to the ARMV7 version. Part 1 is a mandatory part of the instruction set architecture, Part 2 is also important in relation to MMU, and it helps to better understand CPU operations, process management, and Linux code study. |
| Atpcs, ARM-THUMB procedure Call standard |
There are manuals on the network to retrieve, to be able to understand how parameters are passed through registers and stack for process invocation. |
The above two parts for the various C/s + + exception processing are universal, for those who want to understand high-end analysis techniques or in-depth hack code is the first step must be intensive knowledge. Second, for the native exception part:
| Online/offline Debug |
Learn how to use ARM-EABI-GDB to debug the Android native layer code, including using GDB to connect target for online debug, as well as using GDB and coredump to restore the anomaly scene for basic analysis. Focus on the use of tool and familiarity with the roles and limitations of the two debug techniques. (Relevant knowledge can also be searched on the web) |
| The use of Toolchain |
To know how to disassemble through the arm-eabi-objdump, if you go through the arm-eabi-addr2line to see the corresponding line number of an address, if through arm-eabi-readelf to see the structure of the elf and so on, It is better to be familiar with tools such as arm-eabi-xxx. After familiarity with the structure of the elf, these tools can help to extract more debug information to the fullest extent. |
| The signal mechanism of Linux |
You can refer to the 10th chapter of the second edition of Advanced Programming for UNIX environment, which suggests a detailed study. (Ne will be accompanied by the signal of the issue) |
| Ptrace mechanism |
Refer to the Linux man page, as well as the various reference information on the Internet, to understand how to use, the principle can refer to kernel code. (Ptrace is the mechanism to debug another process with one process, which is also the core implementation of GDB) |
| Coredump mechanism |
Refer to the Linux man page (tapping man core at the Linux PC Terminal prompt). Coredump is the most effective means of debug ne. |
| ELF Spec |
ARM's elf spec can be searched on the internet, with arm elf to retrieve it. It is advisable to look at the structure of the elf and see what debug information is available to me in the elf. And how to use arm-eabi-readelf to look at this information. |
| Unwind mechanism |
Refer to the exception handling ABI for the ARM architecture, learning how the Android Debuggerd process uses Elf-related information to restore backtrace. |
| Debuggerd mechanism |
Refer to the Android native code, under/system/core/debuggerd. Tombstone is the use of debuggerd to catch. Looking at code can tell you how the information in the NE in the log is obtained and printed. |
|
