Home | | Embedded Systems Design | Symbolic debug

Chapter: Embedded Systems Design : Emulation and debugging techniques

Symbolic debug

The ability to use high level language instructions, func-tions and variables instead of the more normal addresses and their contents is known as symbolic debugging.

Symbolic debug

 

The ability to use high level language instructions, func-tions and variables instead of the more normal addresses and their contents is known as symbolic debugging. Instead of using an assembler listing to determine the address of the first instruction of a C function and using this to set a breakpoint, the symbolic debugger allows the breakpoint to be set by quoting a line reference or the function name. This interaction is far more efficient than working at the assembler level, although it does not necessarily mean losing the ability to go down to this level if needed.

 

The reason for this is often due to the way that symbolic debuggers work. In simple terms, they are intelligent front ends for assembler level debuggers, where software performs the automatic look-up and conversion between high level language structures and their respective assembler level ad-dresses and contents.

 

12 int prime,count,iter;

 

13

 

14 for (iter = 1;iter<=MAX_ITER;iter++)

 

15                           {

 

16                           count = 0;

 

17                           for(i = 0; i<MAX_PRIME; i++)

 

18                           flags[i] = 1;

 

19                           for(i = 0; i<MAX_PRIME; i++)

 

20                           if(flags[i])

 

21                           {

 

22                           prime = i + i + 3;

 

23                           k = i + prime;

 

24                           while (k < MAX_PRIME)

 

25                           {

 

26                           flags[k] = 0;

 

27                           k += prime;

 

28                           }

 

29                           count++;

 

Source code listing with line references

 

 

000100AA 7C01  MOVEQ #$1,D6

000100AC 7800  MOVEQ #$0,D4

000100AE 7400   MOVEQ #$0,D2

000100B0   207C 0001 2148 MOVEA.L #$12148,A0 000100B6

11BC 0001 2000 MOVE.B #$1,($0,A0,D2.W)

000100BC 5282   ADDQ.L #$1,D2

000100BE 7011   MOVEQ #$11,D0

000100C0   B082 CMP.L D2,D0

000100C2   6EEC          BGT.B $100B0

000100C4   7400  MOVEQ #$0,D2 000100C6 207C 0001 2148

 

MOVEA.L #$12148,A0 000100CC 4A30 2000 TST.B ($0,A0,D2.W) 000100D0 6732 BEQ.B $10104 000100D2 2A02 MOVE.L D2,D5 000100D4 DA82 ADD.L D2,D5 000100D6 5685 ADDQ.L #$3,D5

 

 

 

Assembler listing

 

 

›>> 12 int prime,count,iter; ›>> 13

 

›— 14 => for (iter = 1;<=iter<=MAX_ITER;iter++)

 

                            000100AA 7C01 MOVEQ #$1,D6

 

›>> 15 {

 

›>> 16 count = 0;

 

                            000100AC 7800 MOVEQ #$0,D4

 

›— 17 => for(i = 0;<= i<MAX_PRIME; i++)› > 000100AE 7400 MOVEQ #$0,D2

 

›>> 18 flags[i] = 1;

 

                            000100B0 207C 0001 2148 MOVEA.L #$12148,A0 {flags}

                            000100B6 11BC 0001 2000 MOVE.B #$1,($0,A0,D2.W)

›— 17 for(i = 0; i<MAX_PRIME; => i++)<=

 

› 000100BC 5282 ADDQ.L #$1,D2

 

›— 17 for(i = 0; => i<MAX_PRIME;<=i++)

 

                            000100BE 7011 MOVEQ #$11,D0

 

                            000100C0 B082 CMP.L D2,D0

 

                            000100C2 6EEC BGT.B $100B0

 

Assembler listing with symbolic information

 

The key to this is the creation of a symbol table which provides the cross-referencing information that is needed. This can either be included within the binary file format used for object and absolute files or, in some cases, stored as a separate file. The important thing to remember is that symbol tables are often not automatically created and, without them, symbolic debug is not possible.

 

When the file or files are loaded or activated by the debugger, it searches for the symbolic information which is used to display more meaningful information as shown in the various listings. The symbolic information means that break-points can be set on language statements as well as individual addresses. Similarly, the code can be traced or stepped through line by line or instruction by instruction.

 

This has several repercussions. The first is the number of symbolic terms and the storage they require. Large tables can dramatically increase file size and this can pose constraints on linker operation when building an application or a new version of an operating system. If the linker has insufficient space to store the symbol tables while they are being corrected — they are often held in RAM for faster searching and update — the linker may crash with a symbol table overflow error. The solution is to strip out the symbol tables from some of the modules by recompiling them with symbolic debugging disa-bled or by allocating more storage space to the linker.

 

The problems may not stop there. If the module is then embedded into a target and symbolic debugging is required, the appropriate symbol tables must be included in the build and this takes up memory space. It is not uncommon for the symbol tables to take up more space than the spare system memory and prevent the system or task from being built or running correctly. The solution is to add more memory or strip out the symbol tables from some of the modules.

 

It is normal practice to remove all the symbol table information from the final build to save space. If this is done, it will also remove the ability to debug using the symbol informa-tion. It is a good idea to have at least a hard copy of the symbol table to help should any debugging be needed.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail
Embedded Systems Design : Emulation and debugging techniques : Symbolic debug |


Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.