This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TLS redux
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Mon, 27 Jan 2014 08:39:02 -0800
- Subject: Re: TLS redux
- Authentication-results: sourceware.org; auth=none
- References: <20140115022335 dot EB13174430 at topped-with-meat dot com> <Pine dot LNX dot 4 dot 64 dot 1401150520530 dot 14350 at digraph dot polyomino dot org dot uk>
On Tue, Jan 14, 2014 at 9:42 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Tue, 14 Jan 2014, Roland McGrath wrote:
>
>> Today, dynamic TLS areas are allocated using the public malloc
>> interface. Programs or GC libraries or whatnot can today supply a
>> malloc replacement, scan the static data+bss area, scan each
>
> Does overriding malloc as used within ld.so actually work, then? I
> wouldn't have expected overriding necessarily to work for calls from
> ld.so, only for those from libc and other libraries.
For 10 years between 1997 and 2007 I've been in business (Insure++) of
interposing libc routines, including malloc (for the same purpose as
ASan -- bounds checks and leak detection).
This was *never* simple, and *always* required gross hacks on Linux.
One example that's burned into my memory is that memory allocated by
ld.so's private malloc may later be free'd by public libc.so.6 free.
They are the same implementation, so no harm done, right?
On all UNIX systems of the late 90s except glibc, ld.so was a hermetic
standalone program, that didn't use any symbols from libc.so, and so
Insure++ observed a mostly sane view of the world with matching malloc
and free.
Not so on glibc. I've recently had an occasion to find the thread that
explains why glibc is different:
https://sourceware.org/ml/libc-hacker/1999-02/msg00044.html
--
Paul Pluzhnikov