summaryrefslogtreecommitdiffstats
path: root/doc/FAQ/debug.t
blob: 9c7e9a8ce02b60956f12603723c3e094e582f604 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
@c
@c  COPYRIGHT (c) 1988-1998.
@c  On-Line Applications Research Corporation (OAR).
@c  All rights reserved.
@c
@c  $Id$
@c

@chapter Debugging Hints

The questions in this category are hints that can ease debugging.

@section Malloc

@subsection Is malloc reentrant?

Yes.  The RTEMS Malloc implementation is reentrant.  It is
implemented as calls to the Region Manager in the Classic API.

@subsection When is malloc initialized?

During BSP initialization, the @code{bsp_libc_init} routine
is called.  This routine initializes the heap as well as
the RTEMS system call layer (open, read, write, etc.) and
the RTEMS reentrancy support for the Cygnus newlib Standard C  
Library.

The @code{bsp_libc_init} routine is passed the size and starting
address of the memory area to be used for the program heap as well
as the amount of memory to ask @code{sbrk} for when the heap is
exhausted.  For most BSPs, all memory available is placed in the
program heap thus it can not be extended dynamically by calls to
@code{sbrk}.

@section How do I determine how much memory is left?

First there are two types of memory: RTEMS Workspace and Program Heap.
The RTEMS Workspace is the memory used by RTEMS to allocate control
structures for system objects like tasks and semaphores, task 
stacks, and some system data structures like the ready chains.
The Program Heap is where "malloc'ed" memory comes from.

Both are essentially managed as heaps based on the Heap Manager
in the RTEMS SuperCore.  The RTEMS Workspace uses the Heap Manager
directly while the Program Heap is actually based on an RTEMS Region 
from the Classic API.  RTEMS Regions are in turn based on the Heap
Manager in the SuperCore.

@subsection How much memory is left in the RTEMS Workspace?

An executive workspace overage can be fairly easily spotted with a
debugger.  Look at _Workspace_Area.  If first == last, then there is only
one free block of memory in the workspace (very likely if no task
deletions).  Then do this:

(gdb) p *(Heap_Block *)_Workspace_Area->first
$3 = @{back_flag = 1, front_flag = 68552, next = 0x1e260, previous = 0x1e25c@}

In this case, I had 68552 bytes left in the workspace.

@subsection How much memory is left in the Heap?

The C heap is a region so this should work:

(gdb) p *((Region_Control *)_Region_Information->local_table[1])->Memory->first
$9 = @{back_flag = 1, front_flag = 8058280, next = 0x7ea5b4,
  previous = 0x7ea5b0@}

In this case, the first block on the C Heap has 8,058,280 bytes left.

@section How do I convert an executable to IEEE-695?

This section is based on an email from Andrew Bythell
<abythell@@nortelnetworks.com> in July 1999.

Using Objcopy to convert m68k-coff to IEEE did not work.  The new IEEE
object could not be read by tools like the XRay BDM Debugger.  

The exact nature of this problem is beyond me, but I did narrow it down to a
problem with objcopy in binutils 2-9.1.  To no surprise, others have
discovered this problem as well, as it has been fixed in later releases.

I compiled a snapshot of the development sources from 07/26/99 and
everything now works as it should.  The development sources are at
http://sourceware.cygnus.com/binutils  (thanks Ian!)

Additional notes on converting an m68k-coff object for use with XRay (and
others):

@enumerate


@item The m68k-coff object must be built with the -gstabs+ flag.  The -g flag
alone didn't work for me.  

@item Run Objcopy with the --debugging flag to copy debugging information. 

@end enumerate