I have a project for Mac OS X 10.5 that I'm building on 10.6 using Xcode 3.2. When I use GCC 4.2 for Debug build and hit a breakpoint, Xcode debugger displays local variable information normally. If I choose LLVM GCC 4.2 or Clang LLVM, when I hit breakpoint, local symbols are not available, and GDB says No symbol 'self' in current context if I try to print self or any other local symbol. In all cases Generate debug info option is set. The Debug configuration is set to $(NATIVE_ARCH) and 10.5 SDK, Build active architecture only option is set. When GDB starts, I can see it is being configured as x86_64-apple-darwin. I must be missing something obvious. How do I make GDB show local symbols when using a LLVM compiler?
For those not familiar, a little more detail to cdespinosa's answer, which worked for me, and which I voted up.
From the Xcode menu, select Project > Edit Project Settings...
Choose the Build tab
In the search box type "Optimization Level", choose that field, and select None.
Next search for "Debug Information Format", choose that field, and select "DWARF" or "DWARF with dSYM".
Would have put this in comments to his post if I had the privs. ;)
This cost me some serious time, and was frankly kind of sloppy on Apple's part, but in general I can't complain.
Make sure you're building with Dwarf symbols and no optimization. llvm is a new back-end, and not all of its optimized codegen is hooked up to debug symbol generation yet.
This may help. Try turning off "Link-Time Optimization" in the project's build options. That fixed a problem I had with missing debug symbols.
In fact, that fixed a bunch of weird problems I was having with Clang. I'd say that feature is just too bleeding edge to use yet.
GDB from FSF only added support for JIT code very recently.
I don't know whether Apple-supplied GDB has support for it at all (do you get reasonable stack traces?). If it does, this support is (apparently) incomplete.
I was having this problem and solved it by putting a tick next to the menu item: "Project > Set Active Build Configuration > Debug". Previously, the "Release" option was selected. Locals started showing up in the debugger for my project from then on.
Related
I'm trying to debug an executable which has been created with CMake configuration
SET(CMAKE_BUILD_TYPE Debug)
However, CLion does not hit any breakpoints. What could be the problem?
I had the same issue today. I figured out that the configuration for the project was not set to Debug. After setting the configuration to Debug all the breakpoints are hit.
Please ensure that you have following configuration:
Select the MenuItem Run/EditConfigurations
Select the right Target
Select Debug as Configuration
Now the breakpoints should be hit.
In case this helps someone else, it turned out that my (somewhat embarrassing) issue was that I was hitting Run instead of Debug. So in the Run menu don't use the play icon, instead choose the cute bug icon instead. Choosing Run was causing it to automatically build the non-debug build so breakpoints wouldn't work. Once I started choosing the bug icon, the breakpoints worked like a charm.
As it has turned out, the executable was compiled with following CMake options (further down in the script):
SET(CMAKE_C_FLAGS_DEBUG "-D_DEBUG")
This was breaking debug functionality for CLion (it was also breaking most of the debug functionality of gdb)
I also had the same Problem. Since 2016.3 CLion changed the CMake workflow so that only one configuration is allowed at one time clion new workflow
The solution is File -> Settings -> Build, Excution, Deployment -> change the build configuration
In my case my CMake option CMAKE_BUILD_TYPE was already set to DEBUG on CMake Settings. However, it was the command set(CMAKE_BUILD_TYPE Release) in the CMakeLists.txt, which was merged by git pull and overrode the CMake Settings while execution. I could not figure out earlier as CMake Debug console was showing -DCMAKE_BUILD_TYPE=Debug
When I changed it to set(CMAKE_BUILD_TYPE Debug) breakpoints were hit again.
In case this helps someone else:
In my case I had to set the -DCMAKE_BUILD_TYPE option to Debug explicitly in Settings -> Build, Execution, Deployment -> CMake
I had a different issue that caused my breakpoints not to be hit. I develop both embedded apps and native MacOS console apps with CLion. For the embedded work, GDB needs to be set for your selected Preferences/Toolchains.
For debugging console apps LLDB needs to be selected in Preferences/Toolchains. If it is left on GDB, my breakpoints don't work. Set to LLDB here:
I had a comma in my project path. Removing the comma fixed the problem for me.
In 2019.3, it turns out to be CLion/Preference/Build,Execution,Deployment/CMake/Build type/Debug.
My problem was with the -ffile-prefix-map flag. Once I removed it, everything worked fine.
See https://youtrack.jetbrains.com/issue/CPP-23159 and https://youtrack.jetbrains.com/issue/CPP-15850
I had the same issue. I noticed that every time I click the debug option, the "Antimalware Service Executable" process starts. I created an exclusion for MinGW folder in windows Defender and it worked fine...
Just like minecrawler said in github, if your os is linux, your should set：
file/Settings/Build,Execution,Deployment/Tllochains/Debugger from Bundled GEB or gdb to Bundled LLDB.
I tried and it worded！
In my case (Linux / Ubuntu) the problem was somehow related to mounted directory.
The project was initially opened in CLion from /media/username/ssd/repo/git/projectname. The breakpoints were always disabled with message No executable code is associated with this line.
Then I opened the same project from a symlinked directory
~/git -> /media/username/ssd/repo/git and the breakpoints began to work fine.
In my case I had to edit the file so that everything was compiled again instead of using cache.
In my case, the problem is forget to comment out optimize option add_definitions(-O3) in cmakelists. which let compiler go release.
in the case of "the platform is currently not connected" of CLION for RUST, it turns out there is an authorization step which is not enabled on CLION 2022.2 version.
download the correct version solves the problem
I upgraded to xcode 5.0 today. I then pressed play to run my project in the iOS simulator. This initially worked. Then I decided that I wanted to run the profiler. When I did that, I got the message:
Xcode cannot run using the selected device.
Choose a destination with a supported architecture in order to run on this device.
I looked at a couple past posts on this problem and decided to do a Clean and Build. Now I can no longer run in the profiler or the simulator. I consistently get the message:
Xcode cannot run using the selected device.
Choose a destination with a supported architecture in order to run on this device.
How can I resolve this?
Here are various settings:
My Deployment Target is 6.1
I have also tried changing the deployment target to 7.0, but that did not work either
It appears that the problem is not related to the architecture in the build settings as the error might suggest. Rather, I found that the problem seems to be related to the Build Options Compiler for C/C++/Objective C. I was using a gcc compiler (com.apple.compilers.llvmgcc42) and Xcode 5 has marked this as unsupported.
If I change the compiler to apple's default Apple LLVM 5.0, the project builds and it can now run in the simulator. The downside is that I have a lot of compiler warnings from code related to cocos2D v1.0 source code. But, at least I have a way forward.
Please follow below step
1>Go to Project Build setting
2>Change compiler for c/c++/objective c as Default compiler(Apple LLVM 5.0) (see in below image)
I had to change compiler for Default compiler (Apple LLVM 5.0) at two places:
Build Settings > Build Options > Compiler for C/C++/Objective-C (change to LLVM)
Build Rules > Files *.mc using GCC (change to LLVM)
Hard to find because code compiles even if Build Rules point to an undefined compiler.
After inspecting all the build settings for 15 minutes, this worked for me (Xcode 5.0.2):
Quit and restart Xcode
Check that the Executable File (also known as CFBundleExecutable) in the Info.plist file is set to ${EXECUTABLE_NAME} as opposed to any hardcoded value. This will ensure that even if you change your project name or target name or scheme name, that it still works.
This issue often occurs after duplicating targets on older projects.
Set the following in your Info.plist for the target:
Bundle Name = ${PRODUCT_NAME}
Bundle Display Name = ${PRODUCT_NAME}
Executable file = ${EXECUTABLE_NAME}
Build and run with these settings, after a successful build they can be changed to anything you want.
This works for me: "Quit and restart Xcode". I recently updated something and the testing device on Xcode said: 'iDevice' not iPhone or iPod. So I restarted then my iPhone came back to the target list.
I had this error when I changed the value of the "Bundle name"-key in the Target Properties. Changing it back to "%{PRODUCT_NAME}" solved the problem for me.
I just started using Xcode to program a C++ openCV project.
The project is set up with an external makefile, /usr/bin/gnumake as build tool, and the program compiles and runs fine.
However, breakpoints gets skipped no matter what i do.
I have tried making a new project, selecting between gdb and LLDB, restarting Xcode++
There are numerous threads about this issue, but most talk about "Load Symbols Lazily", but as far as I know, this is not an issue in Xcode 4.5.2.
It is probably my limited Xcode knowledge that causes the error.
Help is greatly appreciated.
I could resolve my similar problem by disabling "Link-Time Optimization" for the Debug build settings.
Make sure that any kind of code optimization is disabled in your debug build settings (code stripping, optimization, etc). Then check that you really run the debug build and not the release version.
It would be great if XCode could automatically warn you when you have build settings that possible break the debugger...
On most projects, If I change the compiler I'm using from "apple llvm compiler 4.1" to "llvm gcc 4.2", the compiler options available later on in Build settings will change accordingly.
Right now, I'm doing a project using objective-c++ , but I'm noticing the compiler options don't update (see screenshot below). Anyone ever experienced this? Is there a way to fix this without creating a brand new project?
I was trying to switch to the apple llvm compiler to try using ARC (and yes, I've read http://philjordan.eu/article/mixing-objective-c-c++-and-objective-c++ and it's recommendation to not use ARC in this scenario).
NOTE: I'm using Xcode Version 4.5 (4G182)
I had the same problem and solved it by editing my project.pbxproj file using a text editor. I had inconsistent settings of "GCC_VERSION" in the file. I quit Xcode and then simply deleted all the lines with GCC_VERSION in them. Restarted Xcode and suddenly I got the default compiler (apple llvm) and all the appropriate compiler options.
Click the "All" label on the top gray bar, and all the options will show up:
Is it possible to symbolicate MonoTouch crash dumps and get line numbers out of them? If so, how is it done?
I have configured my project in the following way:
Build in release mode
Checked 'Enable debugging' in Project Options -> Build -> iPhone Build -> General tab
Checked 'Emit debugging information' in Project Options -> Build -> Compiler
Now, when I run symbolicatecrash against a dump, I get my method names in the stack trace but with only an offset against them (eg '+ 268') rather than a line number.
I am using MonoTouch 4.21.
Short answer: I think the issue is with the ahead-of-time (AOT) compiler - but you better email such question to the mono-devel mailing-list to get a definitive answer.
Long answer:
Mono compilers/runtime (and that behavior is inherited by MonoTouch) keeps the debugging information, that includes line numbers, for its assemblies inside mdb files.
XCode works with DWARF (DSYM) files. When XCode symbolicate a crash dump it looks (only) in the (AOT-produced) DWARF symbols to get its information - i.e. the mdb files are not looked up.
Now the Mono debugger (and runtime) can cope with DWARF too (which should fit the bill). However for MonoTouch I'm not sure the AOT compiler (which calls gcc) is producing the final DWARF symbols containing the C# line numbers - resulting in symbols and offsets (both available to gcc) only being available.
which version of xcode are you using?
There was an problem in earlier versions -
check https://github.com/chrispix/symbolicatecrash-fix