Make aligned_alloc behave more like the underlying platform aligned_alloc

This is the third part of
Bug 466104 aligned_alloc problems, part 1

Shouldn't affect Linux glibc.

Bug 449309 -  Missing loopback device ioctl(s)

Patch provided by:
    Faheem Sheikh <faheem.sheikh@bmw.de>

Note that the testcase provided with this report hasn't
been added as it requires privileges.

Linux PPC regtest: forgot to add the new expected

Linux PPC regtest: add a specific expected for memalign_args

The number of errors for arguments that gets triggered depends
on how GCC optimzes and generates code for the vg_replace_malloc.c
wrappers. PPC seems to trigger more than amd64.

Darwin regtest: no malloc.h header on Darwin

Typo in comment

Fix Darwin compilation

Removed memalign wrapper on Darwin, so valloc can't use it any more.

Bug 445743 - "The impossible happened: mutex is locked simultaneously by two threads" while using mutexes with priority inheritance and signals

Been using the same fix in FreeBSD for quite a while, so I think
it's safe to apply to Linux and close the bugzi item.

Remove unused helgrind expected

I don't think that this can match any more.

Change behaviour of posix_memalign for Solaris

It returns NULL and 0 status whilst most other platforms
allocatae some undefined amount of memory (which is allowed
by posix).

Update the posix_memalign test as well.

Finally remove some clang warnings about alignment.

Put back Darwin zone memalign

I had another look at the XNU source and this does seem to exist.
The manpage says that it is the zone version of posix_memalign,
though that's probably more because Darwin has no memalign.

Make memalign behave more like the underlying platform memalign

This is the first part of
Bug 466104 aligned_alloc problems, part 1

The bulk of this change is try try to get memalign to be more
platform aware. Previously the Valgrind implementation only
reflected the glibc implementation. That meant non-power of
two alignment values would silently get bumped up to the
next largest power of two. Most other platforms return NULL
and set errno to EINVAL.

There are a few other changes. A couple of the other aligned alloc
functions like valloc were caling the Valgrind memalign. This meant
that there weould be an extra Valgrind memalign in any error
callstacks. Now these functions call the allocator directly.

The memcheck memalign2 testcase has been redone. The memalign
parts moved out to per-platform versions and the tescase
itdelf renamed to posix_memalign, since that is all that is left.
I also modified the testcase so that it checks that the
memalign calls check for non-NULL returns, and on platforms
that set errno that it is correctly set. Previously the
test only worked on non-glibc because NULL & alignment is
zero.  The platform versions have been tested on glibc,
MUSL, FreeBSD and OpenIndiana and should hopefully run OK
both under memcheck and standalone.

There is stil quite a lot that is NOT done

1. I'm not certain that implementations allocate more memory
   and/or use a wider alignment. It doesn't help that almost
   universally the memalign implementations are badly
   documented, undocumented or buggy.
2. We don't handle very large alignment requests well.
   Most implementations will fail and set EINVAL if the
   alignment is over half the memory space. Valgrind will
   core panic if an aligmnt of over 16Mbytes is requested.
3. We don't generate any memcheck errors for invalid values
   of alignment. That's planned in Part 2.
4. The code is static and fixed at compile time. That means that
   if you are using MUSL with a glibc-built Valgrind you
   will still get glibc memalign behaviour.
   I'll wait to see if there are any requests before trying
   to make the behaviour selectable at runtime.

And here is the updated expected for FreeBSD scalar x86 mknodat

FreeBSD mknodat syscall dev arg is 64bits so the syscall needs splitting into amd64 and x86 versions

Small update to FreeBSD x86 scalar expected

FreeBSD: make rfork() fail more gracefully

rfork() is barely used in base FreeBSD. The main use
is in posix_spawn(). If rfork() fails with EINVAL
then it falls back to using vfork(). This is preferable
to Valgrind bombing.

ksh93 uses posix_spawn. I tested bash and csh and they had
no problems.

Also add 'hello world" smoke tests for bash csh and ksh

bug465435 - m_libcfile.c:66 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.

One small typo

musl regtest : fix warnings and badly initialized struct msghdr

Try to correct configure script for warning flags with values

Some -W flags come with and without an =
(usually for warning levels)
But some only have the form -Wfoo=42 and -Wno-foo

musl: fix a couple of warnings

musl doesn't have sys/poll.h

GCC moans and then uses poll.h

On glibc linux and FreeBSD poll.h is a symlink to sys/poll.h
Illumos poll.h includes sys/poll.h

regtest: remove compiler warnings with clang

DRD aarch64: Add some suppressions for DRD libstdc++

Also fix building drd/tests/std_mutex, needs -pthread.

README_DEVELOPERS: Explain how to set VALGRIND_LIB to gdb valgrind

Darwin: try to fix assert in DRD

The hard coded memory mapping trigger drd_start_using_mem_w_perms
which will lead to tl_assert(vg_tid != VG_INVALID_THREADID);

But vg_tid was just set to VG_INVALID_THREADID before the
hard coded memory map.

Regtest: rationalize filters for new/delete

Darwin regtest: add filtering for zone functions and realloc

For test of C++17 new/delete variations

DRD regtest: try to make timed_mutex more reliable

On RHEL 7.6 ARM I see this with the lock returning false
but without the 11 second timeout. Try adding some sleeps.

DRD regtest: try to make timed_mutex more reliable

On RHEL 7.6 ARM I see this with the lock returning false
but without the 11 second timeout. Try adding some sleeps.

DRD regtesat: update suppression file for std_threads2

On RHEL 7.6 ARM glibc 2.17 is used which doesn't match the 2.2*
wildard, so widen the wildcard to just 2.*

FreeBSD: fix internal sysctlbyname

I used the libc interface rather than the syscall interface.
The syscall also has the name length which libc adds.

Regtest: foix warning from drd test pth_mutex_signal.c

GCC on RHEL 7.6 ARM complains about the empty init list.

I also noticed that we are using the SA_NOTIFY form of sigaction
(with that union member and handler prototype) but not setting the
SA_NOTIFY flag. Seems harmless in this case as we don't use
the siginfo or context.

FreeBSD: improve internal syscallbyname

Post FreeBSD 12.2 this is a syscall that does everything
(rather than needing an undocumented syscall).

GDB regtest: add filter for gdb python load, RHEL 7.4 ARM

Add valgrind-monitor[-def].py to EXTRA_DIST

So as to make sure these get copied into the tarball.
Fixes make distcheck.

FreeBSD: cleanup launcher

cppcheck spotted a bug in the skipping of whitespace between shebang
and interpreter command. This could potentially cause the platform
to be misidentified (for x86 on amd64).

Pack Lackey Event structure

Seen by cppcheck. Will reduced size from 4 to 3 words on 64bit platforms.

FreeBSD: cleanup and refactor syscalls readlink and readlinkat

There was some code to handle /proc/curproc/file (a symlink to
the exe that wee need to bodge as it refers to the tool exe).
But it was neither tested nor working.

Can't use the same technique as Linux and Solaris which have more
complete /proc filesystems where each pid has symlinks for
each open file, which we use for the guest. Instead need to
copy the path ourselves. So move sys_readlink out of generic.

Simplify the handling of the resolved guest exe name - store it in
a global like VG_(args_the_exename).

Remove warning caused by D demangle testcase

bug464969_d_demangle.cpp: Always print "Xa"

bug464969_d_demangle depends on producing an error about an
uninitialized variable. But it prints something different
to stdout based on the value of that variable. Which can
produce failures. Make sure to always print the same thing
to stdout.

drd/tests/pth_mutex_signal: Port to Darwin

This patch includes a revert of commit 2e873534bb49 ("macOS: drd
pth_mutex_signal test doesn't build").

Bug 464969 -  D language demangling

    Patch from witold.baryluk@gmail.com

(also added a testcase)

macOS: drd pth_mutex_signal test doesn't build

pth_mutex_signal.c:50:13: error: use of undeclared identifier 'SIGRTMAX'
  sigaction(NATIVE_IO_INTERRUPT_SIGNAL, &signalAction, NULL);

Put this target under a condition for the moment.

Compiler warning expansion to defined

Clang doesn't like
m_debuginfo/tinfl.c:182:45: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]

macOS: Try to fix build, doesn't like .debug_gdb_scripts

Remove one lingering trace of tilegx

tsan_thread_wrappers_pthread.h: Only include cstdint for C++11

Fixes build on older g++.

configure.ac: Update AC_PROG_CC checks

AM_PROG_CC_C_O has been obsolete since automake 1.14.
AC_PROG_CC does the same check. With autoconf 2.70 we
must use AC_PROG_CC (which will check for c11 and c99),
for earlier versions we'll use AC_PROG_CC_C99.

Illumos: regtest filters and gitignore

Filter for the gdb python autoload warnings
Filter for another variation of shell abort messages

Regtest: broaden suppression for helgrind bug 392331

Inlining differences on different Linux platforms.

Bug 382034 - Testcases build fixes for musl

Bug 464859 - Build failures with GCC-13 (drd tsan_unittest)

Patch submitted by
Khem Raj <raj.khem@gmail.com>

Linux regtest: some extra filtering for helgrind bug392331

Was failing on rhel 7.6

Linux regtest: forgot prereq test for scalar_openat2

FreeBSD: update comment about __sysctlbyname and kern.proc.pathname

FreeBSD: fix compile of auxv on FreeBSD 12

FreeBSD: fix build on older OSes

A bad copy-and-paste broke compilation on FreeBSD 12.

FreeBSD: remove different reserved fds number

No idea where it originated. Causes no problems on
FreeBSD 13.1 amd64.

FreeBSD: switch to FreeBSD 12 versions of syscalls for fstat etc

This was a change that enabled 64bit inodes (ino64).

Also a couple of typos in READMEs.

Bug 435441 - valgrind fails to interpose malloc on musl 1.2.2 due to weak symbol name and no libc soname

Patch by Michael Forney <mforney@mforney.org>

FreeBSD: More details on interrupting vgdb and correct 1 typo.

FreeBSD: start adding more checks for /proc

Also add a couple of expecteds.

FreeBSD: improve auxv filter

Didn't work id the clone directory isn't 'valgrind'

FreeBSD: Fix auxv AT_EXECPATH

This was being copied from the host. Now it's synthesized for
the guest. Also improve the none/freebsd/auxv test to
print a few of the strings in auxv (but not the envp ones).

Two more debuginfo.c typos

Bug 464476 - Firefox fails to start under Valgrind

On FreeBSD, Firefox uses the kern.proc.pathname.PID sysctl
to get the binary path (where PID can be the actual pid
or -1). The user path is /usr/local/bin/firefox which is
a symlink to /usr/local/lib/firefox/firefox.

This was failing because we were not handling this MIB.
That meant that the sysctl returned the path for the
binary of the running tool (e.g.,
/home/paulf/scratch/valgrind/memcheck/memcheck-amd64-freebsd).
Firefox looks for files in the same directory.
Since it was the wrong directory it failed to find them and
exited.

I also noticed a lot of _umtx_op errors. On analysis they
are spurious. The wake ops take an "obj" argument, a pointer
to a variable. They only use the address as a key for
lookups and don't read the contents.

FreeBSD: small change for pthread mutex types

It seems what is 'normal' and 'default' is not
portable.

And a bit more debuginfo mmap comment fixing

Cleanup mmap comments in debuginfo.c

m_debuginfo: Suppress warning about not handling entry_value ops

The warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf3 isn't
very helpful. This means we didn't handle DW_OP_GNU_entry_value.

DW_OP_GNU_entry_value (or DWARF5 DW_OP_entry_value) means interpreting
the given DWARF expression using register values as they were upon
entering the function. Which is non-trivial to implement.

