#simple shared object results in SIGABRT: mem.alignForward assertion failed

1 messages · Page 1 of 1 (latest)

unkempt adder
#

I have a simple C program calling into a zig-built shared object.

extern void libmain(void);

int main() {
  libmain();
  return 0;
}

Built with gcc -g -O0 test.c -L. -lkernel -o test.
the zig library is built with pic = true. It effectively uses the same code i use to make an executable, except it sets entry to libmain (unnecessary, but useful for what i eventually intend to do) and builds a shared object instead of an executable. libmain simply calls main() catch unreachable;.

the execution is fine until eventually a thread starts up:

   5   0x7ffff7b7ad99 None
   6   0x7ffff7b768ae debug[assert]+46
 ► 7   0x7ffff7b96cf4 mem.alignForward__anon_9055+52
   8   0x7ffff7c1d102 Thread.LinuxThreadImpl.spawn__anon_28826+802
   9   0x7ffff7c16e8d Thread.spawn__anon_28044+29
   10   0x7ffff7c16b10 Thread.Pool.init+944
   11   0x7ffff7c12c49 [removed]
   12   0x7ffff7c0f4e9 [removed]
   13   0x7ffff7c0d14f [removed]
   14   0x7ffff7c0c806 main.main+614

The specific line is:

   4402 pub fn alignForward(comptime T: type, addr: T, alignment: T) T {
 ► 4403     assert(isValidAlignGeneric(T, alignment));
   4404     return alignBackward(T, addr + (alignment - 1), alignment);
   4405 }

where the assertion fails. For this call, alignment is 0, and addr is 0x1001000, which is meant to be linux.tls.area_desc.alignment. This occurs when mapping bytes for the thread.

i am not sure what to do about this. i dont really know enough about linux threading to know why it would fail as a shared object but not as an executable. Any and all help is appreciated.

bronze egret
#

you need to link libc in the zig library to make it use pthread's threadlocal mechanism instead of its own

unkempt adder
#

RIP it adds 153kb to my binary in ReleaseSmall, thats irritating

unkempt adder
#

ok issue: i need a statically linked binary. trying to link musl gives me invalid elf headers

unkempt adder
#

yeah i cant find a way to get libc statically linking. .link_libc = true results in musl being dynamically linked, which isnt acceptable

#

ive manually specified -Dtarget=x86_64-linux-musl and that doesnt change anything; the .so is still looking for musl. the binary isnt, but i need something that can be used with dlopen

#

eh maybe gnu would work

winged dune