Just bought codeclap 0.9.1. I tried to debug a simple program but I can only step through assembly (even though the Source view is selected).
The Working Directory is set to where the executable is (absolute path).
The program breaks in assembly in /usr/lib/dyld after start. I tried putting "main", also "main.c:7", in "Break at function/file:line:" and of course it doesn't break there, "Continue" just falls through.
I verified my binary has correct debug symbols with source line info and I can step through the sources with lldb just fine.
I'm on macOS 10.15.1, my program is built with Apple clang version 11.0.0 (clang-1100.0.33.8).
Best regards,
Tomek
P.s. Just noticed I can't close the window :( the red button on the title bar is greyed out, only Cmd+Q works.
The Working Directory is set to where the executable is (absolute path).
The program breaks in assembly in /usr/lib/dyld after start. I tried putting "main", also "main.c:7", in "Break at function/file:line:" and of course it doesn't break there, "Continue" just falls through.
I verified my binary has correct debug symbols with source line info and I can step through the sources with lldb just fine.
I'm on macOS 10.15.1, my program is built with Apple clang version 11.0.0 (clang-1100.0.33.8).
Best regards,
Tomek
P.s. Just noticed I can't close the window :( the red button on the title bar is greyed out, only Cmd+Q works.
Edited by Tomek Sowiński
on
Reason: Can't close window:(
Hi there,
Thanks for reminding me of that. I never enabled the close button because commonly macOS has the concept that the running application (or service) is more that just the window and keeps running while you can have multiple windows open with different states. While at the moment one running instance basically equals one open window and it is not possible to only close this window but only the application as a whole. But there should be a way to make the close button behave reasonable and it may be confusing to have it disabled.
Knowing the exact situation here is probably key to find a permanent fix.
There are a few things that I would guess based on this information. First of all, is it possible that you may not have xcode installed at all? When only the command line tools are installed there seem to be slight differences in the final compilation output. Also "com_apple_xcode_dsym_uuids" seems to be missing in this case which makes locating the dSYM using this attribute impossible (which is one of the ways codeclap does find the correct dSYM at the moment).
Is the .dSYM bundle in the same directory as the binary? lldb seems to be able to find the dSYM even in other directories and even if com_apple_xcode_dsym_uuids is missing.
What you can try regardless of the other questions: Start your application and open the "Modules" panel (in the "Windows" menu). In this panel there should be 2 entries. One is dyld and the other one should be your own binary (if it is missing here then there is a problem). In your situation the "Debug Information" column should end with "(none)". Right click this row, click "Locate debug information" and select the correct .dSYM from your file system. After that try to manually place a breakpoint (for example in main).
tomeksowi
P.s. Just noticed I can't close the window :( the red button on the title bar is greyed out, only Cmd+Q works.
Thanks for reminding me of that. I never enabled the close button because commonly macOS has the concept that the running application (or service) is more that just the window and keeps running while you can have multiple windows open with different states. While at the moment one running instance basically equals one open window and it is not possible to only close this window but only the application as a whole. But there should be a way to make the close button behave reasonable and it may be confusing to have it disabled.
tomeksowi
The Working Directory is set to where the executable is (absolute path).
The program breaks in assembly in /usr/lib/dyld after start. I tried putting "main", also "main.c:7", in "Break at function/file:line:" and of course it doesn't break there, "Continue" just falls through.
I verified my binary has correct debug symbols with source line info and I can step through the sources with lldb just fine.
Knowing the exact situation here is probably key to find a permanent fix.
There are a few things that I would guess based on this information. First of all, is it possible that you may not have xcode installed at all? When only the command line tools are installed there seem to be slight differences in the final compilation output. Also "com_apple_xcode_dsym_uuids" seems to be missing in this case which makes locating the dSYM using this attribute impossible (which is one of the ways codeclap does find the correct dSYM at the moment).
Is the .dSYM bundle in the same directory as the binary? lldb seems to be able to find the dSYM even in other directories and even if com_apple_xcode_dsym_uuids is missing.
What you can try regardless of the other questions: Start your application and open the "Modules" panel (in the "Windows" menu). In this panel there should be 2 entries. One is dyld and the other one should be your own binary (if it is missing here then there is a problem). In your situation the "Debug Information" column should end with "(none)". Right click this row, click "Locate debug information" and select the correct .dSYM from your file system. After that try to manually place a breakpoint (for example in main).
spx
Thanks for reminding me of that. I never enabled the close button because commonly macOS has the concept that the running application (or service) is more that just the window and keeps running while you can have multiple windows open with different states. While at the moment one running instance basically equals one open window and it is not possible to only close this window but only the application as a whole. But there should be a way to make the close button behave reasonable and it may be confusing to have it disabled.
Well, that concept of "application is more than a window" isn't adhered to staunchly by Apple themselves. Newer one-window apps like Note, AppStore or Font Album just close with the window. I think Windows-like behavior for the close button is warranted for c[ode]clap.
spx
There are a few things that I would guess based on this information. First of all, is it possible that you may not have xcode installed at all? When only the command line tools are installed there seem to be slight differences in the final compilation output. Also "com_apple_xcode_dsym_uuids" seems to be missing in this case which makes locating the dSYM using this attribute impossible (which is one of the ways codeclap does find the correct dSYM at the moment).
No, I have both Xcode GUI and the command line tools installed.
spx
Is the .dSYM bundle in the same directory as the binary? lldb seems to be able to find the dSYM even in other directories and even if com_apple_xcode_dsym_uuids is missing.
What you can try regardless of the other questions: Start your application and open the "Modules" panel (in the "Windows" menu). In this panel there should be 2 entries. One is dyld and the other one should be your own binary (if it is missing here then there is a problem). In your situation the "Debug Information" column should end with "(none)". Right click this row, click "Locate debug information" and select the correct .dSYM from your file system. After that try to manually place a breakpoint (for example in main).
That was it, no .dSYM along-side the binary. If clang creates it, a find on my entire filesystem didn't locate it. Perhaps lldb just generates the .dSYM on the fly from the debug binary. From a quick online inquiry I found some info that Apple's clang generates the .dSYM when the program is compiled in one step, but a regular "compile objects then link binary" build flow (my case) doesn't. Generating it like that solved the problem:
1 | dsymutil <compiled binary> |
Thanks for your support, c[ode]clap looks pretty good now!
Edited by Tomek Sowiński
on
tomeksowi
No, I have both Xcode GUI and the command line tools installed.
That was it, no .dSYM along-side the binary. If clang creates it, a find on my entire filesystem didn't locate it. Perhaps lldb just generates the .dSYM on the fly from the debug binary. From a quick online inquiry I found some info that Apple's clang generates the .dSYM when the program is compiled in one step, but a regular "compile objects then link binary" build flow (my case) doesn't.
Oh well, I tried :).
Interesting, I only knew of the "one-step" behavior which generates the .dSYM for you automatically; always got one, even when mixing pre-compiled object files and source files in a later step. Also wasn't aware that lldb can function without it (either by reading the debug information directly or by generating it on-the-fly). Will see if I can provide support for this in a later update.
Thank you for looking into this.
Edited by spx
on