I am trying to understand the IPv6-over-BLE UDP-client demo example which is present in examples/cc26xx/cc26xx-ble-client-demo, the code has following header files:
#include "contiki.h"
#include "contiki-lib.h"
#include "contiki-net.h"
#define DEBUG DEBUG_FULL
#include "net/ip/uip-debug.h"
#include "net/ip/uiplib.h"
#include "net/ipv6/uip-icmp6.h"
I just want to know the locations of these header files in the Contiki file system as the code for the main implementation of the BLE connection is under cpu/cc26xx-cc13xx/rf-core/*.[ch] and cpu/cc26xx-cc13xx/net/*.[ch]. I want to understand how the example code can use the methods present in files at different locations.
So you need to understand how an application is build.
All executable code is defined in C files and translated into machine code. Having said this, there might be modules written in other languages, the C runtime most probably has some assembler sources. We can call these "translation units" because they are each translated separately on their own.
The header files just contain declarations of objects implemented in those translation units. Header files can combine declarations of several units or deliberately leave out some declarations.
If you compile one of your own sources which includes a header file there will be no code of the referenced objects in your resulting object file.
At the link stage the linker combines all object modules of your program, resolving references between all of them. That means if you have a call in one unit to a method in another module, that call will receive the correct address.
There are still unsatisfied references left, in particular those to library methods that were declared in those header files. The linker searches through the default and the explicitely given libraries to look for the methods. If it finds one it will get added to the code and the call will receive its address.
This is it really very short. Please search for a broader description in the web, you'll find a lot of them.
To answer your explicit question: "How can the example code use the methods present in files at different locations?"
The linker adds the machine code of these methods to the machine code of your modules. The location of their source code is irrelevant. The linker knows the location of the standard libraries. If you use additional libraries, add them (and their path, if needed) to the command line.
If you have any further questions, edit your question, please.
contiki.h, contiki-lib.h, contiki-net.h: These files are in contiki/core/ folder.
uip-debug.h: contiki/core/net/ip
uiplib.h: contiki/core/net/ip
uip-icmp6.h: contiki/core/net/ipv6/
Please find the answer below.
https://github.com/contiki-os/contiki/tree/master/core
"contiki.h"
"contiki-lib.h"
"contiki-net.h"
https://github.com/contiki-os/contiki/blob/master/core/net/ip/uip-debug.h
You can find the header files in the Contiki in the same respective locations.
Related
So I'm going through CS50 introduction course.
And I'm confused about the fact that if you write in IDE #include some header file, which tells computer to find some library, and your compiler will find that code and combine it with your code.
But then how does compiler find that code? Like I just type in #include <cs50.h> for example. But how does it find that code when I don't have it on my PC? Why would I have it without finding it online and downloading it beforehand? Does it look online and then download file, which it uses now and in future for my programs when I call #include? And if so does it mean that you can't properly program without connection to internet?
And im confused about the fact that if you write in ide #include some header file which tells computer to find some library,
Be careful with terminology. #include tells the compiler to find some header. The word library in C usually refers to the file with compiled code (.a, .lib, .so, .dll).
and your compiler will find that code and combine it with your code.
This is right. By and large, the effect is the same as copying and pasting the contents of the header in the place of the #include statement.
But then how does compiler find that code? Like i just type in #include Cs50 for example.
The compiler has default search paths built in, where it looks for the header that is being #included. Typically directories like /usr/include and /usr/local/include are built into the compiler, as well as the current directory .. You can add more search paths through compiler command line arguments, for example -I/some/path in gcc and clang.
But how does it find that code when i dont have it on my pc
It doesn't. You will get an error like "Cs50: No such file or directory".
If this works on your university's system, probably the header is installed on that system in some central location.
why would i have it without finding it online and downloading it beforehand? Does it look online and then download file which it uses now and in future for my programs when i call #include?
It doesn't.
And if so does it mean that you cant properly program without connection to internet?
C was developed in the 1970s. The internet barely existed yet. You can program perfectly well in C without an internet connection – if you can do it without StackOverflow, of course ;)
The code of the library must be present on your computer or nothing will work. There's no such thing as magic downloads of libraries, C compilers and linkers have worked the same since long before the Internet was even invented.
Standard library headers are typically downloaded & installed along with the compiler. They are also very likely already pre-linked into some convenient format for the target system. You don't need to worry about manually adding standard libs to your project since the compiler will take care of that for you.
Custom headers require their corresponding .c files or linked libs to be present too, but they must be manually added to the current project. Either by adding them in your IDE's project, or as in the old days by creating a make file.
How that works in CS50 I don't know, but the lib obviously comes pre-installed somehow and they have hidden how to the students. We wouldn't want to risk CS50 students actually learning how programming works, now would we...
if you write in ide #include some header file which tells computer to find some library
Slight misunderstanding. When you type #include "somefile.h" into your program, the first stage of C and C++ compilation called the pre-processor will search for that file (called a "header") from the INCLUDE path. That is, the pre-processor will search through the local directory of the .c file, then a specified set of standard directories, and perhaps your own project directories to find a file called "somefile.h". The INCLUDE path is highly configurable with IDEs, command lines, and environment variables. Upon finding that file, the result is that the contents of that file are virtually substituted directly into your source code, exactly where the #include statement originally appeared. It's as if you had typed that exact file contents yourself into your .c file. After the textual substitution of the #include statements with the file contents, the intermediate file contents are handed off to the compiler stage to convert to object (assembly) code.
Like i just type in #include Cs50 for example. But how does it find that code when i dont have it on my pc
If the file can't be found, the pre-processor stage of the compile will fail and the whole thing comes to an end. I'm not sure what's in Cs50, but if you type #include "Cs50" and it works, then my guess is that your university environment has some project or environment configuration that adds a course specific include directory into your compilation path. Difficult to say since you didn't specify how you were building your code. Most IDEs will let you right-click on a #include statement and navigate to the actual source of the header file so you can inspect its contents and see where it originates from on your disk.
Also, your title says "linking", but you really mean "including". Linking is final stage after the compiler compiles all source files to object code to produce a final executable program.
.h files (should only) contain data type definitions, extern declarations, and function prototypes. .h files are not libraries.
So the compiler will know what parameters function take and what is the return type. The compiler will know how to call them. It will also know the type of variables defined somewhere else in the code (including the libraries). When the compiler compiles the code it generates intermediate files called object files.
Those files are later linked together by a special program called linker. This program will find the actual code of the functions in other object files or libraries (Libraries are basically sets of object files grouped in one larger file). It happens behind the scenes. If you need to tell the linker to use specific library you simply use command line option. For example to use math library you need to use -lm compiler command line option.
But how does it find that code when I don't have it on my PC?
The library file has to be present in your file system. Otherwise linker will not be able to link functions or variables from that library.
And if so does it mean that you can't properly program without
connection to internet?
No, it means that you have to have properly configured toolchain (ie all libraries needed present in your file system).
But then how does compiler find that code?
For your level of knowledge: some libraries are linked by default. Other not - so you need to tell the compiler/linker what you want to use.
--gcc & binututils related--
Linking is generally quite a complicated process and the compiler has its own configuration files called "spec files" and linker has "linker scripts". But explaining what those files do is rather an advanced topic far beyond the scope of this question.
When I include some function from a header file in a C++ program, does the entire header file code get copied to the final executable or only the machine code for the specific function is generated. For example, if I call std::sort from the <algorithm> header in C++, is the machine code generated only for the sort() function or for the entire <algorithm> header file.
I think that a similar question exists somewhere on Stack Overflow, but I have tried my best to find it (I glanced over it once, but lost the link). If you can point me to that, it would be wonderful.
You're mixing two distinct issues here:
Header files, handled by the preprocessor
Selective linking of code by the C++ linker
Header files
These are simply copied verbatim by the preprocessor into the place that includes them. All the code of algorithm is copied into the .cpp file when you #include <algorithm>.
Selective linking
Most modern linkers won't link in functions that aren't getting called in your application. I.e. write a function foo and never call it - its code won't get into the executable. So if you #include <algorithm> and only use sort here's what happens:
The preprocessor shoves the whole algorithm file into your source file
You call only sort
The linked analyzes this and only adds the source of sort (and functions it calls, if any) to the executable. The other algorithms' code isn't getting added
That said, C++ templates complicate the matter a bit further. It's a complex issue to explain here, but in a nutshell - templates get expanded by the compiler for all the types that you're actually using. So if have a vector of int and a vector of string, the compiler will generate two copies of the whole code for the vector class in your code. Since you are using it (otherwise the compiler wouldn't generate it), the linker also places it into the executable.
In fact, the entire file is copied into .cpp file, and it depends on compiler/linker, if it picks up only 'needed' functions, or all of them.
In general, simplified summary:
debug configuration means compiling in all of non-template functions,
release configuration strips all unneeded functions.
Plus it depends on attributes -> function declared for export will be never stripped.
On the other side, template function variants are 'generated' when used, so only the ones you explicitly use are compiled in.
EDIT: header file code isn't generated, but in most cases hand-written.
If you #include a header file in your source code, it acts as if the text in that header was written in place of the #include preprocessor directive.
Generally headers contain declarations, i.e. information about what's inside a library. This way the compiler allows you to call things for which the code exists outside the current compilation unit (e.g. the .cpp file you are including the header from). When the program is linked into an executable that you can run, the linker decides what to include, usually based on what your program actually uses. Libraries may also be linked dynamically, meaning that the executable file does not actually include the library code but the library is linked at runtime.
It depends on the compiler. Most compilers today do flow analysis to prune out uncalled functions. http://en.wikipedia.org/wiki/Data-flow_analysis
Why should I use another source code file to share code or a function between many programs and use the linker instead of using a header file only? (I read this in Head First C but I didn't understand what is the point of it)
Generally, header files should only be used to declare your functions/structs/classes.
The actual implementation should be created in a separate .c file which then can be built and exported as a binary along with the header.
Keeping the implementation in the header has many drawbacks.
Bigger footprint - the header size will be bigger since you have
more symbols in it.
You cannot hide the implementation from the end-user.
The compile-time will be a lot larger since all code has to be processed every time it is included by the compiler.
Just to name a few. They might be many more reasons.
However, there are some cases when it is okay/better to include some logic in the header files.
For example for inline functions which may improve the runtime of the application while maintaining good code quality and/or templates in C++.
Generally, header files contain declarations, like function signatures, while the function definitions (the actual source code) are located in separate source files.
Multiple files can include the same header file and share function declarations at compile time. But they also must share the source files (the files must be linked together) in order to have access to the function code at run time.
Lately I have been using header files to split up my program into separate files, (C files containing functions and header files declaring them). Every thing works fine but for some reason, I need to include <stdio.h> and <stdlib.h> in EVERY C file... or my project fails to compile. Is this expected behavior?
C modules need to know either how something is defined, or where it can find a definition. If the definition is in the header file, then you should include it in the modules that use it. Here is a link to information regarding header files.
The answer would depend on whether or not that functions might depend on other declared functions in other .c/.h files.
For example:
filea.c:
#include "filea.h";
methodA()
{
methodB();
}
fileb.c:
#include <somelibrary.h>
#include "fileb.h"
methodB();
{
somelibrarycode();
}
This will not compile unless filea.c includes the header for fileb.h as it has some external dependency that is not resolved.
If this is not what you're describing than there is some other spaghettification happening, or you accidentally statically typed functions preventing them from being seen outside of the .c file.
One possible solution to this problem is to have a single shared.h with all the other includes, but I personally don't recommend this as this merely masks the issue instead of making it readily apparently which files depend on what and establish clear lines of dependency.
They must be included some way.
Some projects require long list of includes in .c files, possibly with mandatory sort, even forcing assumption that no header includes any other header.
Some allow assuming some includes form some headers.
Some use collection headers (that include a list of small headers) and replace long lists with those.
Some go even further, using "forced header" option of compiler, so include will not appear anywhere, and declare the content to be implicitly assumed. It may go on project or whole codebase level, or combined. It plays pretty well with precompiled headers.
(And there are many more strategies, you get the figure, all with some pros&cons.)
I've created a header file "foo.h" as well as an source file "bar.c" but can't seem to import bar.c into foo.h.
Is this possible? If so, could someone please point me in the right direction?
You've got it backwards... .h files exist to tell other programs what a .c file contains. The .c implements the things listed in the header.
Then, when a different program wants to use some of the stuff you implemented, they #include your header. When it compiles, another program called the linker is also run. This connects the functions from the header you used to their implementations.
Basically, Importing source files is something that should be avoided, although some compilers allow it.
Regarding the data types, it makes perfectly sense to declare them in the header file.