Re: [Valgrind-developers] valgrind and thread-local storage

[Konstantin S. <kon...@gm...>]

On Tue, Mar 31, 2009 at 3:16 PM, Bart Van Assche
<bar...@gm...> wrote:
> On Tue, Mar 31, 2009 at 12:08 PM, Konstantin Serebryany
> <kon...@gm...> wrote:
>> There are at least two ways to fix this:
>> - somehow recognize this h-b dependency introduced by libpthread
>> - clear the state of stack/tls memory.
>>
>> Second way is preferable since it will not hide real races...
>
> When the Valgrind core notifies a tool that a thread exits the stack
> pointer of that thread is still below the top of the stack because of
> the area reserved by the NPTL. In the DRD tool the state of the
> top-of-stack area is cleared explicitly when a thread exits. The
> following code in DRD's pre_thread_ll_exit handler performs this task:
>
>   drd_stop_using_mem(DRD_(thread_get_stack_min)(drd_tid),
>                      DRD_(thread_get_stack_max)(drd_tid)
>                      - DRD_(thread_get_stack_min)(drd_tid),
>                      True);

I tried the same thing. It helps sometimes, but not always.

I see that the stack provided to clone() syscall is not the same as
returned by VG_(thread_get_stack_max)
(grr, hard to get a small reproducer)

SYSCALL[1799,6]( 56) sys_clone ( 3d0f00, 0xf8cf240,
[stack_max=]0xf8d09f0, 0xf8d09f0, [tls=]0xf8d0960 ) --> [pre-success]
Success(0x71c)
VG_(thread_get_stack_max)=0xF8D0000
VG_(threads)[tid].arch.vex.guest_FS_ZERO=0xF8D0960 (this is tls)

As you can see, the 3-rd parameter of sys_clone() is a bit different
from what VG_(thread_get_stack_max) returns.
Why?
Is there any way for a tool to get the 3-rd parameter of sys_clone?


On amd64-linux I can get the tls from
VG_(threads)[tid].arch.vex.guest_FS_ZERO, but that's too hackish.


Thanks,
--kcc




>
> Bart.
>