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.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.