Building libunwind for wasm32 NDEBUG is not defined causing inclusion of logAPIs symbol

[HaydnTrigg]

I am building a modified libunwind against a wasm32 target with the RelWithDebugInfo build type.

When linking I get the following error:

1>wasm-ld : error : wasi-sysroot-17.0/wasi-sysroot/lib\libunwind.a(Unwind-wasm.c.o): undefined symbol: logAPIs

Inside of Unwind-wasm.c there is usage of the _LIBUNWIND_TRACE_API which is only supposed to use the function logAPIs in a debug build of libunwind.

I have tracked down the issue looking at the command invocation that CMake is not supplying the NDEBUG macro by default. This causes the _LIBUNWIND_TRACE_API macro to be defined causing the inclusion of the logAPIs symbol.

There is a bit of nonsense inside of the libunwine CMake file that doesn't make a lot of sense to me and I think it might be wrong. The following code block

# Assert
string(TOUPPER "${CMAKE_BUILD_TYPE}" uppercase_CMAKE_BUILD_TYPE)
if (LIBUNWIND_ENABLE_ASSERTIONS)
  # MSVC doesn't like _DEBUG on release builds. See PR 4379.
  if (NOT MSVC)
    add_compile_flags(-D_DEBUG)
  endif()

  # On Release builds cmake automatically defines NDEBUG, so we
  # explicitly undefine it:
  if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
    add_compile_flags(-UNDEBUG)
  endif()
else()
  if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
    add_compile_flags(-DNDEBUG)
  endif()
endif()

The statement that CMake automatically defined NDEBUG appears to not always be true. And assuming that might actually be the case. The very last branch statement is supposed to add the NDEBUG flag, but the statement will only add that if the build is a debug build, which seems wrong. Should a debug build actually be defining NDEBUG?

I changed the statement from if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") to if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") and that has resolved the issue of NDEBUG missing from the define statements on the command line.

I'm not aware of any knock on effects that might have and I'm not aware of why libunwind would not have NDEBUG defined for it already by default if that is intended default behavior. But I figure I'd open this issue to raise my observations.

Alternatively, would it make more sense to change the #ifdef statement in config.h from using NDEBUG to checking for the presence of DEBUG instead?

I have an easy workaround that is simply manually defining NDEBUG to appear on the command line through CMAKE_***_FLAGS.

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

[aheejin]

First off, this Unwind-wasm.c file has not been upstreamed to this llvm-project repo, so I'm not sure if this is the best place to file this issue.

That file was added in Emscripten, and it looks at some point it was ported to wasi-sdk in WebAssembly/wasi-sdk#198 (which hasn't been merged though), and you are using that port, right?

In Emscripten, we currently don't build libunwind in debug mode. We only build a part of our libraries in debug mode because of code size concerns, and we manually control which libraries to build in debug mode in our Python config script, and libunwind is currently not one of them. So the code will need some modification if you want to build libunwind with Unwind-wasm.c in debug mode, which I think is the problem you encountered. It looks the logAPIs method is in libunwind.cpp:

llvm-project/libunwind/src/libunwind.cpp

Lines 358 to 368 in 7f56488

	_LIBUNWIND_HIDDEN
	bool logAPIs() {
	// do manual lock to avoid use of _cxa_guard_acquire or initializers
	static bool checked = false;
	static bool log = false;
	if (!checked) {
	log = (getenv("LIBUNWIND_PRINT_APIS") != NULL);
	checked = true;
	}
	return log;
	}

Emscripten is not currently building this file as a part of libunwind, because it doesn't build it in debug mode. Adding this file in Emscripten's libunwind build will cause some additional compilation errors, which can be fixed. But I'm not sure what your build environment is in the first place. It doesn't seem that you are using Emscripten, and I'm not very familiar with how to use the wasi port (WebAssembly/wasi-sdk#198). Perhaps it would be better to file an issue there..?