I have further investigated about this problem.
In short, the answer to
will be No.
And,
will also be No, but in different reason.
First, the answer in StackOverflow on the link provided by @bcardiff (thanks!) says that the problem is that the object files use R_X86_64_REX_GOTPCRELX relocations. This relocation will be used when your code has external linkage, and you invoke GCC with argument -fno-plt. (If GC has been built without this option, Debian seems to have patched GCC to -fno-plt as default.)
For example, consider following C code, which has external linkages to foo and printf:
#include <stdio.h>
extern int foo(void);
int main(int argc, char **argv)
{
printf("%p\n", foo);
return 0;
}
Compiling this with -fno-plt generates an object file using R_X86_64_REX_GOTPCRELX relocation.
$ gcc -fno-plt -c c.c
$ readelf -r c.o
Relocation section '.rela.text' at offset 0x248 contains 3 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000000012 000b0000002a R_X86_64_REX_GOTP 0000000000000000 foo - 4
00000000001a 00050000000a R_X86_64_32 0000000000000000 .rodata + 0
000000000025 000c00000029 R_X86_64_GOTPCREL 0000000000000000 printf - 4
Relocation section '.rela.eh_frame' at offset 0x290 contains 1 entry:
Offset Info Type Sym. Value Sym. Name + Addend
000000000020 000200000002 R_X86_64_PC32 0000000000000000 .text + 0
Otherwise, these relocations won’t be used and PLTs are used instead.
$ gcc -c c.c
$ readelf -r c.o
Relocation section '.rela.text' at offset 0x218 contains 3 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000000010 000a0000000a R_X86_64_32 0000000000000000 foo + 0
000000000015 00050000000a R_X86_64_32 0000000000000000 .rodata + 0
00000000001f 000b00000004 R_X86_64_PLT32 0000000000000000 printf - 4
Relocation section '.rela.eh_frame' at offset 0x260 contains 1 entry:
Offset Info Type Sym. Value Sym. Name + Addend
000000000020 000200000002 R_X86_64_PC32 0000000000000000 .text + 0
For Clang, no modifications about code generation has been made when they introduced -fno-plt option (⚙ D39079 New clang option -fno-plt to avoid PLT for external calls), and just added small number of method calls. So, when not specified, it seems that this is dependent to LLVM whether use this relocation on code generation.
If Crystal does not do so, these relocations are not used until LLVM change the default. Therefore, any object files generated by crystal won’t cause this problem, currently.
On the other hand, Crystal distribution uses the patched version of GC (https://github.com/crystal-lang/distribution-scripts/blob/master/linux/files/feature-thread-stackbottom-upstream.patch), so using vendor GC may not work correctly.
I still want an official suggestion about this problem.
PS: The version of GCC used here is:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-momonga-linux/9.2.1/lto-wrapper
Target: x86_64-momonga-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-pkgversion='Momonga Linux 9.2.1-0.5m.mo8' --program-suffix= --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --enable-multilib --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --host=x86_64-momonga-linux --build=x86_64-momonga-linux --target=x86_64-momonga-linux --with-default-libstdcxx-abi=gcc4-compatible --with-build-config=bootstrap-lto --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --without-system-libunwind --enable-languages=c,c++,objc,obj-c++,fortran,lto,go --with-ppl --enable-cloog-backend=isl --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-momonga-linux
Thread model: posix
gcc version 9.2.1 20190831 (Momonga Linux 9.2.1-0.5m.mo8)