文章转自quic工程师的blob:
Here are some key concepts to keep in mind when debugging Linux on Trace32:
- Process Scheduling. Linux scheduler allocates CPU time slices to processes. The scheduler manages the time slices using timer interrupts and selects the next best task at each scheduling. This means that when stepping through the code in Trace32, you may see the program counter jumping to scheduler or another process. As a result, especially for userspace debugging, one has to be aware of which process you are debugging.
- Virtual memory. 1G/3G virtual memory split is the most common memory split found in Linux systems. This means that top 1G virtual memory is reserved for Linux kernel and the remaining 3G is available for userspace processes. So while debugging, at any point the code from 0xC0000000 to 0xFFFFFFFF is kernel code, while 0×00 to 0xBFFFFFFF is userspace. The userspace code is process specific, so one cannot assume that you will hit the same code at a given address, as this will depend on the userspace process that is running.
- Dynamic libraries. Shared libraries may be loaded dynamically at runtime. If you are debugging one of these libraries that is loaded at runtime, you will have to know the address at which the library loaded, and map the library symbols accordingly. Android prelinks commonly used libraries at predefined addresses in the virtual address space of the process. You can check out build/core/prelink-linux-arm.map in the Android build tree for this information. On target, you can also ‘cat /proc//maps’ to get information on libraries and their addresses that are loaded in a process’s context.
- Loading symbols. Since the top 1G virtual memory is always used by Linux kernel, one can load Linux kernel symbols from vmlinux and the symbols in top 1G will always be valid. However when loading userspace symbols, one has to load them in process context. This can be specified as part of the data.load command.
阅读(3954) | 评论(0) | 转发(0) |
