Unable to debug on macOS

[rjpontefract]

Running SE 29 on macOS 15.1 on ARM.

I used to be able to debug single file projects written in C/C++ using LLDB.  I tried to use this today and the debugger starts, the application runs but no breakpoints are hit.  I tried it with a single file project and with a larger project with a workspace and neither works.  I tried using a clean configuration which made no difference.  LLDB works fine from the command line, as does debugging using LLDB in VSCode.

Any help would be appreciated.

[rjpontefract]

Well that's disappointing, I at least expected some sort of suggestion of things to try.

[Clark]

Here's the fix for getting SlickEdit's LLDB debugging working on Sequoia with Xcode 16 (clang 16):
 
* Open your SlickEdit LLDB Workspace/Project
* Go to Project>Properties
* Select the Tools Tab
* Select the Compile tool
* Select the "Debug" configuration
* Click on "Options..."
* Select the Compile tab
* Set "Other Options:" to -fdebug-default-version=4
* Press OK on the clang++ Options dialog
* Press OK on the Project Properties dialog
* Rebuild or Build your application

[rjpontefract]

Thank you, it's very much appreciated.

[Clark]

A hot fix is available for this (hot fix 1 for v29). The hot fix automatically adds this clang compiler option if necessary.

You can download the hot fix from here:

https://www.slickedit.com/hotfixes

Then load the hot fix: Help>Product Updates>Load Hot Fix...

Build or Rebuid your application after loading the hot fix and restarting SlickEdit.

[PaulElliott]

Hi all,
The above manual instructions do not seem to work for me (debug breakpoints still don't catch) on v28. Is this to be expected, and we have to upgrade to v29 to fix?

[Clark]

Hi all,
The above manual instructions do not seem to work for me (debug breakpoints still don't catch) on v28. Is this to be expected, and we have to upgrade to v29 to fix?

Make sure you clear out the following setting:

Tools>Options>Debugging>General>Debug Server executable

Restart SlickEdit before trying to debug.

[PaulElliott]

Make sure you clear out the following setting:
Tools>Options>Debugging>General>Debug Server executable
Restart SlickEdit before trying to debug.

Hi Clark, definitely done that, I wasn't even able to start debugging until that was done, and that definitely fixes that, many thanks with your help catching that.

Now when I start debugging, the executable just runs straight through and no breakpoints catch. I have followed the instructions above on the clang project, checked that -fdebug-default-version=4 is definitely included on the build command line, however no breakpoints set in the editor are caught, the same symptoms as described in the initial post.

The only major difference here is that I am running v28 (hence no hot fix, so using the manual instructions). My question therefore, is whether or not this fix is expected to work in v28 with apple clang 16, or whether upgrading to v29 is required here.

[Clark]

Upgrading to v29 shouldn't be required. The only change in v29 is automation for adding the extra compile option.

Make sure you build the Debug config and not Release. Build>Set Active Configuration

Debug won't work in a Release config

[PaulElliott]

Yep, definitely building debug, like I say, I can see the option on the build command line.

Only major difference then is I am running 15.2, but its still Apple clang version 16.0.0 (clang-1600.0.26.6) - I'm not entirely sure there was an upgrade.

Looks like I need to do some elf Mach-O analysis in the morning. Any hints and tips on this would be greatly appreciated, I know my way around an elf file, but but new on Mach-O.

[Clark]

Have you tried debugging with the clang sample?

Project>All Workspaces>Sample Workspaces>clang.vpw

[PaulElliott]

This was with the clang workspace, my other projects are too complex for simple tests / built externally.

This was extremely curious. It didn't work until I started messing around with dsymutil on clang_prog, trying to ascertain what debug version it was using. At some point during this, breakpoints started catching again. I have since tried to break this by removing the files that this produces, but to no avail. For now, I will just take the win I think.

I will report back if I can find anything more on this, given many of my projects are being built externally with cmake, this is still something of an issue which won't get resolved with the hotfix either.

[Clark]

glad this works for you.

v30 there will have support for CMake's new file API. It's really good. Much better and more convenient that the old cmake support. Although you will have to manually change the compiler options if you want to be able to debug on macOS. No way to automate that.

[rjpontefract]

There seems to be an issue on macOS where existing breakpoints don't work when a file is restored after restarting SE.  If I remove and re-add a breakpoint it works as expected.