1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-2002. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | @c |
---|
6 | @c $Id$ |
---|
7 | @c |
---|
8 | |
---|
9 | @chapter Debugging Hints |
---|
10 | |
---|
11 | The questions in this category are hints that can ease debugging. |
---|
12 | |
---|
13 | @section Executable Size |
---|
14 | |
---|
15 | @subsection Why is my executable so big? |
---|
16 | |
---|
17 | There are two primary causes for this. The most common is that |
---|
18 | you are doing an @code{ls -l} and looking at the actual file |
---|
19 | size -- not the size of the code in the target image. This |
---|
20 | file could be in an object format such as ELF or COFF and |
---|
21 | contain debug information. If this is the case, it could |
---|
22 | be an order of magnitude larger than the required code space. |
---|
23 | Use the strip command in your cross toolset to remove debugging |
---|
24 | information. |
---|
25 | |
---|
26 | The following example was done using the i386-rtems cross toolset |
---|
27 | and the pc386 BSP. Notice that with symbolic information included |
---|
28 | the file @code{hello.exe} is almost a megabyte and would barely fit |
---|
29 | on a boot floppy. But there is actually only about 93K of code |
---|
30 | and initialized data. The other 800K is symbolic information |
---|
31 | which is not required to execute the application. |
---|
32 | |
---|
33 | @example |
---|
34 | $ ls -l hello.exe |
---|
35 | -rwxrwxr-x 1 joel users 930515 May 2 09:50 hello.exe |
---|
36 | $ i386-rtems-size hello.exe |
---|
37 | text data bss dec hex filename |
---|
38 | 88605 3591 11980 104176 196f0 hello.exe |
---|
39 | $ i386-rtems-strip hello.exe |
---|
40 | $ ls -l hello.exe |
---|
41 | -rwxrwxr-x 1 joel users 106732 May 2 10:02 hello.exe |
---|
42 | $ i386-rtems-size hello.exe |
---|
43 | text data bss dec hex filename |
---|
44 | 88605 3591 11980 104176 196f0 hello.exe |
---|
45 | @end example |
---|
46 | |
---|
47 | Another alternative is that the executable file is in an ASCII |
---|
48 | format such as Motorola Srecords. In this case, there is |
---|
49 | no debug information in the file but each byte in the target |
---|
50 | image requires two bytes to represent. On top of that, there |
---|
51 | is some overhead required to specify the addresses where the image |
---|
52 | is to be placed in target memory as well as checksum information. |
---|
53 | In this case, it is not uncommon to see executable files |
---|
54 | that are between two and three times larger than the actual |
---|
55 | space required in target memory. |
---|
56 | |
---|
57 | Remember, the debugging information is required to do symbolic |
---|
58 | debugging with gdb. Normally gdb obtains its symbolic information |
---|
59 | from the same file that it gets the executable image from. However, |
---|
60 | gdb does not require that the executable image and symbolic |
---|
61 | information be obtained from the same file. So you might |
---|
62 | want to create a @code{hello_with_symbols.exe}, copy that |
---|
63 | file to @code{hello_without_symbols.exe}, and strip |
---|
64 | @code{hello_without_symbols.exe}. Then gdb would have to |
---|
65 | be told to read symbol information from @code{hello_with_symbols.exe}. |
---|
66 | The gdb command line option @code{-symbols} or command |
---|
67 | @code{symbol-file} may be used to specify the file read |
---|
68 | for symbolic information. |
---|
69 | |
---|
70 | |
---|
71 | @section Malloc |
---|
72 | |
---|
73 | @subsection Is malloc reentrant? |
---|
74 | |
---|
75 | Yes. The RTEMS Malloc implementation is reentrant. It is |
---|
76 | implemented as calls to the Region Manager in the Classic API. |
---|
77 | |
---|
78 | @subsection When is malloc initialized? |
---|
79 | |
---|
80 | During BSP initialization, the @code{bsp_libc_init} routine |
---|
81 | is called. This routine initializes the heap as well as |
---|
82 | the RTEMS system call layer (open, read, write, etc.) and |
---|
83 | the RTEMS reentrancy support for the Cygnus newlib Standard C |
---|
84 | Library. |
---|
85 | |
---|
86 | The @code{bsp_libc_init} routine is passed the size and starting |
---|
87 | address of the memory area to be used for the program heap as well |
---|
88 | as the amount of memory to ask @code{sbrk} for when the heap is |
---|
89 | exhausted. For most BSPs, all memory available is placed in the |
---|
90 | program heap thus it can not be extended dynamically by calls to |
---|
91 | @code{sbrk}. |
---|
92 | |
---|
93 | @section How do I determine how much memory is left? |
---|
94 | |
---|
95 | First there are two types of memory: RTEMS Workspace and Program Heap. |
---|
96 | The RTEMS Workspace is the memory used by RTEMS to allocate control |
---|
97 | structures for system objects like tasks and semaphores, task |
---|
98 | stacks, and some system data structures like the ready chains. |
---|
99 | The Program Heap is where "malloc'ed" memory comes from. |
---|
100 | |
---|
101 | Both are essentially managed as heaps based on the Heap Manager |
---|
102 | in the RTEMS SuperCore. The RTEMS Workspace uses the Heap Manager |
---|
103 | directly while the Program Heap is actually based on an RTEMS Region |
---|
104 | from the Classic API. RTEMS Regions are in turn based on the Heap |
---|
105 | Manager in the SuperCore. |
---|
106 | |
---|
107 | @subsection How much memory is left in the RTEMS Workspace? |
---|
108 | |
---|
109 | An executive workspace overage can be fairly easily spotted with a |
---|
110 | debugger. Look at _Workspace_Area. If first == last, then there is only |
---|
111 | one free block of memory in the workspace (very likely if no task |
---|
112 | deletions). Then do this: |
---|
113 | |
---|
114 | (gdb) p *(Heap_Block *)_Workspace_Area->first |
---|
115 | $3 = @{back_flag = 1, front_flag = 68552, next = 0x1e260, previous = 0x1e25c@} |
---|
116 | |
---|
117 | In this case, I had 68552 bytes left in the workspace. |
---|
118 | |
---|
119 | @subsection How much memory is left in the Heap? |
---|
120 | |
---|
121 | The C heap is a region so this should work: |
---|
122 | |
---|
123 | (gdb) p *((Region_Control *)_Region_Information->local_table[1])->Memory->first |
---|
124 | $9 = @{back_flag = 1, front_flag = 8058280, next = 0x7ea5b4, |
---|
125 | previous = 0x7ea5b0@} |
---|
126 | |
---|
127 | In this case, the first block on the C Heap has 8,058,280 bytes left. |
---|
128 | |
---|
129 | @section How do I convert an executable to IEEE-695? |
---|
130 | |
---|
131 | This section is based on an email from Andrew Bythell |
---|
132 | <abythell@@nortelnetworks.com> in July 1999. |
---|
133 | |
---|
134 | Using Objcopy to convert m68k-coff to IEEE did not work. The new IEEE |
---|
135 | object could not be read by tools like the XRay BDM Debugger. |
---|
136 | |
---|
137 | The exact nature of this problem is beyond me, but I did narrow it down to a |
---|
138 | problem with objcopy in binutils 2-9.1. To no surprise, others have |
---|
139 | discovered this problem as well, as it has been fixed in later releases. |
---|
140 | |
---|
141 | I compiled a snapshot of the development sources from 07/26/99 and |
---|
142 | everything now works as it should. The development sources are at |
---|
143 | @uref{http://sourceware.cygnus.com/binutils} (thanks Ian!) |
---|
144 | |
---|
145 | Additional notes on converting an m68k-coff object for use with XRay (and |
---|
146 | others): |
---|
147 | |
---|
148 | @enumerate |
---|
149 | |
---|
150 | |
---|
151 | @item The m68k-coff object must be built with the -gstabs+ flag. The -g flag |
---|
152 | alone didn't work for me. |
---|
153 | |
---|
154 | @item Run Objcopy with the --debugging flag to copy debugging information. |
---|
155 | |
---|
156 | @end enumerate |
---|
157 | |
---|
158 | |
---|