Clang on Windows breaks debugger symbols

[angelfor3v3r]

I'm doing static builds on Windows using the Clang compiler but my debug symbols are broken because the Library does this stuff:
https://github.com/bitdefender/bddisasm/blob/master/CMakeLists.txt#L47-L76

Specifically, it adds stuff like:

        -fstack-protector-strong
        -fno-omit-frame-pointer
        -ffunction-sections
        -fdata-sections
        -g3
        -gdwarf-4
        -grecord-gcc-switches
        -march=native

As compile options, which conflict with my own debug format on my own target. Yet, When targeting Windows MSVC it only adds stuff like: /W4 /WX, which wont conflict with other compiler options (since the lib file is using different options). Specifically, the one causing it is -gdwarf-4 but the other options (like -march=native) make me scared that it'll ruin static builds if I try to release binaries of my own apps.

Would it make more sense for the main library target to only add compile options for warnings and all that?

[ianichitei]

You are right, we set some flags that should be set only by consumers of the library. I'm assuming you're not using the pre-built binaries.

Can you post your build setup (or just a minimal example), together with the error you're getting? Mixing different debug formats should work.

[angelfor3v3r]

Sure. Here is a CMakeLists.txt and a src/main.cpp file. I use CPM and static builds.

cmake_minimum_required(VERSION 3.20)

project(bddisasm-issue)

if (NOT WIN32)
    message(FATAL_ERROR "${PROJECT_NAME}: Unsupported operating system (Windows only).")
