Sorry for the slow reply on this, I'm going to try and get a v3 out sometime after next week.
On Wed, Sep 17, 2025 at 4:41 PM Josh Poimboeuf <[email protected]> wrote: > > As far I can tell, the *only* error condition being checked is if it > (successfully) fell back to frame pointers. By checking/handling error conditions, do you mean just marking the state as unreliable in any case where the unwind isn't successful with SFrame? I'm thinking if I can make the unwind_next_frame_sframe() code path handle the end of the stack correctly on its own, I can more strictly mark the trace as unreliable if it encounters any error. > > What if there was some bad or missing sframe data? Or some unexpected > condition on the stack? > > Also, does the exception handling code have correct cfi/sframe metadata? > > In order for it to be "reliable", we need to know the unwind reached the > end of the stack (e.g., the task pt_regs frame, from entry-from-user). It looks like the frame-pointer based method of handling the end of the stack involves calling kunwind_next_frame_record_meta() to extract and check frame_record_meta::type for FRAME_META_TYPE_FINAL. I think this currently assumes (based on the definition of 'struct frame_record') that the next FP and PC are right next to each other, alongside the meta type. But the sframe format stores separate entries for the FP and RA offsets, which makes extracting the meta type from this information a little bit murky to me. Would it make sense to fall back to the frame pointer method for the final stack frame? Or I guess I could define a new sframe-friendly meta frame record format? Thanks, Dylan
