On Thu, Jan 30, 2014 at 9:50 PM, Rich Felker <[email protected]> wrote: > On Thu, Jan 30, 2014 at 09:38:59PM +0400, Kostya Serebryany wrote: >> On Thu, Jan 30, 2014 at 8:54 PM, Rich Felker <[email protected]> wrote: >> > On Thu, Jan 30, 2014 at 12:49:03AM -0500, Carlos O'Donell wrote: >> >> On 01/30/2014 12:33 AM, Kostya Serebryany wrote: >> >> > On Thu, Jan 30, 2014 at 9:23 AM, Carlos O'Donell <[email protected]> >> >> > wrote: >> >> >> >> >> >> On 01/29/2014 04:48 AM, Kostya Serebryany wrote: >> >> >>> [text only] >> >> >>> >> >> >>>> Indeed so, thanks! >> >> >>>> So, exporting __signal_safe_memalign&co will allow us to extend the >> >> >>>> existing hack to 2.19. >> >> >>>> If this simple change can not be done for 2.19, can *anything* be >> >> >>>> done at all? >> >> >>>> (Long term we'd still prefer something less hackish) >> >> >>> >> >> >>> FTR, I've implemented an even-uglier-then-before hack that deals with >> >> >>> dynamic TLS in both <=2.18 and 2.19. >> >> >>> So, we will survive the 2.19 release. >> >> >>> But I would appreciate if we can resolve >> >> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=16291 >> >> >>> before the next one (2.20). >> >> >> >> >> >> Can you please describe the hack? >> >> > >> >> > intercept __tls_get_addr and __libc_memalign. >> >> > if __libc_memalign is called while we are inside __tls_get_addr, we >> >> > know we are in <= 2.18 mode and we know what to do. >> > >> > Or a signal handler happened to interrupt __tls_get_addr and something >> > from the signal handler caused __libc_memalign to get called. Is this >> > case handled? >> >> Is __libc_memalign AS-safe? I guess not. >> AddressSanitizer's implementation is certainly not. >> So, if __libc_memalign is called in a signal handler it is a problem by >> itself. >> That's what forced the the change in 2.19 in the first place. > > It's legal to call anything (even non AS-safe functions) from a signal > handler if the signal handler did not interrupt a non-AS-safe > function. This is easy to guarantee if the only threads where the > signal is unblocked are only using AS-safe functions (a trivial > example would be a thread doing for (;;) pause();).
Well, in <=2.18 this means that we can not call malloc in signal handler while using tls, so for <=2.18 the hack is safe. Then, there is a check in my hack that the result of the last __libc_memalign is is the same as the current result of __tls_get_addr (minus offset), so if we are in 2.19 mode and __libc_memalign is never called from __tls_get_addr we are still safe even if __libc_memalign is called from a signal handler. (I think...) --kcc > > Rich -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
