Re: ia64/91846: TLS: malloc(3) exposes DTLS bug in non-threaded applications

[Doug Rabson <dfr@xxxxxxxxxx>]

On Monday 16 January 2006 00:22, Marcel Moolenaar wrote:
> >Number:         91846
> >Category:       ia64
> >Synopsis:       TLS: malloc(3) exposes DTLS bug in non-threaded
> > applications Confidential:   no
> >Severity:       serious
> >Priority:       medium
> >Responsible:    freebsd-ia64
> >State:          open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Mon Jan 16 00:30:07 GMT 2006
> >Closed-Date:
> >Last-Modified:
> >Originator:     Marcel Moolenaar
> >Release:        7-CURRENT
> >Organization:
> >Environment:
>
> FreeBSD bigsur.pn.xcllnt.net 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Fri
> Jan 13 16:26:27 PST 2006    
> marcel@xxxxxxxxxxxxxxxxxxxx:/usr/obj/nfs/freebsd/7.x/src/sys/BIGSUR 
> ia64
>
> >Description:
>
> When NO_TLS is *not* defined in src/lib/libc/stdlib/malloc.c on ia64,
> then a SIGSEGV will result due to arenas_map being thread-local and
> it being referenced in choose_arena(). That reference causes a
> thread-local relocation to end up in tls_get_addr_common() in
> src/libexec/rtld-elf/rtld.c for which the dtvp argument is NULL. This
> pretty much means that __tls_get_addr() on ia64 does the wrong thing.
> In this case it assumes that r13 (aka TP) is non-NULL in all cases,
> which is false for non-threaded applications.

I don't understand this. Any dynamic application (threaded or 
non-threaded) should end up 
calling .../ia64/reloc.c:allocate_initial_tls() which sets r13 to point 
at the TLS block for the main thread (or only thread for non-threaded).