Most debugging sessions will involve debugging some type of program. The program may already be on the target when the debugger connects, or the program may be loaded as part of the debugging process. The situation gets more interesting when you consider where the program will be run, and what the program does contain and does not contain.
The Armv8-A architecture does not specify a set memory map or layout. This means that the arrangement, type, and addresses of memory for an Armv8-A SoC depends on the design of the target. Before trying to load a program, you should check the documentation for your target to see what memory is available, and where that memory is located.
Some targets or execution environments require writing a program to flash memory. Flash memory requires a lot more from the debugger, and the user, than other memory types. This is because writing a program to flash memory usually involves having a flash algorithm written in a C-style language. The algorithm provides a flashing-capable debugger with the information it needs to access the flash memory. Each flash device has its own set of requirements, and each debugger will have its own flash information requirements and procedures.
Programs are sometimes executed from read-only memory (ROM) types. This only affects a debugger session when setting breakpoints. We will discuss this in detail in Breakpoints.
If you work with GNU Compiler Collection (GCC) or Arm Compiler 6 when debugging your system, the tools produce an Executable and Linkable Format (ELF) image. An ELF image contains the code and data of the program, and additional metadata, for example debug information. This debug information tells a debugger how to match the binary back to the source when debugging.
This screenshot shows what happens when you are debugging using Arm Development Studio. You can see, in the area with a red outline, that the Program Counter (PC) location is specified in the Disassembly view with a small blue arrow and green highlighted code. However, the function that the code belongs to is not listed in Disassembly view, and the PC location is not indicated in the associated source file: startup.
If you load the program’s debug information, you would see what is shown in the following screenshot:
Now, the PC location and the associated function, start64, are both indicted in the Disassembly view. In addition, the PC location is indicated in the associated source view.
You might work with programs that do not have debug information, or with programs that only have partial debug information. For example, a program may be built against a third-party library that does not have debug information. You can still debug such programs, but the debug process may be more difficult.