Hello All, Special thanks to Arun for all the help.
I incorrectly assumed that unw_init_local makes a cursor out of the passed context and returns it in the output buffer. But I see that modifying the registers in the cursor (using unw_set_reg) results in the context being modified too. Is this the expected behavior? If not, why and under what circumstances can this happen? Or is it that the context and the generated local cursor is essentially the same memory? I am asking this because in our codebase we provide a const guarantee for the passed context but I have to cast it away to get unw_init_local to work in the face of bad IP (the original post). For now, as a workaround, I created a container to hold a copy of the passed context and use this copy instead. I will fire up gdb and dig into libunwind codebase when I get the chance but am hoping someone will provide me with the answer quicker. All help highly appreciated. Regards, Prabhat -----Original Message----- From: Prabhat Verma Sent: Thursday, April 05, 2012 5:24 PM To: 'Arun Sharma' Cc: [email protected] Subject: RE: [Libunwind-devel] Libunwind support for NULL IP Great suggestion and it works like a charm! Inside my SEGV handler: ucontext_t* temp_uc = reinterpret_cast<ucontext_t *> (<the context passed by the OS>); size_t rsp(*reinterpret_cast<size_t *> (temp_uc->uc_mcontext.gregs[REG_RSP])); check if rsp is valid and if it is, let libunwind do the heavy lifting... On a side note, you may disagree, but IMO there is value in moving this inside of libunwind. Many uses still rely on function pointers for state -machines and this will be a useful capability when things go wild.... Thanks a ton Arun and apologies for the trouble :) Regards, Prabhat -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Arun Sharma Sent: Thursday, April 05, 2012 12:04 PM To: Prabhat Verma Cc: [email protected] Subject: Re: [Libunwind-devel] Libunwind support for NULL IP On Wed, Apr 4, 2012 at 8:45 PM, Arun Sharma <[email protected]> wrote: > If you want all of this to work without -fno-omit-frame-pointer, > things become a bit more complicated. We'll somehow have to > (heuristically?) unwind up to the point where IP is valid. libunwind > knows what to do after that. Here's one way to make it work: In the signal handler, you can compare the faulting address to %rip and infer that this was a SIGSEGV caused by a bad function pointer. Then you can special case this (i.e. unwind the inner most frame "manually" -- by changing %rip in the ucontext to the return address pointed to by %rsp). libunwind should be able to do the rest of the work for you. Why not have this code inside of libunwind? The interfaces do so would be icky and this is best done in the signal handler, rather than another library. -Arun _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
