[PATCH 4/7] Move libc_freeres_ptrs and libc_subfreeres to weak functions

[Florian Weimer]

* Adhemerval Zanella via Libc-alpha:

> diff --git a/malloc/set-freeres.c b/malloc/set-freeres.c
> index be8c2a35fc..ce5d010133 100644
> --- a/malloc/set-freeres.c
> +++ b/malloc/set-freeres.c
> @@ -15,32 +15,210 @@
>     License along with the GNU C Library; if not, see
>     <https://www.gnu.org/licenses/>.  */

> +/* Resource Freeing Hooks:
> +
> +   Normally a process exits and the OS cleans up any allocated
> +   memory.  However, when tooling like mtrace or valgrind is monitoring
> +   the process we need to free all resources that are part of the
> +   process in order to provide the consistency required to track
> +   memory leaks.
> +
> +   A single public API exists and is __libc_freeres(), and this is used
> +   by applications like valgrind to freee resouces.
> +
> +   Each free routines must be explicit listed below, with the care to define
> +   weak functions for external symbol if applicable.   */
> +
> +/* From libc.so.  */
> +extern void __libc_freemem (void) weak_function;
> +extern void __hdestroy (void) weak_function;
> +extern void __gconv_cache_freemem (void) weak_function;

These declarations should come from headers under include/, so that they
can be proper type-checked against the implementation.

> +static void (*__libc_freeres_funcs[])(void) attribute_relro =
> +{
> +  __libc_freemem,
> +  __hdestroy,
> +  __gconv_cache_freemem,

I think we can avoid these relocations for the dynamic case if we just
call these functions using call_function_static_weak, or directly free
the pointers using call_free_static_weak (see the other message).  The
latter has somewhat large code size, but I think that's the right
trade-off here.

Thanks,
Florian