[07b8f26] | 1 | @c |
---|
| 2 | @c COPYRIGHT (c) 1988-1998. |
---|
| 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 How do I determine how much memory is left? |
---|
| 14 | |
---|
| 15 | First there are two types of memory: RTEMS Workspace and Program Heap. |
---|
[4b57d272] | 16 | The RTEMS Workspace is the memory used by RTEMS to allocate control |
---|
| 17 | structures for system objects like tasks and semaphores, task |
---|
| 18 | stacks, and some system data structures like the ready chains. |
---|
| 19 | The Program Heap is where "malloc'ed" memory comes from. |
---|
| 20 | |
---|
[07b8f26] | 21 | Both are essentially managed as heaps based on the Heap Manager |
---|
| 22 | in the RTEMS SuperCore. The RTEMS Workspace uses the Heap Manager |
---|
| 23 | directly while the Program Heap is actually based on an RTEMS Region |
---|
| 24 | from the Classic API. RTEMS Regions are in turn based on the Heap |
---|
| 25 | Manager in the SuperCore. |
---|
| 26 | |
---|
| 27 | @subsection How much memory is left in the RTEMS Workspace? |
---|
| 28 | |
---|
| 29 | An executive workspace overage can be fairly easily spotted with a |
---|
| 30 | debugger. Look at _Workspace_Area. If first == last, then there is only |
---|
| 31 | one free block of memory in the workspace (very likely if no task |
---|
| 32 | deletions). Then do this: |
---|
| 33 | |
---|
| 34 | (gdb) p *(Heap_Block *)_Workspace_Area->first |
---|
[92ff266] | 35 | $3 = @{back_flag = 1, front_flag = 68552, next = 0x1e260, previous = 0x1e25c@} |
---|
[07b8f26] | 36 | |
---|
| 37 | In this case, I had 68552 bytes left in the workspace. |
---|
| 38 | |
---|
| 39 | @subsection How much memory is left in the Heap? |
---|
| 40 | |
---|
| 41 | The C heap is a region so this should work: |
---|
| 42 | |
---|
| 43 | (gdb) p *((Region_Control *)_Region_Information->local_table[1])->Memory->first |
---|
[92ff266] | 44 | $9 = @{back_flag = 1, front_flag = 8058280, next = 0x7ea5b4, |
---|
| 45 | previous = 0x7ea5b0@} |
---|
[07b8f26] | 46 | |
---|
| 47 | In this case, the first block on the C Heap has 8,058,280 bytes left. |
---|
| 48 | |
---|
[f28dfb36] | 49 | @section How do I convert an executable to IEEE-695? |
---|
| 50 | |
---|
| 51 | This section is based on an email from Andrew Bythell |
---|
| 52 | <abythell@@nortelnetworks.com> in July 1999. |
---|
| 53 | |
---|
| 54 | Using Objcopy to convert m68k-coff to IEEE did not work. The new IEEE |
---|
| 55 | object could not be read by tools like the XRay BDM Debugger. |
---|
| 56 | |
---|
| 57 | The exact nature of this problem is beyond me, but I did narrow it down to a |
---|
| 58 | problem with objcopy in binutils 2-9.1. To no surprise, others have |
---|
| 59 | discovered this problem as well, as it has been fixed in later releases. |
---|
| 60 | |
---|
| 61 | I compiled a snapshot of the development sources from 07/26/99 and |
---|
| 62 | everything now works as it should. The development sources are at |
---|
| 63 | http://sourceware.cygnus.com/binutils (thanks Ian!) |
---|
| 64 | |
---|
| 65 | Additional notes on converting an m68k-coff object for use with XRay (and |
---|
| 66 | others): |
---|
| 67 | |
---|
| 68 | @enumerate |
---|
| 69 | |
---|
| 70 | |
---|
| 71 | @item The m68k-coff object must be built with the -gstabs+ flag. The -g flag |
---|
| 72 | alone didn't work for me. |
---|
| 73 | |
---|
| 74 | @item Run Objcopy with the --debugging flag to copy debugging information. |
---|
| 75 | |
---|
| 76 | @end enumerate |
---|
| 77 | |
---|
[70b8f3ed] | 78 | |
---|