Ping: RFC: Removing malloc hooks

[DJ Delorie <dj at redhat dot com>]

Returning to this after some diversions (including some vacation time :).

The patch: https://www.sourceware.org/ml/libc-alpha/2018-04/msg00131.html

So far, the only comment I've gotten (Thanks, Joseph :) was about the
HAVE_MALLOC_HOOKS macro.  I mentioned that at one point I was
contemplating taking the hook variables out for new ports, but I think
this deserves a bit more thought from others...

The big question is: where in the deprecation stage should 2.28 be at?

The hook variables are *already* marked as deprecated, and have been
since 2.14 [1], as the implementation is broken in multi-threaded cases,
including hook-related services.  That's "broken since 2011" :-P

My change is primarily about removing the code in libc.so to process and
call the hooks.  Existing binaries will continue to run wihout
recompiling, the hook functions just won't be called unless you set an
environment variable.  This implies that hook-based services (mcheck and
mtrace, ish) act (or don't) accordingly, although alternatives to those
(which support threading) exist elsewhere.

Do we want to allow new compiles to "use" hooks too?  Do we need to take
the declarations out of malloc.h, and possibly poison the hooks via
versioning or something, to force 2.28 to not allow the false assumption
that hooks are still supported by default?


[1] https://www.sourceware.org/ml/libc-alpha/2011-05/msg00103.html