I’m working on a program that tries to walk up the stack after an interrupt, record information about the stack, and resume as if the interrupt never happened. Occasionally, unw_step fails, and, because we have some local expertise in x86-64 stack unwinding, we try to figure out how to complete the step ourselves. After the try, we’d like to use unw_set_reg to update the cursor with the new values we’ve determined and resume the use of libunwind.
The program under test - not the one I’m working on, but the one that we are analyzing with it - segfaults if I dare use unw_set_reg on the libunwind cursor, even though I never try to use unw_resume to use the cursor to affect the program. I can see that unw_step affects the cursor->loc member of the dwarf cursor, but does not go to the underlying context to change anything, while unw_get_reg and unw_set_reg do go to the context, so maybe I’ve looking for an accessible way to access/modify the loc fields of the dwarf cursor. However, the textbook example of writing a stack trace uses unw_step and unw_get_reg, so going to the underlying context must be okay(?). How does unw_get_reg get the value that unw_step has modified, when it seems to be looking past that to the underlying context? So, I’m confused about things. How can I expect unw_get_reg to work for stack unwinding, when unw_set_reg crashes the program? Help appreciated. Doug Moore _______________________________________________ Libunwind-devel mailing list Libunwind-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/libunwind-devel
