How to build darwin target with debugging symbols?

[floatingstone]

Hello, I am trying to build the darwin target using make darwin CLEAN=yes RELEASE=no INSPECTOR=yes, but there are no debugging symbols:

file build/targets/darwin/libTransmuteCore.dylib build/targets/darwin/transmute_browser

build/targets/darwin/libTransmuteCore.dylib: Mach-O 64-bit dynamically linked shared library arm64
uild/targets/darwin/transmute_browser: Mach-O 64-bit executable arm64

Do we need any other configurations here?

Thanks!

[yorkie]

It is true that the files currently output by file do not display debugging information. However, could you specify the issue you are encountering? At present, JSAR prints the call stack upon process crash at src/common/debug.cpp, and on macOS, it is able to correctly display the symbols.

[floatingstone]

It is true that the files currently output by file do not display debugging information. However, could you specify the issue you are encountering? At present, JSAR prints the call stack upon process crash at src/common/debug.cpp, and on macOS, it is able to correctly display the symbols.

Thanks for your reply, :). I want to debug in VSCode IDE, it seems impossible to attach a breakpoint when transmute_browser is running for now.

[yorkie]

@floatingstone This approach is feasible (although there is no debug information, it is still possible to troubleshoot some common issues). I am able to use lldb for debugging on my MacBook.

lldb ./build/output/release/universal-apple-darwin/transmute_browser
> run /Users/yorkie/workspace/jsar-runtime/fixtures/html/document.html

Process 89635 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x000000018452ce68 libsystem_kernel.dylib`__semwait_signal + 8
libsystem_kernel.dylib`:
->  0x18452ce68 <+8>:  b.lo   0x18452ce88               ; <+40>
    0x18452ce6c <+12>: pacibsp 
    0x18452ce70 <+16>: stp    x29, x30, [sp, #-0x10]!
    0x18452ce74 <+20>: mov    x29, sp
Target 0: (transmute_browser) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x000000018452ce68 libsystem_kernel.dylib`__semwait_signal + 8
    frame #1: 0x000000018440c2f8 libsystem_c.dylib`nanosleep + 220
    frame #2: 0x000000018449f81c libc++.1.dylib`std::__1::this_thread::sleep_for(std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l>> const&) + 84
    frame #3: 0x00000001002d2484 transmute_browser`void std::__1::this_thread::sleep_for[abi:v160006]<long long, std::__1::ratio<1l, 1000000l>>(std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000l>> const&) + 152
    frame #4: 0x00000001002d2020 transmute_browser`jsar::example::TransmuteBrowser::start() + 264
    frame #5: 0x00000001002b47d8 transmute_browser`main + 116
    frame #6: 0x00000001841e90e0 dyld`start + 2360

If you wish to use VSCode for debugging, you will need to configure a launch.json file yourself.

[yorkie]

Sorry, I overlooked the fact that you need to set breakpoints. I have created a new PR(#383) to support dSYM output, and you can also follow the progress of this PR.

[floatingstone]

Sorry, I overlooked the fact that you need to set breakpoints. I have created a new PR(#383) to support dSYM output, and you can also follow the progress of this PR.

I just updated the code and found that it can now be debugged using VSCode ("cwd": "${workspaceFolder}").

I tried about a month and a half ago, and it couldn't be debugged at that time. The main differences between now and before are VSCode version, MacOS version, and the code repository commit ID.

In the morning, I only checked if the debugging symbol table was included using file shell command, and didn't update the cwd configuration item(the old value is "${workspaceFolder}/build/output/release/universal-apple-darwin") in launch. json under VSCode.

But anyway, supporting dSYM may indeed be better, for example, the "cwd" mentioned above is not sure how to set it up without seeing debugging information.

[yorkie]

@floatingstone Thanks for your sharing, and in #383, libTransmuteCore.dylib.dSYM can already be generated, and when loading with lldb, it no longer warns that the symbol table is empty. You can give it a try.

I also assigned Copilot adding a built-in launch.json to support direct debugging with VSCode, but this is limited to the server-side part. Since the application process is forked as a separate process, using lldb for debugging it may still be quite challenging.

[floatingstone]

@floatingstone Thanks for your sharing, and in #383, libTransmuteCore.dylib.dSYM can already be generated, and when loading with lldb, it no longer warns that the symbol table is empty. You can give it a try.

Thanks! I tried "Debug transmute_browser" and the browser can be debugged.

I also assigned Copilot adding a built-in launch.json to support direct debugging with VSCode, but this is limited to the server-side part. Since the application process is forked as a separate process, using lldb for debugging it may still be quite challenging.

The attach debugging type in VSCode works for transmute_client proces, which I find you have added to the launch.json in the above commit, :). If we want to debug the logic related to startup, some auxiliary code can be added.