You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 30, 2024. It is now read-only.
// If the frame didn't move, and the program counter didn't change, bail out
// (otherwise we might print the same frame over and over).
if !cfa_changed && !program_counter_changed {
// If we do not end up in the reset function the stack is corrupted
output.corrupted = !reset_range.contains(&pc);
break;
}
this is not due to this PR but I wouldn't necessarily categorize this exit condition as "corrupted". if you compile the rust program with -C force-frame-pointers=off then it's not possible to unwind the stack because frame pointer information is missing (from register r7) so you'll hit this branch but the call stack and the program will both operate fine.
-C force-frame-pointers=off is not very common but the assembly trampolines used to implement context switches in RTOSes / kernels could have the same effect of making unwinding not work.
I think it would be more to correct to simply say in this branch that it's "not possible to further unwind the stack" or something like that
The text was updated successfully, but these errors were encountered:
This came up in the review of #383:
probe-run/src/backtrace/unwind.rs
Lines 104 to 110 in b83bb96
The text was updated successfully, but these errors were encountered: