Lines Matching full:stack
20 > complicated things to get it right, eg. unwinding the stack. How robust
30 I have a shadow call stack for every thread. For signal handlers of a thread,
31 I first PUSH a separation marker on the shadow stack, and use the stack as
45 - do unwinding if needed (i.e, POPs of the shadow call stack)
47 - if our call stack is empty, simulate a CALL lasting from beginning
55 BB on shadow call stack.
114 > - have a shadow call stack for every thread
123 changes with %esp > stored esp on shadow stack.
139 the stack, a normal jump will rarely jump to the first BB of a function,
142 > - Unwind the shadow call stack if necessary.
143 > [when is "necessary"? If the real %esp > the shadow stack %esp?]
149 > - If this is a function return and there was no shadow stack unwinding,
151 > linker). Pop the shadow call stack, setting the previous BB address to
158 function) at least one entry of the shadow call stack. But this doesn't need
160 one on the shadow stack. E.g. suppose
166 stack frame at all.
173 > from previous BB to current BB on shadow call stack.
176 I meant: Append a struct call_entry to the shadow stack (together with the
177 current %esp value). As I said before, the shadow stack is used for robust
186 > thread's shadow stack, then use it as normal. The marker is used for
196 > What about stack switching -- does it cope with that? (Not that Valgrind
201 IMHO is: How to distinguish among a stack switch and allocating a huge array
202 on the stack?
