#compiled .so not detected as having debug symbols

1 messages · Page 1 of 1 (latest)

sullen sandal
#

trying to debug a DLL by running a debugger on the parent program. on windows it works fine (windbg), however on linux (.so file) neither lldb nor gdb seem to pick up the symbols.

const std = @import("std");

pub fn build(b: *std.Build) void {
    const target = b.standardTargetOptions(.{});
    const optimize = b.standardOptimizeOption(.{});

    const sanlib = b.addModule(
        "root",

        std.Build.Module.CreateOptions{
            .root_source_file = b.path("src/root.zig"),
            .target = target,
            .optimize = optimize,
        },
    );
    const byondapi = b.addModule(
        "byondapi",
        std.Build.Module.CreateOptions{
            .root_source_file = b.path("byondapi/_byondapi.zig"),
            .target = target,
            .optimize = optimize,
        },
    );
    if (target.query.os_tag == .windows) {
        byondapi.addLibraryPath(b.path("import"));
        byondapi.linkSystemLibrary("byondapi", .{});
    }
    sanlib.addImport("byondapi", byondapi);
    sanlib.addImport("sanlib", sanlib);
    byondapi.addImport("sanlib", sanlib);

    const lib = b.addLibrary(.{
        .name = if (target.query.os_tag == .windows) "libsan" else "san",
        .root_module = sanlib,
        .linkage = .dynamic,
    });
    b.installArtifact(lib);

    const test_byondapi = b.addTest(.{ .root_module = byondapi });
    const test_sanlib = b.addTest(.{ .root_module = sanlib });

    const run_test_byondapi = b.addRunArtifact(test_byondapi);
    const run_test_sanlib = b.addRunArtifact(test_sanlib);

    const test_step = b.step("test", "Run unit tests");
    test_step.dependOn(&run_test_sanlib.step);
    test_step.dependOn(&run_test_byondapi.step);
}

compiled through zig build -Dtarget=x86-windows and -Dtarget=x86-native (linux) respectively

# 
warning: Could not load shared library symbols for ext/libsan.so.
Do you need "set solib-search-path" or "set sysroot"?

Program received signal SIGTRAP, Trace/breakpoint trap.
0xf5bc4431 in ?? ()
dire maple
#

you are only linking the library when targeting windows
also system library will be more optimised and have less debug information, so they might be harder to reason about in a debugger, though it should still work.

sullen sandal
#

so

dire maple
#

oops, sorry

sullen sandal
#

the program provides a supplementary .lib to link against for its c api
its not needed (?) for linux

#

ext/libsan.so is the output here and the "this .so isnt working" in question

sour flame
#

maybe you need to do set solib-search-path . or whatever directory ext/ is in

sullen sandal
#

huh

#

that worked

#

so a debugger needs to read a second copy of the library to actually load shit in?

sour flame
#

unlike windows, linux programs usually don't ship with .so files in their directory so no debugger would check there, theyd just check the system paths

sour flame
#

like maybe in theory it could just read the exe and loaded libraries from memory but there's probably a reason it can't or doesn't want to

sullen sandal
#

doesnt seem to work on lldb though

image.png
#

ech

#

either that or theres a different command for that

unkempt terrace
#

I wonder why I haven't had to do that for cmake built binaries, does it automatically set rpath for debug builds or something?

sullen sandal
#

"settings set target.exec-search-paths ${workspaceFolder}/zig-out/lib"

#

worked

unkempt terrace
#

maybe another addLibraryPath with ext/ would allow it to work automatically?

sullen sandal
#

no clue
but it functions now so w/e