Workaround for visual GDB breakpoint invalid

(This article mainly lists the experience and methods to solve several breakpoint failures, which may be of great help to the developers who struggle with the puzzling problem.)

First, let's look at a typical structure of an Android app that includes native code:

The app code is packaged in an. apk file, in effect, the. apk file is a zip-format compression package that includes a Classes.dex file (all Java code included) and one or more stored in the Lib\<eabi name > The local code library file under the directory. Under normal circumstances, the work steps for an app that contains native code are as follows:
1. Android System load Java code, start to execute
2. Loading the local code base with the System.loadlibrary () method in Java code
3. Functions implemented by Java code calling native code

Each local code base has two versions: a full version with debug information, this version of the library file contains the corresponding source code, and the binary code address in the library file corresponds to the line of the source code file. This version of the file is stored in the Obj\local\armeabi directory under your project path. A version without debug information, this file is located in the Libs\armeabi directory, and finally the library file that is actually packaged into the APK file is this version of the file.
Set breakpoints

When you set a breakpoint in a line in a source code file, GDB needs to do something first to actually create the breakpoint and let the breakpoint trigger on the back.
Assuming that libNative1 has been loaded, the in-memory start address is 0x10000, and the user wants to set a breakpoint on line 24th of the source code file C:\main.cpp, GDB will do the following to set the breakpoint: GDB searches for loaded library files searched "C : \main.cpp "file corresponding to the library file, in the example of this article, is the libnative1.so library file. GDB in the Obj\local\armeabi directory to find a file called libnative1.so, as described above, the file in this directory is with debugging information. GDB reads the symbol table in the source code file (c:\main.cpp) in this library file. GDB calculates the address offset of the 24th line according to the read-out symbol table, which is +0x2. This offset is then added to the starting address (0x10000) of the library file libnative1.so and the breakpoint is set at the 0x10002 location.

The 3-step operation fails at any one step, the breakpoint is not created, or an error is created, causing it to never be triggered. We'll explain how to diagnose this problem in the next section and how to fix it. Diagnose problems

This section describes in detail how to check for methods that cause breakpoints to fail due to an irregular configuration or missing files.

A. Make sure the library file is loaded

The first thing to do is to make sure that the local code base is already loaded and that GDB is not already aware of the issue. We can enter the "info shared" command in GDB to view it.

The results of the info Shared command contain three important information:
1. Linker connector
2. libc.so file
3. All local code library files that you want to debug
This provides an example:

From to Syms Read Shared obje CT Library
............................................................ No com.visualgdb.example.MyAndroidApp
0xb0001000 0xb00069d0 Yes C:/.../androidbinarycache/.../linker
0x40073300 0X400A12FC Yes c:/.../androidbinarycache/.../libc.so
0X5148FCCC 0x51491198 Yes e:/.../obj/local/armeabi/libmyandroidapp.so

If some library files are not shown here, you can manually force GDB to reload the symbol table by using "Sharedlibrary".
If you have a. so file (for example, libmyandroidapp.so) already listed here, but the display symbol is not loaded (the "sysms read" column has a status of "no"), which means gdb cannot find a library file with debug information. You can then use the "show Solib-search-path" command in GDB:

You can see that your project's Obj/local/armeabi directory path is printed, which should contain a. So file with debug information, if there is no. so file under that directory, copy the correct. So file to this directory and rerun the Sharedlibrary Command
In addition, you can also use the "set Solib-search-path" command to force GDB to search for. So files in other directories.
If your. So file is still not listed, the instructions have not been loaded by Java code, please confirm that the System.loadlibrary () method in the Java code is called correctly, and that no exception is generated. B. Make sure you use the correct file path

Another common cause of breakpoint invalidation is that you use a different directory when you build and debug your project. For example, if you compile the library file when the project source code is located in C:\projects, and then you move the source code to the D:\projects directory, then set a breakpoint in the D:\projects\main.cpp file will fail, GDB does not use D: \ Projects\main.cpp This source file to replace the file in the original directory. Problems like this can be resolved by examining the source file and comparing it to the source file when the breakpoint is set, you can remove all breakpoints, then reset the breakpoints, and then look at the GDB command shown in your IDE to see exactly which source file you set the breakpoint on, whether it is the same as the source file when the library file was generated.

From the image above you can see the-break-insert command used to set breakpoints to show the path of the source file you are using, and then use the "info sources" command to see what source files GdB really finds.

Copy the output of this command into a text editor, and then find the source file you want to debug (say Myandroidapp.c):

If there is no source file that you want to debug in the output, then your home's. So file version is wrong (see the previous section for the version of the. so file). If the data results have files that you want to debug, but the path is inconsistent with the path of the source file that you displayed when you use the-break-insert command, this is the reason you need to find out. In this case, recompile your project under the new path, or put the source file back to the old path, so that you can ensure that the source file for the breakpoint you set is consistent with the source file path of the "info sources" command output.
Again, GDB needs you to set the breakpoint source file path and the info sources command to print out the file path exactly. Includes a double slash preceding the JNI. C. Recheck the file version and do a cleanup operation

If you set a breakpoint, but never takes effect, there is also a possibility that your Android app will load the. So file and the version of the. so file that your gdb uses to calculate the address. The most common cause of this is when Android is loaded with a bug that does not load the file under the armeabi-v7a directory, but instead loads the library file in the Armeabi directory. If you think it might be the case, try to modify the build configuration, either on the Armeabi platform or on the ARMEABI-V7A platform, and do not compile at the same time as the other two platforms. ("Translator note" The original person did not mention armeabi-v7a, and now suddenly came out, Armeabi and armeabi-v7a are different CPU types, the latter with other functions including floating-point arithmetic, through the android.mk file target_cpu_ API to specify that if ARMEABI-V7A is selected, the previously mentioned Xxx\armeabi directory will become xxx\armeabi-v7a, and an Android project with NDK development may have multiple android.mk, the original author It means that all android.mk files have the same TARGET_CPU_API settings)