This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TLS redux


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]