We can fail the evaluation of the DWARF expression without warning
about it by default, since it isn't really needed for any current
valgrind functionality (and it is only done with --read-var-info=yes.

FreeBSD: some _umtx_op corrections

mutex trylock doesn't user timer arguments
plain mutex lock doesn't need restart

still not sure about mutex trylock

FreeBSD: some more clangd refactoring

Remove execute bit from drd tests std_string.cpp

Update wrong expecteds for Bug 241072

Bug 241072 List tools in --help output

s390: Add z16 support to ecag testcase

The testcase 'none/tests/s390x/ecag' requires expected output from any
machine it runs on.  This is missing for z16, so add it.

s390: Add test for short/extended vector float insns

Several issues with vector floating point instructions have gone unnoticed
due to a lack of test coverage in this area.  Add a test case that
improves the coverage, particuarly when dealing with short and extended
floating point formats.

s390: Stop CC clobbering by VFMIN and VFMAX

Valgrind's implementation of the VFMIN and VFMAX instructions clobbers the
condition code, which is wrong.  Stop doing that.

s390: Un-swap implementations of VFCH and VFCHE

When running under Valgrind, the VFCH instruction behaves like VFCHE, and
vice versa.  Fix this.

s390: Fix VFMA, VFMS, VFNMA, and VFNMS for 128-bit FP

When trying to execute any of the vector float multiply-and-add family
instructions, Valgrind panics with the message "Iex_Qop with F128 data".

So far all F128 operations were implemented with instructions that operate
on FP register pairs.  However, such instructions don't exist for
Iop_MAddF128 and Iop_MSubF128, so they must be implemented with vector
instructions instead.  This was missed when emitting them in
"guest_s390_toIR.c".

Add the missing support.  This also involves adding a few new features to
host_s390_defs:

* a new vector operation S390_VEC_INIT_FROM_FPRS

* the capability to move the left half of a VR to an FPR

* S390_VEC_FLOAT_MADD/_MSUB for 128-bit sizes

Bug 460356 -- s390: Fix code generation for Iop_Sqrt32Fx4

There is no instruction selector for Iop_Sqrt32Fx4, leading to Valgrind
panicking with the message:

   s390_isel_vec_expr: cannot reduce tree

Fix this.

gdbserver tests filter out uninstalled python scripts warnings

Filter out loading error messages when python scripts haven't
been installed yet (running against vg-in-place)

Linux regtest: openat2 not available on older systems

The x86-linux/scalar testcase fas failing to compile.
So split out openat2 into a separate test with a condfigure test.

Fix gdbserver tests failing when python code cannot be autoloaded.

If the valgrind python code loading is not authorised by GDB config,
ensure the related error messages and info messages are filtered.

Cleanup warnings

Now no warnings on Fedora 36
For a short while

FreeBSD: clang-tidy corrections

Cleanup of warnings, mostly -Wno-unused-but-set-variable

Implement front end GDB commands for Valgrind gdbserver monitor commands.

This commit implements in python a set of GDB commands corresponding to the
Valgrind gdbserver monitor commands.

Basically, the idea is that one GDB command is defined for each valgrind
gdbserver subcommand and will generate and send a monitor command to valgrind.

The python code is auto-loaded by GDB as soon as GDB observes that the valgrind
preload core shared lib is loaded (e.g. vgpreload_core-amd64-linux.so).
This automatic loading is done thanks to the .debug_gdb_scripts section
added in vg_preloaded.c file.

Sadly, the auto-load only happens once valgrind has started to execute the code
of ld that loads this vg_preload file.

I have tried 2 approaches to have the python code auto-loaded when attaching at
startup to valgrind:
  * have valgrind gdbserver reporting first to GDB that the executable file is
    the tool executable (with a .debug_gdb_scripts section) and then reporting
    the real (guest) executable file.
    The drawback of this approach is that it triggers a warning/question in GDB
    according to the GDB setting 'set exec-file-mismatch'.
  * have valgrind gdbserver pretending to be multiprocess enabled, and report
    a fake process using the tool executable with a .debug_gdb_scripts section.
    The drawback of this is that this always creates a second inferior in GDB,
    which will be confusing.

Possibly, we might complete the below message :
  ==2984378== (action at startup) vgdb me ...
  ==2984378==
  ==2984378== TO DEBUG THIS PROCESS USING GDB: start GDB like this
  ==2984378==   /path/to/gdb /home/philippe/valgrind/littleprogs/some_mem
  ==2984378== and then give GDB the following command
  ==2984378==   target remote | /home/philippe/valgrind/git/improve/Inst/libexec/valgrind/../../bin/vgdb --pid=2984378
  ==2984378== --pid is optional if only one valgrind process is running

with:
  ==2984378== GDB valgrind python specific commands will be auto-loaded when execution begins.
  ==2984378== Alternatively, you might load it before with the GDB command:
  ==2984378==   source /abs/path/to/valgrind/install/libexec/valgrind/valgrind-monitor.py

The following GDB setting traces the monitor commands sent by a GDB valgrind
command to the valgrind gdbserver:
  set debug valgrind-execute-monitor on

How to use the new GDB valgrind commands?
-----------------------------------------

The usage of the GDB front end commands is compatible with the
monitor command as accepted today by Valgrind.

For example, the memcheck monitor command "xb' has the following usage:
 xb <addr> [<len>]

With some piece of code:
   'char some_mem [5];'
xb can be used the following way:
  (gdb) print &some_mem
  (gdb) $2 = (char (*)[5]) 0x1ffefffe8b
  (gdb) monitor xb 0x1ffefffe8b 5
       ff   ff   ff   ff   ff
  0x4A43040:   0x00 0x00 0x00 0x00 0x00
  (gdb)

The same action can be done with the new GDB 'memcheck xb' command:
  (gdb) memcheck xb 0x1ffefffe8b 5
       ff   ff   ff   ff   ff
  0x1FFEFFFE8B:   0x00 0x00 0x00 0x00 0x00
  (gdb)

At this point, you might ask yourself: "what is the interest ?".

Using GDB valgrind commands provides several advantages compared to
the valgrind gdbserver monitor commands.

Evaluation of arguments by GDB:
-------------------------------
For relevant arguments, the GDB command will evaluate its arguments using
the usual GDB evaluation logic, for example, instead of printing/copying
the address and size of 'some_mem', the following will work:
  (gdb) memcheck xb &some_mem sizeof(some_mem)
       ff   ff   ff   ff   ff
  0x1FFEFFFE8B:   0x00 0x00 0x00 0x00 0x00
  (gdb)

or:
  (gdb) p some_mem
  $4 = "\000\000\000\000"
  (gdb) memcheck xb &$4
       ff   ff   ff   ff   ff
  0x1FFEFFFE8B:   0x00 0x00 0x00 0x00 0x00
  (gdb)

This is both easier to use interactively and easier to use in GDB scripts,
as you can directly use variable names in the GDB valgrind commands.

Command completion by GDB:
--------------------------
The usual command completion in GDB will work for the GDB valgrind commands.
For example, typing TAB after the letter 'l' in:
  (gdb) valgrind v.info l
will show the 2 "valgrind v.info" subcommands:
  last_error  location
  (gdb) valgrind v.info l

Note that as usual, GDB will recognise a command as soon as it is unambiguous.

Usual help and apropos support by GDB:
--------------------------------------
The Valgrind gdbserver provides an online help using:
  (gdb) monitor help
However, this gives the help for all monitor commands, and is not searchable.
GDB provides a better help and documentation search.
For example, the following commands can be used to get various help
or search the GDB Valgrind command online documentation:
   help valgrind
   help memcheck
   help helgrind
   help callgrind
   help massif
to get help about the general valgrind commands or the tool specific commands.

Examples of searching the online documentation:
  apropos valgrind.*location
  apropos -v validity
  apropos -v leak

User can define aliases for the valgrind commands:
--------------------------------------------------
The following aliases are predefined:
  v and vg for valgrind
  mc for memcheck
  hg for helgrind
  cg for callgrind
  ms for massif

So, the following will be equivalent:
   (gdb) valgrind v.info location &some_mem
   (gdb) v v.i lo &some_mem
   (gdb) alias Vl = valgrind v.info location
   (gdb) Vl &some_mem

Thanks to Hassan El Karouni for the help in factorising the python
code common to all valgrind python commands using a decorator.

Avoid doing mempool specific leak search activities if there are no mempools

For most memcheck users, no mempools are used, but the leak search logic
was doing in any case special handling, leading to useless work such as
sorting again an already sorted array and making a copy of an array without
modifying it.

This slightly optimises the perf reg tests of memcheck.
perl perf/vg_perf --tools=memcheck --vg=. --vg=../trunk_untouched perf
-- Running  tests in perf ----------------------------------------------
-- bigcode1 --
bigcode1 .         :0.08s  me: 3.0s (38.1x, -----)
bigcode1 trunk_untouched:0.08s  me: 3.1s (38.6x, -1.3%)
-- bigcode2 --
bigcode2 .         :0.07s  me: 7.4s (105.9x, -----)
bigcode2 trunk_untouched:0.07s  me: 7.5s (107.4x, -1.5%)
-- bz2 --
bz2      .         :0.40s  me: 5.2s (12.9x, -----)
bz2      trunk_untouched:0.40s  me: 5.4s (13.6x, -5.0%)
-- fbench --
fbench   .         :0.15s  me: 2.8s (18.8x, -----)
fbench   trunk_untouched:0.15s  me: 2.9s (19.0x, -1.1%)
-- ffbench --
ffbench  .         :0.16s  me: 2.7s (16.8x, -----)
ffbench  trunk_untouched:0.16s  me: 2.7s (17.1x, -1.9%)
-- heap --
heap     .         :0.06s  me: 4.0s (66.5x, -----)
heap     trunk_untouched:0.06s  me: 4.1s (68.7x, -3.3%)
-- heap_pdb4 --
heap_pdb4 .         :0.07s  me: 6.2s (89.1x, -----)
heap_pdb4 trunk_untouched:0.07s  me: 6.6s (94.9x, -6.4%)
-- many-loss-records --
many-loss-records .         :0.01s  me: 1.2s (122.0x, -----)
many-loss-records trunk_untouched:0.01s  me: 1.2s (125.0x, -2.5%)
-- many-xpts --
many-xpts .         :0.03s  me: 1.2s (41.7x, -----)
many-xpts trunk_untouched:0.03s  me: 1.3s (43.7x, -4.8%)
-- memrw --
memrw    .         :0.06s  me: 1.2s (19.8x, -----)
memrw    trunk_untouched:0.06s  me: 1.2s (20.2x, -1.7%)
-- sarp --
sarp     .         :0.02s  me: 1.8s (91.5x, -----)
sarp     trunk_untouched:0.02s  me: 2.1s (103.5x,-13.1%)
-- tinycc --
tinycc   .         :0.11s  me: 7.1s (64.4x, -----)
tinycc   trunk_untouched:0.11s  me: 7.1s (64.3x,  0.1%)
-- Finished tests in perf ----------------------------------------------

== 12 programs, 24 timings =================

Bug 433873 - openat2 syscall unimplemented on Linux

This syscall is not exposed via glibc, so there is only an
addition to the scalar test.

Remove a debugging line `if (0) ..` that mistakenly got landed in fa3a9cc43c22593c70796a99aff33bb9436ad448.

Fix 64-bit uncleanness in VG_(get_bbs_translated)/VG_(get_bbs_discarded_or_dumped) ..

.. and some debug printing associated with them.  I don't think this affects
anything apart from debug printing.  Noticed when running a x86 (32-bit)
Firefox build.

amd64 and x86 front ends: add a few more spec rules.

amd64:
  S and NS  after LOGICQ (per comments from Eyal Soha on the dev list)
  S         after SHLQ
  NZ        after SHLL

x86:
  NZ        after SHRL
  Z         after SHLL

I would have liked to have added the inverse conditions in all cases (eg, both
S and NS, or both Z and NZ), but finding use cases for some of these is almost
impossible, hence they are sometimes omitted.  All of the added cases have
been tested.

Memcheck: handle origin data for 8-/16-bit shadow stores a bit more accurately.

With origin tracking enabled, 8- and 16-bit stores could sometimes lose origin
info unnecessarily.  This patch removes this avoidable lossage.  (Since MC
only stores 1 origin value for each 32-bit word of address space, there is
still unavoidable lossage of origins in some cases; this patch does not help
in those cases since it's a fundamental design limitation.)

DHAT: increase the size of the cache for `find_Block_containing` from 2 to 3.

In the hope of making DHAT a bit faster.

Bug 327548 - false positive while destroying mutex

Small improvement to documentation.

Update none/tests/cmdline1 and 2 for non-linux

Allows to only output "new" loss records when doing a leak search.

In the memcheck monitor 'leak_search', add a "new" keyword corresponding
to the delta leak search mode LCD_New.

Add a new client request VALGRIND_DO_NEW_LEAK_CHECK.

When doing a delta leak search, new loss records are marked with "new"
(whatever the delta leak search mode).

Note that trailing white spaces were removed in mc_main.c.
A much small diff can be looked at by using the -w diff option.

Add clo option -scheduling-quantum=<number> to control scheduler time slice.

This option can be useful when tracking race conditions which are sensitive
to thread scheduling.

FreeeBSD: Add Helgrind suppression for void __thread_specific_ptr<_Tp>::set_pointer(pointer __p)