`-g --backtrace full` doesn't work on Linux

[ArtemkaKun]

fn main() {
    panic('panic')
}

compiled with

./spawnlang -g --backtrace full --run test.sp

outputs error

panic: panic

thread "main" (604503):
libbacktrace error: no debug info in ELF executable
libbacktrace error: no debug info in ELF executable
libbacktrace error: no debug info in ELF executable
libbacktrace error: no debug info in ELF executable
libbacktrace error: no debug info in ELF executable
note: looks like debug info is missing, try to recompile with `-g` flag

on both compilers (GCC and Clang). On ARM Mac this works as expected. Seems debug info is present in the executable as well

╰─λ objdump -h out | grep '\.debug'
28 .debug_aranges 00000090  0000000000000000  0000000000000000  0003c533  2**0
29 .debug_info   0001ad85  0000000000000000  0000000000000000  0003c5c3  2**0
30 .debug_abbrev 00001027  0000000000000000  0000000000000000  00057348  2**0
31 .debug_line   0000f7c2  0000000000000000  0000000000000000  0005836f  2**0
32 .debug_str    0000b6c5  0000000000000000  0000000000000000  00067b31  2**0
33 .debug_line_str 0000070b  0000000000000000  0000000000000000  000731f6  2**0
34 .debug_rnglists 000002ad  0000000000000000  0000000000000000  00073901  2**0

[B1Z0N]

Reproduced

Reproduced on Ubuntu WSL machine(and I suspect it's the case on bare Windows machine also):

/mnt/c/dev/personal/spawn/thirdparty/libbacktrace$ uname -a
Linux B1Z0N 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I checked the output with --showcc flag and the resulting command is using gcc with -g flag, which means it is working as intended:

gcc -Werror=int-conversion /mnt/c/dev/personal/spawn/out.c -std=gnu11 -funsigned-char -w -fdiagnostics-color=always -o /mnt/c/dev/personal/spawn/out -g -fno-omit-frame-pointer -fasynchronous-unwind-tables -I /mnt/c/dev/personal/spawn/thirdparty/libgc/include -D GC_BUILTIN_ATOMIC=1 -D GC_PTHREADS=1 -D GC_MARKERS=1 -D MPROTECT_VDB=1 -ldl -lpthread /mnt/c/dev/personal/spawn/thirdparty/libgc/gc.c -l m /mnt/c/dev/personal/spawn/thirdparty/libbacktrace/backtrace.c -I /mnt/c/dev/personal/spawn/thirdparty/libbacktrace -lpthread

Also when I check the out file with file command it shows:

/mnt/c/dev/personal/spawn$ file out
out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6e429c170ce4d28a4dcdfe98daad5bab1ebf6808, for GNU/Linux 3.2.0, with debug_info, not stripped

This is a good sign, specifically with debug_info, not stripped at the end. ELF debug symbols are here. Everything is working on this part.

Bugs candidates

Looked into it for a couple of hours and figured out that probably it has something to do with one of:

1. Outdated version of libbacktrace library - we use somewhat older files in our code. Perhaps something is fixed or updated already.
2. Specifically in darwin(macos) case, we have already pre-compiled libbacktrace library that is linked to the main executable here. Down below that line we are adding libbacktrace.c file to our compilation in case of non-darwin systems (linux, windows). Probably that's why such a difference in behavior.
3. Of course it can always be a mere bug in libbacktrace library. But the probability of this is undetermined. The library is highly used in top projects, which decreases the prob, but it is also very complex.

I also checked the API of this library and according to that our wrapper code must be ok.

Next

So if debug symbols are ok and our wrapper code is ok, the thing is probably in how we distribute the lib and which version of it we use in our project. With that I am going to look into the specific version of libbacktrace library that we use here and how we use it.

I'll be back with more updates.

UPD: I'm stuck with my Windows PC being really bad for building this libbacktrace library based on autotools. I'll switch to something more productive till I have UNIX system PC.

[ArtemkaKun]

Btw we have libbacktrace copy pasted from V repo, maybe we can handle this library and stuff in a better way or something

[B1Z0N]

That's a precious part of info! I'll take a look at it.

[i582]

@B1Z0N great!