ftmemsim-valgrind/reach_thread_register.stderr.exp-mips64 at 4247ea70e0ea51e1ab2bfcc7f0a6d2e26ce5de6a - ftmemsim-valgrind - Gitea: Git with a cup of tea

zenithsiz/ftmemsim-valgrind

mirror of https://github.com/Zenithsiz/ftmemsim-valgrind.git synced 2026-02-03 10:05:29 +00:00

Dejan Jevtic 4247ea70e0 mips32/64: Add extra suppression for mips32/64.

After the thread is detached not all thread memory is freed. This memory (dtv-dynamic thread vector)
can be used by the main thread. There are two types of run-time handling of TLS.
Difference is in the position of memory. It can be either before the thread pointer or
after the thread pointer.
Taken form the document http://www.akkadia.org/drepper/tls.pdf:
"Variant I for the thread-local storage data structures were developed
as part of the IA-64 ABI. Being brand-new, compatibility was no issue. The thread
register for thread t is denoted by tpt. It points to a Thread Control Block (TCB) which
contains at offset zero a pointer to the dynamic thread vector dtvt for the thread.

Variant II has a similar structure. The only difference is that the thread pointer
points to a Thread Control Block of unspecified size and content. Somewhere the TCB
contains a pointer to the dynamic thread vector but it is not specified where. This is
under control of the run-time environment and the pointer must not be assumed to be
directly accessible; compilers are not allowed to emit code which directly access the
dtvt."

Because of this we have two types of error when the program ends:
possibly lost, and definitely lost.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13761

2013-12-16 13:57:18 +00:00

7 lines

202 B

Plaintext

Raw Blame History

 Abandoning the helper.
 bytes in 1 blocks are definitely lost in loss record ... of ...
    at 0x........: calloc (vg_replace_malloc.c:...)
    ...
    by 0x........: main (reach_thread_register.c:47)