From: Josef W. <Jos...@in...> - 2003-04-17 13:37:43
|
On Thursday 17 April 2003 10:31, Jeremy Fitzhardinge wrote: > ... > I think the correct solution is to move stack switch detection into the > skin themselves (memcheck, addrcheck and helgrind are the only ones I know > of which care). Memcheck and addrcheck can use their existing validity > info to make the determination; helgrind is harder. Calltree does ESP tracking, too. Needed for recursion detection and correct handling of setjmp/longjmp or C++ exceptions and like that. So I'm voting for a skin trackable event for stack switching from the core. Isn't this almost the same as the "switch_thread" event? As I see, the first stack switch always has quite a large delta. If we remember the instruction address somehow and assume further stack switches if the same instruction is executed (breaking up a BB into two at this point). [This is new in the resend to Valgrind-users] Another idea: Doesn't the kernel need to know about stack segments somehow by declaring the VMA as growable? So isn't it enough to check for ESP changes among growable VMAs? Or how behaves the LWP lib of AFS on stack overflows? If it uses mprotect() for manual stack growing, we can track this, too. Josef |