TLS redux

[Carlos O'Donell]

On 01/28/2014 08:23 PM, Rich Felker wrote:
> On Mon, Jan 27, 2014 at 11:25:27AM -0800, Jason Evans wrote:
>> On Jan 27, 2014, at 9:52 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
>>> On Mon, Jan 27, 2014 at 9:32 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>>
>>>>> 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.
>>>>
>>>> That should not happen, and would be a major bug.
>>>
>>> I could be mistaken, but I am 99% sure this *did* happen in glibc-2.2
>>> - 2.5 time frame under specific (and rare) execution path with
>>> pthread_exit from main thread or some such.
>>>
>>>>> They are the same implementation, so no harm done, right?
>>>>
>>>> The ld.so malloc is a stub implementation that has nothing in common
>>>> with libc malloc.
>>>
>>> Currently that's the case. Was that the case in glibc-2.2?
>>>
>>>
>>> Anyway, my point is that interposing malloc under glibc was never an
>>> easy affair, was fraught with special cases, and Roland's claim that
>>> we broke it by using different allocator for TLS is an
>>> over-simplification of the reality that tools like Leak Sanitizer face
>>> now (and will likely continue to face for a while).
>>
>> Here's a slight variation on how the non-hermetic ld.so design can
>> bite:
>>
>> 	http://www.canonware.com/pipermail/jemalloc-discuss/2013-November/000663.html
>>
>> In short, ld.so doesn't save/restore floating point state when
>> calling into malloc, which can corrupt application state as a side
>> effect of lazy symbol loading.
> 
> Yet another reason that failing to save/restore the FULL register set
> on lazy symbol resolution is a bug that should be fixed on all archs,
> rather than being swept under the rug with excuses.

Do we have a bugzilla entry for this?

I can tag it for 2.20 and see if we can fix this.

The consequences seem somewhat dire though for performance?

Could we just do the save/restore around malloc at least?

I thought we ran into a similar bug for ARM and NEON?

Cheers,
Carlos.