I'm using IAR EWARM 5.4 , I wondered if there is a directive to show the compiler in Simulator mode.
For example, I want a part of my code to be only compiled in Simulator mode but will be ignored in target mode.
Thanks,
The compiler don't know if the end result will be executed on the simulator or on the target hardware.
However, you can always defined your own preprocessor symbol, say MY_SIMULATOR, when using the simulator. Your code could then check if it present using #ifdef MY_SIMULATOR.
Update: If you would like to check the difference between the Debug and Release modes, you can check the symbol NDEBUG. It is defined in Release mode.
Related
I have a UWP app that compiles and runs fine in debug mode, but when I compile in x86 release mode, I get the following error:
Severity Code Description Project File Line Source
Error ILT0038: 'Microsoft.CodeAnalysis.Formatting.AutoFormattingOptions' is a value type with a default constructor. Value types with default constructors are not currently supported. Consider using an explicit initialization function instead.
I do have Microsoft.CodeAnalysis analyzers installed, but they should have no effect while compiling, right?
Has anyone seen this before or have any idea how to resolve? Any help appreciated.
I have some C++ code using NEON intrinsics. From what I have read, all you need to do is include arm_neon.h to your project.. And then I read that this arm_neon.h header is not actually readily available to you automatically, you have to get it from the web. So I found and added this version to my project:
http://clang.llvm.org/doxygen/arm__neon_8h-source.html
In my project's prefix.pch I added:
#import "arm_neon.h"
And when I try to build on my iPhone6 device (I am not using the simulator), I get a billion errors inside the arm_neon.h file:
Can anyone please explain to me what I am missing here?
You've been misinformed about being able to pick up an arm_neon.h from the Internet. Generally the header is not just compiler specific, but compiler version (even compiler revision) specific. For GCC it relies on a number of compiler built in function calls, and from your screenshot of Clang the same holds there. As you'd expect, if the name of these internal-only functions changes, the header will fail to compile.
What surprises me is that you're unable to use an include of whichever arm_neon.h ships with your build environment. The only thing I can think of that would cause this is the build command trying to build for x86_64 (for the simulator) but you say this isn't what is happening. It might be worth checking your build settings one more time.
If you're still not getting anywhere, remember that arm_neon.h is sometimes considered as a system header, so in C++ you might need to #include <arm_neon.h> rather than #include "arm_neon.h" to get the compiler to search the system paths.
I am currently writing c++ code and compiling using Xcode. I was wondering: How can I find out which c++ compiler is Xcode 5 using?
I would like to know that to make sure that the program I am writing is compilable on other computers that don't necessarily use the same compiler.
Thanks in advance!
You can also check your target's build settings to see what the current setting is. However, Xcode 5 only uses the LLVM 5.0 compiler. GCC is no longer used.
https://developer.apple.com/technologies/tools/features.html
I just created a new cocoa project on Xcode 4.3.3. The preprocessor macros for the Apple LLVM compiler 3.1 settings have a DEBUG=1 $(inherited) value assigned. I removed it and add it again, and now I'm getting an error when compiling :
clang: error: no such file or directory: 'DEBUG=1'
I search for the value on the project settings and I saw that the value is also defined in "Other warning flags"
My questions are:
What is the difference between just having DEBUG vs DEBUG=1?
What does $(inherited) do?
What is it also doing on the other warning flags?
First, if you're getting a compilation error, then you most likely put the macro back in the incorrect place in the project settings. Please ensure you've put it into the Debug configuration branch of the Preprocessor Macros item under the Apple LLVM compiler x.x - Preprocessing section.
For your other questions:
The first version just defines the macro DEBUG so it's essentially empty. You can test for whether it exists or does not exist, but not much. The second sets it to 1 so that the preprocessor can actually do comparisons like #if DEBUG && SHOULD_DIE_ON_ERROR where you might abort if the application comes across some validation error, but only if SHOULD_DIE_ON_ERROR is set and 1 and you're running in debug mode.
The $(inherited) just brings in other macros you're inheriting from further up the chain. So if your project defines some items and your target defines some more, the target gets the project's settings as well without having to re-define them.
It shouldn't be effecting the warning flags at all. If anything, it determines code paths in header files you include (like the cocoa frameworks) which may use different implementations for things or may add debugging information to data structures, or whatever.
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.