Re: [Valgrind-users] not understanding some valgrind errors against afs...

[Sebastian K. <sk@z.pl>]

Hello!

Dnia wto 15. kwiecie=F1 2003 22:50, Robert Walsh napisa=B3:
> JeremyF and I had a chat about this over lunch a few weeks ago.  One
> idea floated was to check what the instruction that was ultimately
> responsible for the stack switch was.  If it was a move to sp type
> instruction, it's probably a stack switch.  Otherwise it's probably a
> push or a pop.  JeremyF did mention a few days ago that he was trying
> something new but was running into problems - maybe this was what he wa=
s
> trying but it wasn't turning out to be that easy... :-)

How about following approach (rough idea):
Checking wether value loaded into ESP fits within some memory block alloc=
ated=20
by malloc call (V is keeping track of those blocks anyway). If ESP skips =
from=20
one such block into another, this is probably stack switch. Now we only h=
ave=20
to remember, that initial stack is not mallocated and handle that=20
apropriately (remembering where initial, primary stack was when EPS skips=
 out=20
into some mallocated block).
This surely wouldn't work for multiple stacks residing in the same malloc=
ated=20
block, but then maybe V could use some combined approach (or even user=20
configurable combination of detecting ESP change amount, if it's caused b=
y=20
MOV, not ADD/SUB/etc... and the above proposed method, and maybe somethin=
g=20
else).

Also allowing code instrumentation is not bad idea. Also it might be desi=
rable=20
to allow user supply the address of stack switching instruction from comm=
and=20
line -- there are probably very few places in the whole code where stack=20
switch itself is actually performed, and this would allow to use library =
one=20
has no sources for (or one does not want to recompile).

Just rough ideas, but maybe useful...

rgds
Sebastian Kaliszewski
sk@z.pl