How to generate meaningfull stacktraces with RTEMS on the Leon3

Jiri Gaisler jiri at gaisler.se
Thu Dec 8 07:39:45 UTC 2016


Remember that on SPARC (leon3), parts of the stack will be cached in the
register file windows. Printing the backtrace by following the
stack/frame pointers will then not work unless all windows are first
flushed to memory. This is done automatically on high-level O/S (Linux &
Solaris), but not on embedded systems like RTEMS.

Jiri.

On 07/12/16 13:30, Matthew J Fletcher wrote:
> Hi,
>
> The gcc builtin functions (and libunwind) and only work if the stack
> frame information is not optimised away, this is controlled by gcc
> compiler flags,
> see; https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html -fomit-frame-pointer
>
> Without that you have to do your own unwinding, for example on x86 you
> could do the following, but its pretty crude. Linux/FreeBSD do much
> more fancy unwinders, it depends on what you want.
>
> #define get_ebp()       \
> ({ unsigned long  __value;   \
>    asm volatile (" mov %%ebp,%0": "=a"(__value));  \
>    __value; })
>
> void error_dump_callstack(int fd)
> {
> unsigned longebp=0,arg0,arg4,arg8,arg12,arg16;
> int i;
>
> arg0 = get_ebp(); // base pointer, start of current stack frame
>
> assert_out(fd,"\r\nCall Stack Information:\r\n\r\n");
> for (i=0; i<15; i++)
> {
> // attempt get backtrace (with arguments) from stored EPB
> arg0 = *(unsigned long*)(arg0);
>
> if (arg0 == 0)
> break;
>
> // print stackframe back past inturrupt
> arg0 = *(unsigned long*)(arg0);
> arg4 = *(unsigned long*)(arg0+4);
> arg8 = *(unsigned long*)(arg0+8);
> arg12 = *(unsigned long*)(arg0+12);
> arg16 = *(unsigned long*)(arg0+16);
> sprintf(assertbuffer,"ebp:     %p\r\nframe%d:  %p\r\narg1:  
>  %p\r\narg2:    %p\r\narg3:    %p\r\n",arg0,i,arg4,arg8,arg12,arg16);
> assert_out(fd,assertbuffer);
> }
> assert_out(fd,"use 'addr2line -C -e abc.elf -f address' to get symbol
> names\r\n");
> }
>
>
>
>
>
> On 6 December 2016 at 22:36, Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
>
>     On 06/12/2016 01:46, Jan Sommer wrote:
>
>         Is there a common way how to create stacktraces in RTEMS?
>
>
>     Not that I know of.
>
>         I tried to use the _Unwind_Backtrace_-function from gcc, but
>         so far it
>         only returns _URC_END_OF_STACK if I call it from a leaf function
>         (haven't tried a trap handler yet).
>
>
>     The end of stack code means the unwinder could not find any data
>     about the frames in the stack. The default DWARF unwinder, which
>     SPARC uses, searches for a valid Frame Description Entry (FDE) and
>     if not found reports the end of stack code. If an FDE is found the
>     Common Information Entry (CIE) is extracted from that data and the
>     frame info decoded.
>
>     C++ uses the same process for exceptions. A .eh_frame plus some
>     other sections are created and the frames effected by the
>     exceptions added to these sections. These sections are registered
>     at start up. For a DWARF unwinder, which includes the SPARC, the
>     DWARF standard is used for the format of these sections.
>
>         I am not sure if that is the way to go.
>
>
>     I am not 100% sure myself. I think you would need to include some
>     level of DWARF related information in the executable to do this.
>     This information would need to be registered with the DWARF
>     unwinder code via something like 'void __register_frame (void
>     *begin)'.
>
>     I would also take a look at FreeBSD and see how they implement the
>     unwinder. I do not know if the FreeBSD kernel has one.
>
>         Are there any recommendations or examples for this topic?
>
>
>     The DWARF standard website is the best source of info:
>
>     http://dwarfstd.org/
>
>     Chris
>
>     _______________________________________________
>     users mailing list
>     users at rtems.org <mailto:users at rtems.org>
>     http://lists.rtems.org/mailman/listinfo/users
>     <http://lists.rtems.org/mailman/listinfo/users>
>
>
>
>
> -- 
>
> regards
> ---
> Matthew J Fletcher
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20161208/09b327b9/attachment-0002.html>


More information about the users mailing list