enhancement : support building in debug mode

[SleathCobra]

Hey i thought it would be great and help during developement/testing if the cmakelists allowed for building in debug mode

Here's my code changes, that allowed me to build in debug mode

CMakeLists.txt - lines 99-106

if(TARGET capstone)
    if(MSVC)
        target_compile_options(capstone PRIVATE "$<$<NOT:$<CONFIG:Debug>>:/O2>")
    else()
        target_compile_options(capstone PRIVATE "$<$<NOT:$<CONFIG:Debug>>:-O3;-fomit-frame-pointer>")
    endif()
    target_compile_definitions(capstone PRIVATE "$<$<NOT:$<CONFIG:Debug>>:NDEBUG>")
endif()

lib/decode/CMakeLists.txt - line 16

 target_compile_options(NeverDDecode PRIVATE "$<$<NOT:$<CONFIG:Debug>>:/O2>")

Also i saw your earlier message on a closed issue on mine, I appreciate your offer ;) but you don't have to pay me anything it's okay. I'm really interested in this tool , and i would love to help you push it forward !

[NeverSightAI]

Thanks for the report and the suggested CMake change. You were right that Debug wasn’t honoring normal Debug semantics for the Capstone / NeverDDecode hot paths.

We’ve landed a fix along those lines:

• Capstone only gets the forced opts + NDEBUG in non-Debug configs
• NeverDDecode does the same on both the MSVC and GCC/Clang branches
• Generator expressions so it works for single- and multi-config generators
• A CI check that configures real Debug/Release trees and asserts the compile flags

One note on intent: we still keep those hot paths optimized in Release / RelWithDebInfo (decode throughput matters there). For day-to-day debugging, use Debug; if you want symbols and fast decode, prefer RelWithDebInfo.

Appreciate you pushing this forward. This should be fixed on dev in 7d011de: Capstone and NeverDDecode no longer force release opts / NDEBUG under Debug, so a normal Debug build should work as expected.

Mind giving it a try when you have a chance? If anything still looks off, let us know.

[tomrus88]

There's still an issue with debug mode on windows: PDB files generated for neverd.exe and neverd.dll have same name (neverd.pdb) and that causes conflict where one pdb overwrites another and debugger will be unable to load correct pdb's...