elseif (NOT CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
    message(FATAL_ERROR "${PROJECT_NAME}: Unsupported compiler (Clang only).")
endif ()

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(BUILD_SHARED_LIBS OFF)
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

include(third_party/cmake/get_cpm.cmake)
CPMAddPackage(URI "gh:bitdefender/bddisasm@3.0.0" OPTIONS "BDD_INCLUDE_TOOL OFF" "BDD_INCLUDE_ISAGENERATOR_X86 OFF")

add_library(test-dll SHARED src/main.cpp)
target_compile_features(test-dll PRIVATE cxx_std_23)
target_compile_definitions(test-dll PRIVATE NOMINMAX UNICODE _UNICODE)
target_include_directories(test-dll PRIVATE src)

# Debug options
target_compile_options(test-dll
    PRIVATE
    -Wall
    -Wextra
    -Wshadow
    -pedantic
    -Werror=unused-variable
    -Wno-non-virtual-dtor
    -Wno-unused-parameter
    -Wno-unused-private-field
    -Wno-cast-function-type
    -Wno-missing-designated-field-initializers
    -g
    -O0)
target_link_libraries(test-dll PRIVATE bddisasm::bddisasm)

#include <bddisasm_types.h>
#include <bddisasm.h>
#include <cstdint>

std::int32_t main(std::int32_t argc, char *argv[], char *envp[])
{
    ND_CONTEXT ctx;
    NdInitContext(&ctx); // Once this line exists and is compiled, the issue happens.

    ctx.DefCode  = ND_CODE_64;
    ctx.DefData  = ND_DATA_64;
    ctx.DefStack = ND_STACK_64;
    ctx.VendMode = ND_VEND_ANY;
    ctx.FeatMode = ND_FEAT_ALL;

    return 0;
}

My debugger (LLDB with CLion) fails to hit breakpoints because I assume it's mixing debug formats or something:

lld-link: warning: section name .debug_abbrev is longer than 8 characters and will use a non-standard string table
lld-link: warning: section name .debug_info is longer than 8 characters and will use a non-standard string table
lld-link: warning: section name .debug_line is longer than 8 characters and will use a non-standard string table
lld-link: warning: section name .debug_ranges is longer than 8 characters and will use a non-standard string table
lld-link: warning: section name .debug_str is longer than 8 characters and will use a non-standard string table

I use CMake, Ninja and Clang on Windows:

ninja --version
1.13.1

cmake --version
cmake version 4.0.3

clang version 19.1.5
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\bin

I'm also scared that the lib file has all the other options enabled on it, which could cause issues in the future for me.

If you have any ideas, please let me know. Thank you 😃

[ianichitei]

That lld-link warning should be harmless, it was introduced due to a dumpbin bug, see https://reviews.llvm.org/D69594.

Some options are indeed problematic and I will remove them (like -march=native).

I modified your example to build an executable (test-exe) so debugging is easier. I can debug it with both WinDbg and lldb 20.1.0 (I did a simple test: break set -n NdDecodeWithContext and frame variable once that breakpoint is hit).

Note that test-exe will have the bddisasm.lib symbols embedded, but a test-exe.pdb will also be generated. Without this PDB you can debug the bddisasm.lib code freely, but you will have no visibility into test-exe itself.

$ llvm-objdump.exe -h .\test-exe.exe

.\test-exe.exe: file format coff-x86-64

Sections:
Idx Name          Size     VMA              Type
  0 .text         000a3706 0000000140001000 TEXT
  1 .rdata        0010605c 00000001400a5000 DATA
  2 .data         00004e00 00000001401ac000 DATA
  3 .pdata        00007f8c 00000001401b3000 DATA
  4 .00cfg        00000028 00000001401bb000 DATA
  5 .voltbl       0000005e 00000001401bc000
  6 _RDATA        000000fc 00000001401bd000 DATA
  7 .rsrc         000001a8 00000001401be000 DATA
  8 .reloc        000062ac 00000001401bf000 DATA
  9 .debug_abbrev 000005cd 00000001401c6000 DATA, DEBUG
 10 .debug_info   00047e04 00000001401c7000 DATA, DEBUG
 11 .debug_line   00006246 000000014020f000 DATA, DEBUG
 12 .debug_ranges 000003b0 0000000140216000 DATA, DEBUG
 13 .debug_str    00081a92 0000000140217000 DATA, DEBUG

$ dumpbin /PDBPATH:VERBOSE .\test-exe.exe
Microsoft (R) COFF/PE Dumper Version 14.29.30159.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file .\test-exe.exe

File Type: EXECUTABLE IMAGE
  PDB file found at 'C:\work\113\build\test-exe.pdb'

  Summary

        1000 .00cfg
        7000 .data
        1000 .debug_abbrev
       48000 .debug_info
        7000 .debug_line
        1000 .debug_ranges
       82000 .debug_str
        8000 .pdata
      107000 .rdata
        7000 .reloc
        1000 .rsrc
       A4000 .text
        1000 .voltbl
        1000 _RDATA

Now, if I build both the lib and the exe with -gcodeview (which is the default if no other flag is specified in this case) all I have is a PDB and that should be enough (WinDbg loads it without any issues). However, I can not make lldb load it (not even for a simple hello world program) and this might be what's preventing you from debugging your code as well. Try using -gdwarf-4 for your code as well in the meantime and see if that works.

[angelfor3v3r]

Thanks for the info! It definitely seems like I need to have gdwarf-4 for my breakpoints to get hit (I'm compiling my own DLL file on Windows).

There are my current compiler options:

target_compile_options(foo
        PRIVATE
        -Wall
        -Wextra
        -Wshadow
        -pedantic
        -Werror=unused-variable
        -Wno-non-virtual-dtor
        -Wno-unused-parameter
        -Wno-unused-private-field
        -Wno-cast-function-type
        -Wno-missing-designated-field-initializers
        -gdwarf-4
        -g
        -O0)

And my breakpoints get hit again using CLion's LLDB stuff.

[ianichitei]

I'm glad that debugging now works. The core issues you have raised are still valid and should be fixed by #114.

[ianichitei]

Just commenting to add some information. I managed to get lldb 21.1.1 to load PDBs by setting the LLDB_USE_NATIVE_PDB_READER env variable to yes.