public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
* cannot allocate memory in static TLS block
@ 2003-09-05  6:02 Thorsten Kukuk
  2003-09-05  8:16 ` Jakub Jelinek
  0 siblings, 1 reply; 2+ messages in thread
From: Thorsten Kukuk @ 2003-09-05  6:02 UTC (permalink / raw)
  To: libc-hacker

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]


Hi,

compiling the appended test case on i686, gives me the following
error messages in some configurations:

# ./dlopen-tls 
dlopen() failed: './tls.so: cannot allocate memory in static TLS block'

It does not work with glibc compiled for i686 with TLS and
without NPTL (the fallback, if somebody uses an older kernel or
LD_ASSUME_KERNEL=2.4.1).

Is this a binutils/gcc problem or a bug in glibc? It seems to work
on other architectures with the same tool chain (gcc 3.3.1, 
binutils-2.14.90.0.5).

 Thanks,
  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Deutschherrnstr. 15-19        D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

[-- Attachment #2: Makefile --]
[-- Type: text/plain, Size: 166 bytes --]

all:
	gcc -g dlopen-tls.c -o dlopen-tls -Wall -ldl
	gcc -g -c tls.c -o tls.o -fPIC -ftls-model=local-exec
	gcc -g -o tls.so -shared tls.o

clean:
	rm -rf *.o *~ *.so

[-- Attachment #3: dlopen-tls.c --]
[-- Type: text/plain, Size: 754 bytes --]


#include <stdio.h>
#include <dlfcn.h>
#include <unistd.h>
#include <stdlib.h>

int main()
{
    void *handle;
    int (*func)(void);

    int i;

    for (i = 0; i < 500; i++) {

        handle = dlopen("./tls.so", RTLD_NOW);

        if (!handle) {
            fprintf(stderr, "dlopen() failed: '%s'\n", dlerror());
            exit(1);
        }

        func = dlsym(handle, "getTLSVar");
        
        if (!func) {
            fprintf(stderr, "Failed to find symbol 'getTLSVar'\n");
            exit(1);
        }
        
        func();

        if (dlclose(handle) != 0) {
            fprintf(stderr, "dlopen() failed: '%s'\n", dlerror());
            exit(1);
        }
        
        printf("success %d\n", i);

    }
    
    return 0;
}

[-- Attachment #4: tls.c --]
[-- Type: text/plain, Size: 70 bytes --]

static __thread int foo;

int getTLSVar(void)
{
    return foo; 
} 
 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: cannot allocate memory in static TLS block
  2003-09-05  6:02 cannot allocate memory in static TLS block Thorsten Kukuk
@ 2003-09-05  8:16 ` Jakub Jelinek
  0 siblings, 0 replies; 2+ messages in thread
From: Jakub Jelinek @ 2003-09-05  8:16 UTC (permalink / raw)
  To: Thorsten Kukuk; +Cc: libc-hacker

On Fri, Sep 05, 2003 at 08:02:24AM +0200, Thorsten Kukuk wrote:
> 
> Hi,
> 
> compiling the appended test case on i686, gives me the following
> error messages in some configurations:
> 
> # ./dlopen-tls 
> dlopen() failed: './tls.so: cannot allocate memory in static TLS block'
> 
> It does not work with glibc compiled for i686 with TLS and
> without NPTL (the fallback, if somebody uses an older kernel or
> LD_ASSUME_KERNEL=2.4.1).
> 
> Is this a binutils/gcc problem or a bug in glibc? It seems to work
> on other architectures with the same tool chain (gcc 3.3.1, 
> binutils-2.14.90.0.5).

It works for me with all 3 libc/libpthread combos we have on i686
(linuxthreads non-FLOATING_STACKS TLS, non-__thread,
linuxthreads FLOATING_STACKS TLS, non-__thread,
NPTL (obviously TLS __thread), aka LD_ASSUME_KERNEL={2.2.5,2.4.1,2.4.20}),
about a day old CVS checkout.

	Jakub

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-09-05  8:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-05  6:02 cannot allocate memory in static TLS block Thorsten Kukuk
2003-09-05  8:16 ` Jakub Jelinek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).