Re: Gimp does not build on macppc: No space available for static Thread Local Storage

Martin Husemann <[email protected]>
Newsgroups gmane.os.netbsd.devel.toolchain
Message-ID <[email protected]>
On Fri, May 27, 2022 at 06:56:57AM +0200, Martin Husemann wrote:
> Hey folks,
> 
> trying to build Gimp from pkgsrc-current on NetBSD/macppc -current
> fails with:
> 
> mkdir -p `dirname 64/gimp-info.png` && GEGL_USE_OPENCL=no GEGL_SWAP=ram /usr/pkg/bin/gegl ../../icons/Symbolic/64/gimp-info.png -o 64/gimp-info.png -- cast-format input-format="R'G'B'A float" output-format="RGBA float" brightness-contrast contrast=1.5 cast-format input-format="RGBA float" output-format="R'G'B'A float"
> GEGL-Message: 06:50:10.625: Module '/usr/pkg/lib/gegl-0.4/exr-save.so' load error: /usr/lib/libstdc++.so.9: No space available for static Thread Local Storage

I added a bit more debugging info:

Module '/usr/pkg/lib/gegl-0.4/exr-save.so' load error:
/usr/lib/libstdc++.so.9: No space available for static Thread Local
Storage, initial space 3936, initial offset 3872, offset 3936, align 4,
tlssize 16, next_offset 3952, _rtld_tls_static_space 3936

and that values confuse me a bit (patch that produced them below). IIUC:

 - we are loading "obj" /usr/lib/libstdc++.so.9
 - that object asks for 16 bytes of TLS storage with 4 byte alignement
 - we initially allocated 3936 bytes of TLS space but set start offset
   to 3872 (why?)
 - and that is exactly how we are when starting to resolve this request
   for libstdc++ (offset is still 3936 and will be 3952 after allocation,
   which exceeds the allocated 3936)

That totally sounds like random garbage initially in _rtld_tls_static_offset,
but the only place it gets modified we should not have reached yet (a few
lines after the error message is printed).

Any ideas?

Martin

Index: tls.c
===================================================================
RCS file: /cvsroot/src/libexec/ld.elf_so/tls.c,v
retrieving revision 1.14
diff -u -p -r1.14 tls.c
--- tls.c	5 Nov 2019 22:22:42 -0000	1.14
+++ tls.c	27 May 2022 09:59:34 -0000
@@ -53,6 +53,11 @@ static size_t _rtld_tls_static_offset;	/
 size_t _rtld_tls_dtv_generation = 1;
 size_t _rtld_tls_max_index = 1;
 
+/* debug vars for later error message */
+static size_t _rtld_orig_tls_static_space;
+static size_t _rtld_orig_tls_static_offset;
+
+
 #define	DTV_GENERATION(dtv)	((size_t)((dtv)[0]))
 #define	DTV_MAX_INDEX(dtv)	((size_t)((dtv)[-1]))
 #define	SET_DTV_GENERATION(dtv, val)	(dtv)[0] = (void *)(size_t)(val)
@@ -105,6 +110,9 @@ _rtld_tls_initial_allocation(void)
 #endif
 	dbg(("_rtld_tls_static_space %zu", _rtld_tls_static_space));
 
+_rtld_orig_tls_static_space = _rtld_tls_static_space;
+_rtld_orig_tls_static_offset = _rtld_tls_static_offset;
+
 	tcb = _rtld_tls_allocate_locked();
 #ifdef __HAVE___LWP_SETTCB
 	__lwp_settcb(tcb);
@@ -255,8 +263,15 @@ _rtld_tls_offset_allocate(Obj_Entry *obj
 		}
 		if (next_offset > _rtld_tls_static_space) {
 			_rtld_error("%s: No space available "
-			    "for static Thread Local Storage",
-			    obj->path);
+			    "for static Thread Local Storage, initial space %zu, "
+			    "initial offset %zu, offset %zu, "
+			    "align %zu, tlssize %zu, next_offset %zu, "
+			    "_rtld_tls_static_space %zu",
+			    obj->path, 
+			    _rtld_orig_tls_static_space, _rtld_orig_tls_static_offset,
+			    offset,
+			    obj->tlsalign, obj->tlssize, next_offset,
+			    _rtld_tls_static_space);
 			return -1;
 		}
 	}
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.