It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
http://lxr.linux.no/#linux+v3.0.3/arch/x86/boot/header.S
This is the first file that is first read by the CPU. So shouldn't this start in Assembly Language. It starts with #include so include is a method in C?
#include is a directive to the preprocessor, not the assembler. The preprocessor has nothing to do with the compiler.
That's the source code to the file. It gets compiled into machine language before it's used as part of the OS.
Given that it's AT&T syntax, the first thing you should do is check out the manual for GAS, which is part of the GNU binutils collection:
http://sourceware.org/binutils/docs-2.21/as/Preprocessing.html#Preprocessing
According to the manual:
"You can use the gnu C compiler driver to get other “CPP” style preprocessing by giving the input file a `.S' suffix."
That means the .S assembly files are meant to be assembled by running them through the GCC frontend, which applies the C preprocessor for macros and #include commands, and then passes the result to the GNU binutils assembler.
This is a .S file, therefore it can be processed by the C-preprocessor, of which #include is a valid C-preprocessor directive. If it was only a .s file, then that would typically be considered a "pure" gas syntax assembly file, at least from the standpoint of gcc.
#include is a preprocessor statement. The compiler won't see it at all.
You are looking at a source file. It will be compiled to produce assembler code and then it will be linked by linker (or compiler in some cases). What linker will do is it will look at linking table and the sections in header.S file and arrange them in correct manner.
That's the pre-processor it will be replaced by some other code after the pre-processing state, which will include the contents of the file at the place where it was defined. After that the compiler will compile the code, and the output from it will be assembled by the assembler, which will them read by the CPU and decoded.
Whatever code you write in whatever language, it is converted into machine code before it can execute. All the C programs are and all others are converted into machine code first and then that code will be read by the CPU, and not the C language syntax.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm trying to understand the Linux kernel, so I'm reading Linux kernel source. So how can I determine where a header file located, because there are many header files have the same name but locate in different directories?
Example: they include fcntl.h in fs/open.c
I can find fcntl.h in 17 different directories
arch/alpha/include/asm/fcntl.h
arch/arm/include/asm/fcntl.h
....
Generally, it's going to depend on the way the file was included. If included with quotes like this:
#include "QuotedHeader.h"
It should be in the same directory. (It can also be in the "include" directories.)
If included with angle brackets like this:
#include <BracketedHeader.h>
It's located in an "include" directory. These are directories that the compiler is told at compile-time to search in for header files. These can be passed as parameters, or set in an environment variable.
For the examples provided, the directories make it clear why there are duplicates: generally, different architecture-specific files are separated by folders named for different architectures.
In the example provided, you're looking at different fcntl.h files for the Alpha and ARM architectures. The file your compiler will use depends on the CPU being compiled for, and the compiler will be told which to use during compile time.
In my personal opinion, if you don't already know this, you may be starting in the wrong place to understand the linux kernel. Try first researching C
You could add preprocessor options to the CFLAGS governing the compilation of your kernel module. In particular, the -H option (passed to gcc) displays the path of each #include-d header, and -I option augments the list of searched include directories.
Look up the name of the header file in the man pages...or google it.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Is there a way to have a C source file print to the screen without including <stdio.h>?
Here's my situation: I was asked to programatically handle 1000 C source files that will each implements several numerical functions in C (these functions are supposed to work on data that is in memory, eithout any I/O). The origin of these source files in unclear, and hence, I'd like to make sure there will be no harm to my machine when I compile & run these source files.
Is there a way to find out if a C source file is potentially harmful? I thought of asking the developers to avoid any #include statements whatsoever, but I do need just printf -- as I'd like them to include an output of their calculations within main().
Any ideas?
Sure, add the prototype for printf at the top of your source file, as long as you're linking to the CRT libraries you can use the function without including stdio.h
printf prototype
int printf ( const char * format, ... );
There are, though they are probably a bit larger than the scope of the format of SO. In essence you leverage assembler calls in C. The blog KSplice touches on the subject ( with code and examples ) here.
Is there a way to find out if a C source file is potentially harmful?
No, there is none. A malicious source file could possibly do anything it wanted by defining its own prototypes, or by using inline assembly -- #include is just a compile-time convenience.
I would like to clarify why we need printf and studio.h to maybe make the concept more clear. C is a portable language. You can compile c for Linux, Mac OSX, Windows. In each, causing output normally boils down to a system call, or in embedded systems, dealing directly with a frame buffer or Uart device.
So of course it is possible, do you want to do it? Depends why. If you are coding against a specific platform and dont have printf(), then you may have to look into invoking a system call directly for that platform/writing some platform specific assembly code. It all depends on your use case.
Sure, put the necessary function prototypes in your program.
If you mean by not using printf, then you have several options - you can use fwrite, or you could dispense with streams and use write, or you could invoke operating system I/O services directly, or perhaps you could talk to the display hardware directly, or many other things.
If you want a better answer, perhaps explain why you want to not include stdio.h
This is silly but still:
#include <string.h>
int main() {
puts ("hi");
return 0;
}
and Output:
$ gcc -o try try.c
$ ./try
hi
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I am searching for some information.
I have seen in many programmes following files included
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
I want to know more what the above header files are used for i.e. in which conditions which header file is used.
Any link which clearly mentions which header file serves what purpose that will be great.
sys/types.h: "data types"
sys/socket.h: "main sockets header"
sys/un.h: "definitions for UNIX domain sockets"
unistd.h: "standard symbolic constants and types"
Header files are used for declaring items that are defined in some existing library.
If you want to use socket(), you'll need to include sys/types.h and sys/socket.h. If you want to use atan(), you'll need to include math.h. If you want to use printf(), you'll need to include stdio.h.
Knowing which header file is needed for a function is given in its documentation (man printf on Unix/Linux).
Knowing which function can be used for solving a problem is given by experience, stackoverflow and Google.
If you want to know what's in a header file, try looking at it, seriously: most will start with some comment describing the content if it's not obvious anyway.
If you want to know what part of a header file is being used by the program that's including, try removing it and looking at the error messages. That may also sound glib, but sadly there's generally not a better way to find this out. But, it may be that on one platform some functionality requires including two headers, whereas on some other platform only one of them is required (perhaps because the second header is indirectly picked up by some earlier include anyway): if you test on the platform where one header is needed and decide to remove the second include, you may break the build on the other platform. So, when you find stuff that is needed, consult the man pages for the required headers - they may be specified by some Standard that both platforms honour.
If you want to know which header files to use yourself, then again - you have to look at the documentation for the functions you need to call. Even then, as a C++ programmer you should prefer the C++ versions of certain C headers, and standard documentation tools like man - given the C function name - won't tell you about the C++ headers. Have a read of e.g. http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch03s02.html - it's GCC documentation but describes C++ Standard requirements for these headers.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I just want to know the language in which the C compiler was written. Please say something other than C.
Here's an excellent read: Reflections on Trusting Trust by Ken Thompson. Starts off with an overview of how the first C compilers were written. The boot-strapping technique to be precise. May not answer your question directly but gives you some insight.
Nearly all major C compilers are written in C. You might think there's a chicken-and-egg problem with this, but there's not. The process is called bootstrapping.
The very original C compiler was written (by K&R) in a predecessor language called B, or maybe BCPL. But once the C compiler was working well enough, they converted over to C and began using each successive version to compile the next.
Many of the bizarre features of C such as pre- and post-increment operators exist because (a) they represented special addressing modes on the PDP-11 on which the first C was developed, or (b) they helped the compiler fit in memory while compiling its own next version.
So that's the rest of the story.
GCC is written in C. The majority of C compilers are written in C.
There is a boot-strapping phase when first producing a compiler for a language (any language that has pretensions to be able to compile its own compiler - COBOL is one plausible exception, but there are many others) on a given platform, but once you have a compiler, then you write the compiler in that language.
All else apart, doing it in assembler is too expensive.
Depending on which C compiler, it was likely written in assembly, then it eventually probably became self-compiling so then parts were written in C.
You may browse the source for GCC for yourself at http://gcc.gnu.org/viewcvs/branches/
gcc is written in C
Clang is written in C++.
Those are the two I know.
You have to specify which compiler.
In the old days, people would write a small subset of the C language in assembler, and then use that to "bootstrap" compile a better C compiler written in C. These days it's more common to make a C compiler for a new architecture by cross compiling from an architecture that already works. I believe there are very few bits of, for instance, the gcc compiler, that aren't written in C or C++.
Seems to me it would be easiest to write a compiler in perl
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Assignment:
You are required to implement a C preprocessor. The preprocessor is to be implemented as a command-line tool, the input to which is a C source file (.c extension) and the output is the preprocessed file (.i extension). The tool also takes several options.
$ cppr <options> file.c
On successful processing, file .i is produced.
<options> may be:
Preprocessor options-
-Aassertion -C -dD -dM -dN -Dmacro[=defn] -E -H
-idirafter dir -include file -imacros file
-iprefixfile -iwithprefix dir -M -MD -MM -MMD
-nostdinc –P -Umacro –undef
Directory options-
-Bprefix -Idir -I-
Implement any two of the above. This has to be decided during requirements phase.
These are the options defined by the GCC compiler. Refer to the manpage of GCC to understand the options.
You must implement the following features at a minimum:
Stripping off of comments
#ifdef and #endif
#define for constants (not macros)
It is not easy to answer not knowing what exactly you don't understand, but I'll try anyway, using my very limited C experience.
What is a preprocessor?
A preprocessor is a program that does some kind of processing on the code file before it is compiled. You can, for example, define a symbolic constant with a preprocessor directive:
#define PI 3.14159
Then you can use this value with a meaningful name across your code:
area = r * r * PI;
...
circumference = 2 * r * PI;
What the preprocessor does here is replace all occurrences of PI with the numeric value you specified:
area = r * r * 3.14159;
...
circumference = 2 * r * 3.14159;
You can also include code depending on whether or not a constant has already been defined somewhere else in your code (this is typically used in projects with multiple files):
#define WINDOWS
...
#ifdef WINDOWS
/* do Windows-specific stuff here */
#endif
The lines between #ifdef and #endif will only be included if the constant WINDOWS is defined before.
I hope that by now you have some idea about what your program should do.
Tips on implementing the "minimum features"
Here I'm going to give you some ideas on how to write the minimum features your professor requires. These are just off the top of my head, so please think about them first.
Stripping off of comments
While reading the input, look for "/*". When you encounter it, stop writing to the output, then when you find "*/", you can start writing again. Use a boolean flag to indicate whether you are inside a comment (AFAIK, there is no bool type in C, so use an int with 0 or 1, or, more ideally, two symbolic constants like INSIDE_COMMENT and OUTSIDE_COMMENT).
#define for constants (not macros)
If you encounter any line beginning with #, obviously you should not write it out. If you find a #define directive, store the symbolic name and the value somewhere (both strings), and from then on, look for the name in the input, and write out the value instead each time it is found. You can set a maximum length for the constant name, this is I think 6 chars in C, and always check 6 characters from the input. If the 6 characters begin with a known constant name, write out the value instead.
#ifdef and #endif
Create a boolean flag to indicate whether you are inside an #ifdef, much like with comments. When finding #ifdef, check if you are already storing the constant name, and write to the output depending on that.
I hope this helps.
EDIT: also read the comment by gs!
Here's the gcc documentation on preprocessor options, which might be of some help to you. It's fairly long but most of it deals with options that you don't need to bother with, so you can look through and pick out the relevant sections.
Your C textbook should describe what the standard C preprocessor does, but you can also try man cpp.
Then write a program to perform a limited subset of these tasks (i.e. process #ifdef / #endif pairs, and simple #defines).
Your program should parse its command line, accept at least two of the options listed above, and handle them in the way explained in the gcc manpage.