[Valgrind-developers] "precise" tracking of call stack

[Jeremy F. <je...@go...>]

Well, I decided to look into my suggestion for maintaining the call
stack of by "simply" tracking pairs of call/ret instructions.   I've
decided it is either completely non-viable, or too complex to bother
with.

While a fine idea in theory, it relies on real code using call/return
and not playing too much with return address on the stack.  I had
thought the main violations of the call/return rule would be some or all
of:

/* A - PIC code - dealt with already in vg_to_ucode */
	call 1f
1:	popl %reg

/* B - common idiom */
	push code_addr
	ret

/* C - manual call */
	pop %reg
	push some_addr
	jmp *%reg

/* D - manual return */
	pop %reg
	jmp *%reg
	

Unfortunately I completely underestimated the twisty-turnyness of the
glibc dynamic linker, which basically does arbitrary stack manipulations
to manually build stack frames, manually call and manually return, and
also does delights such as:
	xchg	%eax, 8(%esp)
	ret	$8

In other words, to keep track of this stuff, Valgrind would have to keep
track of all stack accesses (optimistically accesses based off %esp;
pessimistically all memory accesses which happen to be in the area), and
maintain the call stack that way.  I don't think this is viable.

A possibly more viable, but complex, approach is to use a hybrid
technique: maintain a call stack, and also walk up the call frames using
esp/ebp.  If they agree, then all is well; if not, use the call stack to
resync the call frame walker, rather than using its information
directly.  I think that would take rather more effort than I was
prepared to get slightly more precision in a backtrace, so I'm not going
to explore it for now.

	J