Incomplete backtraces

Mohammed Khoory mkhoory at
Mon Nov 18 03:10:09 UTC 2013

Thanks for the information. I've recompiled RTEMS with CFLAGS_FOR_BUILD and
CFLAGS_FOR_TARGET set to the following:
-mhard-float -O0 -g -fno-omit-frame-pointer

The problem is still there however.

I also forgot to mention that when I ask gdb for a backtrace, I get the
following message at the end

#0  rtems_rfs_buffer_open (name=0x400e6e08 "/dev/rda", fs=0x40136d60) at
#1  0x400c2d64 in rtems_rfs_format (name=0x1 "\200\004\b\001", config=0x1)
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

This example is when I try to format a RAMDisk. Notice how there's nothing
beneath #1, even though I called it from a function in my application, which
was called from another function, etc.

>-----Original Message-----
>From: rtems-users-bounces at [mailto:rtems-users-
>bounces at] On Behalf Of Stephen Tether
>Sent: Sunday, November 17, 2013 5:53 PM
>To: rtems-users at
>Subject: Re: Incomplete backtraces
>On 11/14/13 8:56 PM, Mohammed Khoory wrote:
>> For example, if Init() calls function1(), which calls function2(),
>> which calls function3(), and a breakpoint is placed in function3(),
>> then when the debugger pauses the program the stack trace only shows
>> function3() and function2(), and nothing under that.
>I'm not familiar with the SPARC but it sounds as if you need to read the
>description of the GCC option -fomit-frame-pointers. Frame pointers are
>to chain call stacks together but some forms of optimization prevent them
>from being used. For example they're often omitted in functions that call
>other functions, so-called "leaf" functions.
>Alas, omitting frame pointers can make complete backtrace listings
>impossible. You can try using -fno-omit-frame-pointers after specifying the
>optimization level.
>- Steve Tether
>rtems-users mailing list
>rtems-users at

More information about the users mailing list