I'm making a firmware for an embedded device and when I build for different hardware I use different config settings.
For this I have a config file config.h:
#define FOO_MODE 7
In my code I would then use something like
void do_something_if_in_mode_4() {
if (FOO_MODE == 4)
return;
// ...
}
But CLion understands the config file as code and tells me that the "Condition is always false" and that return is unreachable code.
That file is code! The preprocessor included that file's content in your main source code and replaced all occurrences of FOO_MODE with 4. The compiler never sees FOO_MODE; remember that the preprocessor is dumb string handling that happens completely before the compiler gets to see the source code
And your compiler correctly detects the unreachable code, because 7 is not 4. The compiler will also be smart enough to omit the unreachable code in the binary, which is desirable.
If the warning annoys you, I'm sure there's ways to disable it. However, I think it's a good tool, so I'd keep it.
For code that you really do not even want to compile for some devices, try to use preprocessor #if instead, to effectively remove the text from the code that the compiler gets to see.
Related
I have a #define ONB in a c file which (with several #ifndef...#endifs) changes many aspects of a programs behavior. Now I want to change the project makefile (or even better Makefile.am) so that if ONB is defined and some other options are set accordingly, it runs some special commands.
I searched the web but all i found was checking for environment variables... So is there a way to do this? Or I must change the c code to check for that in environment variables?(I prefer not changing the code because it is a really big project and i do not know everything about it)
Questions: My level is insufficient to ask in comments so I will have to ask here:
How and when is the define added to the target in the first place?
Do you essentially want a way to be able to post compile query the binaries to to determine if a particular define was used?
It would be helpful if you could give a concrete example, i.e. what are the special commands you want run, and what are the .c .h files involved?
Possible solution: Depending on what you need you could use LLVM tools to maybe generate and examine the AST of your code to see if a define is used. But this seems a little like over engineering.
Possible solution: You could also use #includes to pull in .c or header files and a conditional error be generated, or compile (to a .o), then if the compile fails you know it is defined or not. But this has it's own issues depending on how things are set-up in your make file.
Does any program compiled with the -g command have its source code available for gbd to list even if the source code files are unavailable?? Also when you set the breakpoints at a line in a program with a complicated multi source file structure do you need the names of the source code files??
OP's 1st Question:
Does any program compiled with the -g command have its source code available for gbd to list even if the source code files are unavailable??
No. If there is no path to the sources, then you will not see the source.
OP's 2nd Question:
[...] when you set the breakpoints at a line in a program with a complicated multi source file structure do you need the names of the source code files??
Not always. There are a few ways of setting breakpoints. The only two I remember are breaking on a line or breaking on a function. If you wanted to break on the first line of a function, use
break functionname
If the function lives in a module
break __modulename_MOD_functionname
The modulename and functionname should be lowercase, no matter how you've declared them in the code. Note the two underscores before the module name. If you are not sure, use nm on the executable to find out what the symbol is.
If you have the source code available and you are using a graphical environment, try ddd. It stops me swearing and takes a lot of guesswork out of gdb. If the source is available, it will show up straight away.
I have a large base of code for a series of embedded devices. Everytime we make a fix for one product, we merge-in the changes for others. Sometimes, some devices have the code under Macro's .. something like
#if DEVICE1
Do_This();
#elif DEVICE2
Do_That();
#else
Do_SomethingElse();
#endif
In the above case, I will have to merge-in the code under resspective macro. Sometimes, it is not very stright forward. So, after merging-in the changes.
During compilation time, is there any way to find whether the new added lines of code getting compiled or not?
cpp is the same preprocessor used by gcc. Call it manually with the same flags, it will output resulting (processed) code. Search interesting area to check what you want.
E.g. cpp foo.c | less.
I am wondering what difference it makes to the debugger (Intellij IDEA + Scala plug-in) when I debug Scala code and not Java code. To my understanding, a debugger is tightly coupled with the language i.e. a Java debugger can not handle Scala code but apparently the JVM is the center of attention here meaning as long as it is byte-code, any debugger would do. right ?
IMPORTANT UPDATE: The problem was to give an example of how a byte-code debugger may be limiting for Scala. Assume a break point is reached and I don't want to go to the next line but I want the debugger to evaluate an Scala expression in the context of the application (e.g. I like to call an operator method from a singleton object). The debugger is stuck because it can not understand Scala. I have to do the transformation myself and input the resulting Java to the debugger.
The problem is that only "breakpoint stuff" could be handled in byte-code level. What if you want to put an expression under watch? Debugger has to understand Scala to evaluate the watched expression,right? This time I'm sure I'm right. Vengeance is mine, Saith the Lord ;-)
Short answer your assumptions are wrong.
The reason is the debugger does not care what language your debugging. It stops at breakpoints which in turn include the line of a particular source file. Note that the source file is merely text for you to read - the debugger never scans the source files. If you change the spot where source files are to another directory with a text file in the right directory w/ the right filename as a breakpoint that has been set, the debugger will happily show it when the breakpoint happens. Everytime you set a breakpoint your ide is telling the debugger hey scan this class for any byte code on this line and stop when you hit it. This of course does not work if your ide is attempting to compile the same text file into a class file - however it will work if you create fake text files as source for a jar file and do the source file mapping thing.
If one thinks about it, writing a simple template and compiling it while support debugging is not that difficult. Simply use asm to create all the print statements and tell asm this print statement is from the template file on this line. After that you can add more clever stuff while keeping things debuggable.
The project I'm working on recently made a big effort to cleanup the code by turning on all the strictest GCC warnings and iterating until it compiled. Now, for instance, compilation fails if I declare a variable and don't use it.
After my latest development task there I see that there is a header file included somewhere that is now unnecessary. Is there any good way to find other such header files (and in such a way reduce dependencies) other than trying to remove a header file and seeing if anything breaks?
I am using GCC 4.3.2 on Linux.
No, there's no way to get gcc to fail if a header isn't required. Included headers can contain pretty much anything, so it is assumed that whoever included them had good reason to do so. Imagine the following somewhat pathological case:
int some_function(int x) {
#include "function_body.h"
return x;
}
It's certainly not good form, but it would still compile if you removed the include. So, an automatic checker might declare it "unnecessary," even though the behavior is presumably different when the function body is actually there.