Skip to content

-g --backtrace full doesn't work on Linux #3

Open

Description

@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

Activity

  1. B1Z0N commented on Apr 1, 2024

    @B1Z0N
    Collaborator

    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.

  2. ArtemkaKun commented on Apr 1, 2024

    @ArtemkaKun
    CollaboratorAuthor

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

  3. B1Z0N commented on Apr 1, 2024

    @B1Z0N
    Collaborator

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

  4. i582 commented on Apr 1, 2024

    @i582
    Collaborator

    @B1Z0N great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions