Missing debug information when stepping into V8 code

[stroiman]

I tried compiling a local version with debug following the instructions in the readme.

But while I would get proper debug information in the v8go C++ code, I didn't get that when calling into V8 C++ code. When inspecting a v8go function in the callstack

But here, it's called into V8

So there is some information as comments in the assembly view - which could somewhat be used to identify the rough location. It also shows the name of the function being called.

This is observed on Apple silicon, with M2 max.

I can confirm that the ldflags=-compressdwarf=false option has an effect, without it the v8go C++ code didn't have proper debug info either. I'm mentioning this as the readme file says "You may need to". So at least on this platform, it is still a necessity.

[stroiman]

Or output from bt - C++ line numbers in v8go - no line numbers in V8 (I have no idea how to interpret + 296 / + 96)

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010187dd0c v8go.test`v8::ScriptCompiler::CompileUnboundInternal(v8::Isolate*, v8::ScriptCompiler::Source*, v8::ScriptCompiler::CompileOptions, v8::ScriptCompiler::NoCacheReason) + 296
    frame #1: 0x000000010187e38c v8go.test`v8::ScriptCompiler::CompileModule(v8::Isolate*, v8::ScriptCompiler::Source*, v8::ScriptCompiler::CompileOptions, v8::ScriptCompiler::NoCacheReason) + 96
    frame #2: 0x00000001002ce5c8 v8go.test`ScriptCompilerCompileModule(ctx=<unavailable>, s=<unavailable>, o=<unavailable>) at script_compiler.cc:99:8 [opt]
    frame #3: 0x00000001002c77bc v8go.test`_cgo_d519e780b97c_Cfunc_ScriptCompilerCompileModule(v=0x0000014000069d98) at cgo-gcc-prolog:56:35 [opt]
    frame #4: 0x000000010007e35c v8go.test`runtime.asmcgocall.abi0 at asm_arm64.s:1000
(lldb)

[tommie]

We're not setting --debug when building:

v8go/.github/workflows/v8build.yml

Line 165 in b563a19

run: cd deps && ./build.py --ccache --verbose --arch ${{ matrix.arch }} --os ${{ matrix.os }}

There's no debug info:

$ objdump -C -g deps/linux_amd64/libv8-2.a
In archive deps/linux_amd64/libv8-2.a:

363.keys.o:     file format elf64-x86-64

364.literal-objects.o:     file format elf64-x86-64
...

However, each deps/* directory is already ~100 MiB in size, and I'd be rather worried about adding even more there. The Go proxy downloads the entire repository, and we doing a git pull is already slow. I had to start splitting the .a files due to the 100 MiB GitHub file size limit. (I believe every dependent on v8go also has to download all platforms, because go.mod doesn't have granular dependencies.)

I'm not really sure what the solution is, but as long as the compiled libv8 are stored on GitHub, I doubt we'll publish debug symbols.

[stroiman]

I had build it locally with deps/build.py --debug as the readme instructed under "Recompile V8 with debug info and debug checks". And I also had some debug information, as I could see see the function name in the call stack.

But as the ldflags=-compressdwarf=false had an effect on the C++ code from v8go - I could guess that something similar isn't configured when compiling V8 from sources?

But while I have some ancient knowledge of the C++ language, I have zero knowledge of modern compilers and tools

[stroiman]

And no - debug information should most certainly NOT be included in the release version.

[stroiman]

Regarding size of the repository - could it be possible to have a separate github repo and go package for the compiled binaries? Something like github.com/tommie/v8go-binaries

My experimental fork that my browser depends on is renamed to github.com/gost-dom/v8go - but it still depends on github.com/tommie/v8go/deps/...

So I'm kinda doing that

An example go.mod from a project using gost-dom shows that it includes v8go from my fork, but v8 builds from yours.

require (
	github.com/gost-dom/browser v0.5.7
)

require (
	github.com/gost-dom/v8go v0.0.0-20250226155312-422158da51fa // indirect
	github.com/tommie/v8go/deps/android_amd64 v0.0.0-20250402043228-5f86851c373c // indirect
	github.com/tommie/v8go/deps/android_arm64 v0.0.0-20250402043228-5f86851c373c // indirect
	github.com/tommie/v8go/deps/darwin_amd64 v0.0.0-20250402043228-5f86851c373c // indirect
	github.com/tommie/v8go/deps/darwin_arm64 v0.0.0-20250402043228-5f86851c373c // indirect
	github.com/tommie/v8go/deps/linux_amd64 v0.0.0-20250402043228-5f86851c373c // indirect
	github.com/tommie/v8go/deps/linux_arm64 v0.0.0-20250402043228-5f86851c373c // indirect
)

[tommie]

I had build it locally with deps/build.py --debug as the readme instructed under "Recompile V8 with debug info and debug checks". And I also had some debug information, as I could see see the function name in the call stack.

Oh, sorry. I read your first sentence, and then forgot about it!

What does objdump -C -g deps/darwin_arm64/libv8-2.a say? Does it list anything? The public function names are present since they're in the symbol table for linking, and since everything it split into tiny little .o files, sadly everything except inline functions will be public... The drawback of static archives and small source files. Perhaps there's a way to prelink that into aggregate .o files, to reduce the symbol table size.

could it be possible to have a separate github repo and go package for the compiled binaries? Something like github.com/tommie/v8go-binaries

Yeah, now that they are separate packages (IIRC to work around Go proxy size limitations), it could easily be a separate repo. I'd have to think that through a bit more, but my main issue is that it still downloads all platforms...