source: rtems/doc/FAQ/debug.t @ e112b63

4.104.114.84.95
Last change on this file since e112b63 was f28dfb36, checked in by Joel Sherrill <joel.sherrill@…>, on Jul 28, 1999 at 5:29:54 PM

Added information on using objcopy to produce IEEE-695 format.

  • Property mode set to 100644
File size: 2.6 KB
RevLine 
[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
11The questions in this category are hints that can ease debugging.
12
13@section How do I determine how much memory is left?
14
15First there are two types of memory: RTEMS Workspace and Program Heap.
[4b57d272]16The RTEMS Workspace is the memory used by RTEMS to allocate control
17structures for system objects like tasks and semaphores, task
18stacks, and some system data structures like the ready chains.
19The Program Heap is where "malloc'ed" memory comes from.
20
[07b8f26]21Both are essentially managed as heaps based on the Heap Manager
22in the RTEMS SuperCore.  The RTEMS Workspace uses the Heap Manager
23directly while the Program Heap is actually based on an RTEMS Region
24from the Classic API.  RTEMS Regions are in turn based on the Heap
25Manager in the SuperCore.
26
27@subsection How much memory is left in the RTEMS Workspace?
28
29An executive workspace overage can be fairly easily spotted with a
30debugger.  Look at _Workspace_Area.  If first == last, then there is only
31one free block of memory in the workspace (very likely if no task
32deletions).  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
37In this case, I had 68552 bytes left in the workspace.
38
39@subsection How much memory is left in the Heap?
40
41The 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
47In 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
51This section is based on an email from Andrew Bythell
52<abythell@@nortelnetworks.com> in July 1999.
53
54Using Objcopy to convert m68k-coff to IEEE did not work.  The new IEEE
55object could not be read by tools like the XRay BDM Debugger. 
56
57The exact nature of this problem is beyond me, but I did narrow it down to a
58problem with objcopy in binutils 2-9.1.  To no surprise, others have
59discovered this problem as well, as it has been fixed in later releases.
60
61I compiled a snapshot of the development sources from 07/26/99 and
62everything now works as it should.  The development sources are at
63http://sourceware.cygnus.com/binutils  (thanks Ian!)
64
65Additional notes on converting an m68k-coff object for use with XRay (and
66others):
67
68@enumerate
69
70
71@item The m68k-coff object must be built with the -gstabs+ flag.  The -g flag
72alone 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
Note: See TracBrowser for help on using the repository browser.