red-rocket-computing / backtrace Goto Github PK

I have a project using a Microchip SAM4E. I experience a crash via memory access violation when the the line at 165 in backtrace.c tries to de-reference an out of range location. In this case 0xa5a5a5a5. This is while testing this library calling backtrace_unwind in main(). If I add a new if statement in _backtrace_unwind as so, to catch:
'''
if (frame->fp == 0xa5a5a5a5 || frame->fp == 0x00000000)
// end of stack
'''
This prevents the future crash further on at line 165
Then all seems to work. My question then, is this compatible with ARM m-4, and is this the correct way to detect if then end of stack has been reached?

EDIT: Essentially, if the frame pointer going into the unwind functions is NULL or out of memory range, in this case 0xa5a5a5a5, then later on in the unwind_execute_instruction() function, when vsp is de-referenced, the crash or memory fault triggers.

The functions __aeabi_unwind_cpp_pr0 etc in backtrace.c have a comment saying they prevent the linking of the same functions in libgcc, but I just get errors about that:

/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/thumb/v7e-m/fpv4-sp/hard/libgcc.a(unwind-arm.o): In function `__aeabi_unwind_cpp_pr0':
unwind-arm.c:(.text+0x760): multiple definition of `__aeabi_unwind_cpp_pr0'
build/backtrace_backtrace.c.o:backtrace.c:(.text.__aeabi_unwind_cpp_pr0+0x0): first defined here
collect2: error: ld returned 1 exit status

In file backtrace.c, there's a small bug I think at line 127. The lines says

ucb->vrs[13] -= ((instruction & 0x3f) << 2) - 4;

while that should be

ucb->vrs[13] -= ((instruction & 0x3f) << 2) + 4;

Kind regards,

Steven

Hello,

I wanted to ask why you don't use the function _Unwind_Backtrace defined in unwind-arm-common.h.
This function works very similar to this implementation and works on an STM32F4.

Another question:
After throwing an exception, which calls std::terminate, I cannot get a complete backtrace (neither with your implementation or with _Unwind_Backtrace).
Doing the exact same thing on a linux system, everything works fine. Do you know anything about this limitation?

I've been trying to get this lib working on Cortex-M33 as an alternative to _Unwind_Backtrace which doesn't return anything. This lib works slightly better, but it's only returning one level in the backtrace

00> Backtrace, 1 steps
00>    Addr: 0x800EF58

which points to backtrace.h:75 in my case:

	/* Let it rip */
	return _backtrace_unwind(buffer, size, &frame);

I have enabled the compile flags specified in the README. Is there anything else I should watch out for? (trying to debug but gdb-server shuts itself down when hitting a breakpoint).

arm-none-eabi-gcc (15:10.3-2021.07-4) 10.3.1 20210621 (release)

While handling that case, after the while loop, which stops when the mask is 0, the mask is by definition 0, and the writeback to the virtual stackpointer fails. Check the mask for 1 << (13 -4) before entering the while loop.

I have an application where I want to extract traces on crashes, but I already have a backtrace data structure on the application layer. With the current way backtrace works I'd have to allocate a second set of array, populate it and then copy it to my application's structure.

I'm thinking about extending the library so it works similarly to _Unwind_Backtrace where you provide a callback that handles the copying (on a frame by frame basis) and decides when to stop. Essentially, in addition to the current API:

int backtrace_unwind_from_frame(backtrace_t *buffer, int size, backtrace_frame_t frame);
int backtrace_unwind(backtrace_t *buffer, int size)

two new functions would be introduced:

enum
{
	UNWIND_CONTINUE,
	UNWIND_STOP
} unwind_code_t

typedef unwind_code_t *unwind_trace_fn(backtrace *trace, void *context);
int backtrace_unwind_from_frame(unwind_trace_fn callback, backtrace_frame_t frame);
int backtrace_unwind(unwind_trace_fn callback)

Is that something you'd need/want upstream? If so I can do it on Github and make a proper PR.