Re: [Valgrind-developers] memcheck --track-origins=yes vs alloca/__chkstk

[John R. <jr...@Bi...>]

Julian Seward wrote:

>>What are the thoughts about implementing this desire for the error report
>>to identify the caller of alloca or __chkstk? ...

> The 1-element stack traces limitation exists because unwinding the stack
> in general is an expensive operation, and considered too expensive to
> be viable to do at every sub $N, %esp.  So instead a 1-element stack
> trace is made for those, which can obviously be done at JIT time since
> the only required info is the current instruction's address.  See
> mk_ecu_Expr in coregrind/m_translate.c.
> 
> Getting more would be a bit complex.  You'd have to change mk_ecu_Expr
> to generate IR that called a helper to do a depth-2 unwind, wrapped the
> result up into an ECU, and returned that to the generated code.

Thank you for explaining.  A traceback of length 2 _is_ too expensive.

However, recognizing the special case of __chkstk might work.  Under Wine,
the redirected code for __chkstk can be:
	neg %eax
	add %esp,%eax
	xchg %eax,%esp   ### The allocation.  Caller is (* %esp)
	mov (%eax),%eax  ### The return address.
	mov %eax,(%esp)
	ret
So the JIT translator of the allocator "xchg %eax,%esp" can verify the
context by looking for those rather-unique surrounding instructions, then
fetch the return address (* %esp) as the culprit, instead of using $pc.

--