Stack frame help.

Till Straumann strauman at slac.stanford.edu
Mon Feb 9 20:14:43 UTC 2009


Nick Thomas wrote:
> Hi, this is probably a basic error on my part, but,
>
> The bottom few lines of my .num file show where the heap and stack are at:
>
> 00ce7078 B global_shell_env
> 00ce7098 B rtems_global_user_env
> 00ce70d8 B rtems_filesystem_mount_table_control
> 00ce70e4 B _POSIX_signals_Vectors
> 00ce7264 B _POSIX_signals_Inactive_siginfo
> 00ce7270 B _POSIX_signals_Wait_queue
> 00ce72b0 B _POSIX_signals_Siginfo
> 00ce7430 A __SBSS_END__
> 00ce7430 B _end
> 00ce7430 B bss.end
> 00ee7430 A _heap_end
> 00ee7430 A heap.end
> 00fa7430 A stack.end
>
>
> Now, my program is crashing, and the stack frame is like this:
>
> (gdb) info frame
> Stack level 0, frame at 0xf8d258:
>  Pc = 0x3c8f20 in timer_task
>  (C:\blah\blah..)
> Saved pc = 0x2e38e0
>  Called by frame at 0xf8d2c0
>  Source language c.
>  Arglist at 0xf8d230, args: argc=0 argv=0x0
>  Locals at 0xf8d230, Previous frame's sp is 0xf8d258
>  Saved registers:
>  R31 at 0xf8d254, pc at 0xf8d25c, lr at 0xf8d25c
> (gdb)
>
>
> Am I right in thinking that the stack has grown into the heap area? 
Doesn't look so. The innermost stack frame is at 0xf8d258
which is still well above the top of the heap (0xee7430)
(if 'heap.end' really is the end of the heap).

HTH
T.

> Or is
> timer_task's stack actually located in the heap area?
>
> Please help me to clear the fog!
>
> Looking forward to your responses.
>
> Regards
>
> Nick
>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   




More information about the users mailing list