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. if __libc_memalign was not called but the DSO ID passed to __tls_get_addr was not seen before by the current thread, we know that we are in 2.19 mode and that the TLS block was allocated by __signal_safe_memalign, which has a header with the actual block size. Ugly, as I said. --kcc > > Cheers, > Carlos. > -- 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.
