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

4.104.114.84.95
Last change on this file since fc766ef5 was fc766ef5, checked in by Joel Sherrill <joel.sherrill@…>, on 08/18/99 at 20:04:43

Added section on malloc reentrancy.

  • Property mode set to 100644
File size: 3.4 KB
Line 
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 Malloc
14
15@subsection Is malloc reentrant?
16
17Yes.  The RTEMS Malloc implementation is reentrant.  It is
18implemented as calls to the Region Manager in the Classic API.
19
20@subsection When is malloc initialized?
21
22During BSP initialization, the @code{bsp_libc_init} routine
23is called.  This routine initializes the heap as well as
24the RTEMS system call layer (open, read, write, etc.) and
25the RTEMS reentrancy support for the Cygnus newlib Standard C 
26Library.
27
28The @code{bsp_libc_init} routine is passed the size and starting
29address of the memory area to be used for the program heap as well
30as the amount of memory to ask @code{sbrk} for when the heap is
31exhausted.  For most BSPs, all memory available is placed in the
32program heap thus it can not be extended dynamically by calls to
33@code{sbrk}.
34
35@section How do I determine how much memory is left?
36
37First there are two types of memory: RTEMS Workspace and Program Heap.
38The RTEMS Workspace is the memory used by RTEMS to allocate control
39structures for system objects like tasks and semaphores, task
40stacks, and some system data structures like the ready chains.
41The Program Heap is where "malloc'ed" memory comes from.
42
43Both are essentially managed as heaps based on the Heap Manager
44in the RTEMS SuperCore.  The RTEMS Workspace uses the Heap Manager
45directly while the Program Heap is actually based on an RTEMS Region
46from the Classic API.  RTEMS Regions are in turn based on the Heap
47Manager in the SuperCore.
48
49@subsection How much memory is left in the RTEMS Workspace?
50
51An executive workspace overage can be fairly easily spotted with a
52debugger.  Look at _Workspace_Area.  If first == last, then there is only
53one free block of memory in the workspace (very likely if no task
54deletions).  Then do this:
55
56(gdb) p *(Heap_Block *)_Workspace_Area->first
57$3 = @{back_flag = 1, front_flag = 68552, next = 0x1e260, previous = 0x1e25c@}
58
59In this case, I had 68552 bytes left in the workspace.
60
61@subsection How much memory is left in the Heap?
62
63The C heap is a region so this should work:
64
65(gdb) p *((Region_Control *)_Region_Information->local_table[1])->Memory->first
66$9 = @{back_flag = 1, front_flag = 8058280, next = 0x7ea5b4,
67  previous = 0x7ea5b0@}
68
69In this case, the first block on the C Heap has 8,058,280 bytes left.
70
71@section How do I convert an executable to IEEE-695?
72
73This section is based on an email from Andrew Bythell
74<abythell@@nortelnetworks.com> in July 1999.
75
76Using Objcopy to convert m68k-coff to IEEE did not work.  The new IEEE
77object could not be read by tools like the XRay BDM Debugger. 
78
79The exact nature of this problem is beyond me, but I did narrow it down to a
80problem with objcopy in binutils 2-9.1.  To no surprise, others have
81discovered this problem as well, as it has been fixed in later releases.
82
83I compiled a snapshot of the development sources from 07/26/99 and
84everything now works as it should.  The development sources are at
85http://sourceware.cygnus.com/binutils  (thanks Ian!)
86
87Additional notes on converting an m68k-coff object for use with XRay (and
88others):
89
90@enumerate
91
92
93@item The m68k-coff object must be built with the -gstabs+ flag.  The -g flag
94alone didn't work for me. 
95
96@item Run Objcopy with the --debugging flag to copy debugging information.
97
98@end enumerate
99
100
Note: See TracBrowser for help on using the repository browser.