Update.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13671 a5019735-40e9-0310-863c-91ae7b9d1cf9
mc_LOADVn_slow: also allow --partial-loads-ok=yes to grant an
exemption for aligned 32 bit loads on 64 bit targets, since it appears
to be necessary.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13672 a5019735-40e9-0310-863c-91ae7b9d1cf9
fix attribution of memcheck/tests/reach_thread_register.c code


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13673 a5019735-40e9-0310-863c-91ae7b9d1cf9
In an inner valgrind, register the interim stack earlier

The "late" registration of the interim stack is causing false
positive non addressable memcheck errors in x86.

Registering the interim stack earlier avoids these false positive.

Note however that this is just a bypass for the problem.

I believe there is a more fundamental problem in m_stacks.c stack handling:
In case a thread is switching of stack while the new stack is not yet
registered, the stack switching code will keep the old stack as current stack,
as the stack corresponding to the new sp cannot be found.
In such a case, the zone between the old and new SP in this unknown stack
can be marked either as addressable (if unknown stack is growing)
or unaddressable (if unknown stack is shrinking).
Then at some point in time, the new stack is registered.
If just after that, the sp is changed so as to grow the stack
by nr of bytes not determinable at translation time, VG_(unknown_SP_update)
will be called, will detect the stack switch and will do nothing.
This leaves a certain zone of the stack (the grown zone) in a not
addressable state, as the stack switch code has in fact wrongly
guessed a stack switch, while in fact what should have been detected
is just a sp change in a stack previously unknown.

Proper fixes might be: 
 1. in "IF_STACK_SWITCH_SET_current_stack_AND_RETURN", do not return
    if old and new sp are in the stack stack.
    rather continue so as to execute correctly the sp change in
    the newly discovered stack.
and/or
 2. in the stack registration code (client request), if the current SP
    is inside the stack being registered, also set the current stack
    to the just registered stack pointer

None of these fixes are being looked at currently, as such changes looks
too adventurous close to 3.9.0



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13674 a5019735-40e9-0310-863c-91ae7b9d1cf9