Signals in Linux - Standard Signals

Every signal has a unique signal name, an abbreviation that begins with SIG (SIGINT for interrupt signal, for example). Each signal name is a macro which stands for a positive integer - the signal number for that kind of signal. Your programs should never make assumptions about the numeric code for a particular kind of signal, but rather refer to them always by the names defined. This is because the number for a given kind of signal can vary from system to system, but the meanings of the names are standardized and fairly uniform.

The signal names are defined in signal.h (/usr/include/bits/signum.h), which must be included by any C program that uses signals.

Several signal numbers are architecture-dependent, as indicated in the "Value" column. (Where three values are given, the first one is usually valid for alpha and sparc, the middle one for ix86, ia64, ppc, s390, arm and sh, and the last one for mips. A - denotes that a signal is absent on the corresponding architecture.)



The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

Next the signals not in the POSIX.1-1990 standard but described in SUSv2 and POSIX.1-2001.


Up to and including Linux 2.2, the default behavior for SIGSYS, SIGXCPU, SIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS was to terminate the process (without a core dump). Linux 2.4 conforms to the POSIX.1-2001 requirements for these signals, terminating the process with a core dump.

Next various other signals.


For detailed information about the side-effects and reasons causing these signals checout libc manual.

Signals in Linux - Basics

What is a Signal ?

A signal is a software interrupt delivered to notify a process or thread of a particular event. The operating system uses signals to report exceptional situations to an executing program. Some signals report errors such as references to invalid memory addresses; others report asynchronous events, such as disconnection of a phone line.

The lifetime of a signal is the interval between its generation and its delivery. A signal that has been generated but not yet delivered is said to be pending. There may be considerable time between signal generation and signal delivery. The process must be running on a processor at the time of signal delivery.

Many computer science researchers compare signals with hardware interrupts, which occur when a hardware subsystem, such as a disk I/O (input/output) interface, generates an interrupt to a processor when the I/O completes. This event in turn causes the processor to enter an interrupt handler, so subsequent processing can be done in the operating system based on the source and cause of the interrupt. When a signal is sent to a process or thread, a signal handler may be entered (depending on the current disposition of the signal), which is similar to the system entering an interrupt handler as the result of receiving an interrupt.

What causes a Signal ?

Let us see some of the events that can cause (or generate, or raise) a signal:

• A program error such as dividing by zero or issuing an address outside the valid range.
• A user request to interrupt or terminate the program. Most environments are set up to let a user suspend the program by typing Ctrl-z, or terminate it with Ctrl-c. Whatever key sequence is used, the operating system sends the proper signal to interrupt the process.
• The termination of a child process.
• Expiration of a timer or alarm.
• A call to kill or raise system calls by the same process.
• A call to kill from another process. Signals are a limited but useful form of interprocess communication.
• An attempt to perform an I/O operation that cannot be done. Examples are reading from a pipe that has no writer, and reading or writing to a terminal in certain situations.

Each of these kinds of events (excepting explicit calls to kill and raise) generates its own particular kind of signal.

Signals may be generated synchronously or asynchronously. A synchronous signal pertains to a specific action in the program, and is delivered (unless blocked) during that action. Most errors generate signals synchronously, and so do explicit requests by a process to generate a signal for that same process. On some machines, certain kinds of hardware errors (usually floating-point exceptions) are not reported completely synchronously, but may arrive a few instructions later.

Asynchronous signals are generated by events outside the control of the process that receives them. These signals arrive at unpredictable times during execution. External events generate signals asynchronously, and so do explicit requests that apply to some other process. One obvious example would be the sending of a signal to a process from another process or thread via a kill system call. Asynchronous signals are also aptly referred to as interrupts.

A given type of signal is either typically synchronous or typically asynchronous. For example, signals for errors are typically synchronous because errors generate signals synchronously. But any type of signal can be generated synchronously or asynchronously with an explicit request.

How Signals Are Delivered ?

When a signal is generated, it becomes pending. Normally it remains pending for just a short period of time and then is delivered to the process that was signaled. However, if that kind of signal is currently blocked, it may remain pending indefinitely—until signals of that kind are unblocked. Once unblocked, it will be delivered immediately.

When the signal is delivered, whether right away or after a long delay, the specified action for that signal is taken. For certain signals, such as SIGKILL and SIGSTOP, the action is fixed, but for most signals, the program has a choice. Possible default dispositions are

Term   Default action is to terminate the process.
Ign    Default action is to ignore the signal.
Core   Default action is to terminate the process
  and dump core.
Stop   Default action is to stop the process.
Cont   Default action is to continue the process
  if it is currently stopped.

The program can also specify its own way of handling the signals (signal handlers). We sometimes say that a handler catches the signal. While the handler is running, that particular signal is normally blocked.

References:

1. Libc Manual

Gcov - analyzing code produced with GCC

How can a programmer exactly know which part of his code is frequently executed and which part of code is never traversed ? That's where CODE COVERAGE comes for rescue ...

Code Coverage is a measure used in software testing to describe the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and checks the active and non-active parts of the source-code.

Basically there are number of code coverage criteria, the main ones being:

• Function coverage
Has each function in the program been executed?


• Statement coverage
Has each line of the source code been executed?


• Decision coverage (also known as Branch coverage)
Has each control structure (such as an if statement) evaluated both to true
and false?


• Condition coverage
Has each boolean sub-expression evaluated both to true and false (this does
not necessarily imply decision coverage)?


• Modified Condition/Decision Coverage (MC/DC)
Has every condition in a decision taken on all possible outcomes at least
once? Has each condition been shown to affect that decision outcome
independently?


• Path coverage
Has every possible route through a given part of the code been executed?


• Entry/exit coverage
Has every possible call and return of the function been executed?

CERN's LHC is also powered by GNU/LINUX

Everyone knew about Large Hadron Collider (LHC) Experiment (a snip at $10 billion) conducted by CERN.

The Large Hadron Collider (LHC) is the world's largest and highest-energy particle accelerator complex, intended to collide opposing beams of protons or lead, two of several types of hadrons, at up to 99.99 percent the speed of light.

CERN played a pivotal part in the evolution of the internet we know and love today. Tim Berners-Lee invented the hypertext link when he was working at CERN as an independent contractor in the 1980s. He saw the opportunity to link his hypertext to the Transmission Control Protocol (TCP) and the Domain Name System (DNS) The rest, as they say, is history.

Berners-Lee designed the first web browser, built the fist server and the first website was launched at CERN in August 1991. And he gave away world wide web to the world as a gift for Free.

CERN is home to not only a spirit of free enquiry, but to the use of free software itself. For starters CERN’s 20,000 servers use GNU/Linux. In fact they developed their own version of Scientific Linux (SL), a recompiled version of Red Hat Enterprise Linux, in conjunction with Fermilab and other labs across the world.


Coming to LHC experiment, LHC will output data on a truly massive scale that threatens to simply overwhelm the bandwidth of the current web: it is reported that the experiment will produce one gigabyte of data every second and that deluge requires a whole new way of handling data and distributing petabytes of information.

To solve that problem CERN came up with the Grid. This is being seen widely as the future of the web. Two large bottlenecks have been identified: the shortage of IP addresses and bandwidth. The former is being solved with the introduction of IPv6 which should render addresses virtually inexhaustible. As the number of users and web-enabled devices grows however and the web churns out more and more data, the other choke point therefore becomes bandwidth. CERN’s solution is The Grid.

The primary architecture of the computing grid is the “TIER” and there are three of them: 0, 1 and 2. The first centres on CERN itself, the second covers various sites across Asia, Europe and North America and the third is represented by individual labs, universities and private companies. Tier 0 - capable of managing up to 10 gigabytes per second across fibre optic cables. Checkout ZDNet's video on CERN's 3D digital camera.


CERN’s choice of GNU/Linux is no one off. To manage such a vast data output from the LHC some controlling software was required to manage the petabytes of data for users sitting at their computers across the world on the computing grid and GNU?LINUX is the best option for it. Users need to access the data transparently even though it is sitting on geographically disparate servers housing those petabytes. It is the opensource community that plays a great role in all the scientific experiments as well as in new innovative stuff. It is quite clear that even if it is a Super computer or a billion dollar Scientific Experiment or a new innovative technology it is the opensource community and GNU/LINUX that comes for the rescue rather than the propreitary stuff.

Actual link where you can have much more information about this topic is at this link.

Client Server example with PIPES

This example shows a combined use of unnamed and named pipes to produce a client–server relationship. Let us discuss first about the PROBLEM we are going to try.

There is a single Server process which runs continuously in background eventhough if there is no client to interact with it. Client processes runs in foreground and interacts with the server process. Both the client and server processes will run on the same machine (So server process will run background forever until it is manually killed).

The Client process accepts a command (probably a shell command) from the user and send's it to the Server via a FIFO which is a public channel between Client and Server for processing. Let us name this FIFO as PUBLIC fifo since its existence is known to all clients and the server. Once the command is received, the Server executes it using the popen–pclose sequence (which generates an unnamed pipe in the Server process). After execution Server process should return the output of the command executed to the client over a FIFO which is a private channel between the client and server. Let us name this FIFO as PRIVATE fifo. The Client, upon receipt, displays the output on the screen.

NOTE: Each and every Client process should have its own unique PRIVATE fifo to receive information from Server.

Check out the diagrammatic representation of the PROBLEM.


To ensure that both Server and Client processes use the same PUBLIC fifo name and have the same message format for the data sent through the FIFO, a local header file named local.h is created.

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <linux/limits.h>
#include <string.h>
#include <stdio.h>

#define B_SIZE (PIPE_BUF/2)

const char *PUBLIC = "/tmp/PUBLIC";

struct message {
   char fifo_name[B_SIZE];
   char cmd_line[B_SIZE];
};

The format of the message sent over the PUBLIC fifo is declared within the struct statement. The message structure consists of two character array's namely fifo_name, stores the name of the PRIVATE fifo of the Client process and cmd_line, stores the command to be executed by the Server.

Let us checkout the functionality steps of a newly created Client process.
  [1].  Create a unique name for the PRIVATE fifo and invoke it.
  [2].  Open the PUBLIC fifo in write mode.
  [3].  Prompt for command from user.
  [4].  Write command to PUBLIC fifo for Server to process.
  [5].  Open PRIVATE fifo in read mode to read the contents from Server..

#include "local.h"
int main()
{
int publicfifo, privatefifo, n;
static char buffer[PIPE_BUF];
struct message msg;

/*Using sprintf to create a unique fifo name 
and save into message structure*/
sprintf(msg.fifo_name, "/tmp/fifo%d", getpid());

/*Creating the PRIVATE fifo*/
if(mknod(msg.fifo_name, S_IFIFO | 0666, 0) < 0) {
  perror(msg.fifo_name);
  exit(1);
}

/*Opening PUBLIC fifo in WRITE ONLY mode*/
if((publicfifo = open(PUBLIC,O_WRONLY)) < 0) {
  unlink(msg.fifo_name);
  perror(PUBLIC);
exit(1);
}

while(1) {

  write(fileno(stdout), "\n cmd>", 6);
  memset(msg.cmd_line, 0x0, B_SIZE);
  n = read(fileno(stdin), msg.cmd_line, B_SIZE);

if(strncmp("quit", msg.cmd_line, n-1) == 0) {
  break;
}

write(publicfifo, &msg, sizeof(msg));

if((privatefifo = open(msg.fifo_name, O_RDONLY)) < 0) {
  printf("1\n");
  perror(msg.fifo_name);
  goto CLEANUP;
}

while((n = read(privatefifo, buffer, PIPE_BUF)) > 0) {
  write(fileno(stderr), buffer, n);
}

close(privatefifo);
}

CLEANUP:
close(publicfifo);
unlink(msg.fifo_name);

return 0;
}

Now we will check the Server process.
  [1].  Generate a PUBLIC fifo and open it in both read and write mode. Wait for the message from a Client process.
  [2].  Read the message from PUBLIC fifo.
  [3].  Open the Client's PRIVATE fifo in write mode.
  [4].  Execute the command from Client process using popen.
  [5].  Write the output into Client's PRIVATE fifo.

#include "local.h"

int main() {

int privatefifo, dummyfifo, publicfifo, n, done;
struct message msg;
FILE *fin;
static char buffer[PIPE_BUF];

/*creating the PUBLIC fifo*/
mknod(PUBLIC, S_IFIFO | 0666, 0);

/*
Server process opens the PUBLIC fifo in write mode to make sure that
the PUBLIC fifo is associated with atleast one WRITER process. As a
result it never receives EOF on the PUBLIC fifo. The server process
will block any empty PUBLIC fifo waiting for additional messages to
be written. This technique saves us from having to close and reopen
the public FIFO every time a client process finishes its activities.
*/

if( (publicfifo = open(PUBLIC, O_RDONLY)) < 0 ||
 (dummyfifo = open(PUBLIC, O_WRONLY | O_NDELAY)) < 0) {
   perror(PUBLIC);
   exit(1);
}

/*Read the message from PUBLIC fifo*/
while(read(publicfifo, &msg, sizeof(msg)) > 0) {

n=0;
done=0;

do {
  if((privatefifo = open(msg.fifo_name, O_WRONLY|O_NDELAY)) == -1) {
    sleep(5);
  }
  else {
    fin = popen(msg.cmd_line, "r");
    write(privatefifo,"\n",1);

    while((n= read(fileno(fin), buffer, PIPE_BUF)) > 0) {
      write(privatefifo, buffer, n);
      memset(buffer, 0x0, PIPE_BUF);
    }

    pclose(fin);
    close(privatefifo);
    done = 1;
  }
}while(n++ < 5 && !done);

if(!done) {
  perror("Not accessed the private fifo\n");
  exit(1);
}

}
return 0;
}

Compile server.c and client.c and generate server, client executable's. A sample execution of the client-server programs is shown below

[bash]$./server &                                  
[1] 27107

[bash]$./client                                           
cmd>ps
PID TTY          TIME CMD
14736 pts/3    00:00:00 csh
27107 pts/3    00:00:00 server
27108 pts/3    00:00:00 client
27109 pts/3    00:00:00 6
cmd>who
gray     pts/3    Feb 27 11:28
cmd>quit                                            

$./kill -9 27107
[1]    Killed        server
$

Calculate Time in Linux

Calculating time in LINUX in milliseconds and Seconds. We should include sys/time.h header file and the remaining sample code is

struct timeval start;

we wil be using gettimeofday system call whose syntax is
int gettimeofday(struct timeval *tv, struct timezone *tz); where

struct timeval
{
time_t tv_sec;···············/* seconds */
suseconds_t tv_usec;······/* microseconds */
};


/* To calculate time in seconds*/

gettimeofday(&start, NULL);
starttime = start.tv_sec + start.tv_usec/1000000;

/* To calculate time in milliseconds*/

gettimeofday(&start, NULL);
starttime = start.tv_sec*1000 + start.tv_usec/1000;

Optimization levels in GCC

Compilers have become pretty smart as they can perform all sorts of code transformations — from simple inlining to sophisticated register analysis — that make compiled code run faster.

In most situations, faster is better than smaller, because disk space and memory are quite cheap for desktop users. However, for embedded systems small is often at least as important as fast because of a commonplace environment consisting of extreme memory constraints and no disk space, making code optimization a very important task.

Optimization is a complex process. For each high-level command in the source code there are usually many possible combination's of machine instructions that can be used to achieve the appropriate final result. The compiler must consider these possibilities and choose among them.

In general, different code must be generated for different processors, as they use incompatible assembly and machine languages. Each type of processor also has its own characteristics -- some CPU's provide a large number of registers for holding intermediate results of calculations, while others must store and fetch intermediate results from memory. Appropriate code must be generated in each case.

Furthermore, different amounts of time are needed for different instructions, depending on how they are ordered. GCC takes all these factors into account and tries to produce the fastest executable for a given system when compiling with optimization.

Turning optimization flags ON makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program.

NOTE: While the GCC optimizer does a good job of code optimization, it can sometimes result in larger or slower images (the opposite of what you may be after). It’s important to test your image to ensure that you’re getting what you expect. When you don’t get what you expect, changing the options you provide to the optimizer can usually remedy the situation.

Let us see various optimization levels provided by GCC

LEVEL 0: -O0 Optimization
At this optimization level GCC does not perform any optimization and compiles the source code in the most straightforward way possible. Each command in the source code is converted directly to the corresponding instructions in the executable file, without rearrangement. This is the best option to use when debugging with a source code debugger (such as the GNU Debugger, GDB). It is the default level of optimization if no optimization level option is specified. It can be specified as

[bash]$gcc -O0 hello.c -o hello
or
[bash]$gcc hello.c -o hello

NOTE: -O0 is actually -(Capital O)(Number 0). Similarly -O1 is -(Capital O)(Number 1).

LEVEL 1: -O1 Optimization (-O)
In the first level of optimization, the optimizer’s goal is to compile as quickly as possible and also to reduce the resulting code size and execution time. Compilation may take more time with -O1 (over -O0), but depending upon the source being compiled, this is usually not noticeable. Level 1 also has two sometimes conflicting goals. These goals are to reduce the size of the compiled code while increasing its performance. The set of optimizations provided in -O1 support these goals, in most cases.

The -O1 optimization is usually a safe level if you still desire to safely debug the resulting image. Check out the table given below for optimizations enabled at different levels.

NOTE: Any optimization can be enabled outside of any level simply by specifying its name with the -f prefix, for example, to enable the defer-pop optimization, we would simply define this as

[bash]$ gcc -fdefer-pop hello.c –o hello

We could also enable level 1 optimization and then disable any particular optimization using the -fno- prefix, like this:

[bash]$ gcc -O1 -fno-defer-pop -o test test.c

This command would enable the first level of optimization and then specifically disable the defer-pop optimization.

LEVEL 2: -O2 Optimization
The second level of optimization provides even more optimizations (while including those in -O1, plus a large number of others). Only optimizations that do not require any speed-space tradeoffs are used, so the executable should not increase in size. The compiler will take longer to compile programs and require more memory than with -O1. This option is generally the best choice for deployment of a program, because it provides maximum optimization without increasing the executable size. It is the default optimization level for releases of GNU packages. The second level is enabled as shown below:

[bash]$gcc -O2 hello.c -o hello

LEVEL 2.5: -Os Optimization
The special optimization level (-Os or size) enables all -O2 optimizations that do not increase code size; it puts the emphasis on size over speed. This includes all second-level optimizations, except for the alignment optimizations. The alignment optimizations skip space to align functions, loops, jumps and labels to an address that is a multiple of a power of two, in an architecture-dependent manner. Skipping to these boundaries can increase performance as well as the size of the resulting code and data spaces; therefore, these particular optimizations are disabled.

-Os optimization level simply disables some -O2 optimizations like -falign-labels, -falign-jumps, -falign-labels, and -falign-functions. Each of these has the potential to increase the size of the resulting image, and therefore they are disabled to help build a smaller executable. The size optimization level is enabled as:

[bash]$gcc -Os hello.c -o hello

In gcc 3.2.2, reorder-blocks is enabled at -Os, but in gcc 3.3.2 reorder-blocks is disabled.

LEVEL 3: -O3 Optimization
The third and highest level enables even more optimizations by putting emphasis on speed over size. This includes optimizations enabled at -O2 and rename-register. The optimization inline-functions also is enabled here, which can increase performance but also can drastically increase the size of the object, depending upon the functions that are inlined. The third level is enabled as:

[bash]$gcc -O3 hello.c -o hello

Although -O3 can produce fast code, the increase in the size of the image can have adverse effects on its speed. For example, if the size of the image exceeds the size of the available instruction cache, severe performance penalties can be observed. Therefore, it may be better simply to compile at -O2 to increase the chances that the image fits in the instruction cache.

Architecture Specification
The optimizations discussed thus far can yield significant improvements in software performance and object size, but specifying the target architecture also can yield meaningful benefits.

The -march option of gcc allows the CPU type to be specified

The default architecture is i386. GCC runs on all other i386/x86 architectures, but it can result in degraded performance on more recent processors. If you're concerned about portability of an image, you should compile it with the default. If you're more interested in performance, pick the architecture that matches your own.


References:

1. Optimization in GCC
2. An Introduction to GCC - for the GNU compilers gcc and g++.

Compilation process in GCC

Compiling a C program - Compiling a simple C program using gcc.

Above article is a high level view of compliation in gcc. In present article let us see in depth view of the compilation order or flow in gcc which is a default C compiler in GCC.

gcc goes through a sequence of different intermediate steps before generating final executable. Those intermediate steps are the result of different tools which are invoked internally to complete the compilation of the source code.

The whole Compilation process is broken down into following phases:

• Preprocessing
• Compilation
• Assembly
• Linking

As an example, we will examine these compilation stages individually using the same ‘hello.c’ program given below:

#include <stdio.h>
#define STRING "Hello World"

int main (void)
{
printf ("My First program - %s\n",STRING);
return 0;
}

NOTE: We dont need to manually go through all the intermediate stages to generate a executable using gcc. All these stages are directly taken care transparently by gcc internally, and can be seen using the -v option.

Although 'hello.c' program is very simple it uses external header files and libraries, and so exercises all the major steps of the compilation process. If we compile the 'hello.c' with a simple command namely gcc hello.c then we end-up creating an executable file called a.out.

Back in the days of the PDP computer, a.out stood for "assembler output". Today, it simply means an older executable file format. Modern versions of Unix and Linux use the ELF executable file format. The ELF format is much more sophisticated. So even though the default filename of the output of gcc is "a.out", its actually in ELF format.

The Preprocessor
Basically C Preprocessor is responsible for 3 tasks namely:

• Text Substitution,
• Stripping of Comments, and
• File Inclusion.

Text Substitution and File Inclusion is requested in our source code using Preprocessor Directives.

The lines in our code that begin with the “#” character are preprocessor directives.

In 'hello.c' program the first preprocessor directive requests a standard header file, stdio.h, be included into our source file. The other one requests a string substitution to take place in our code.

So in preprocessor stage those included header files and defined macros are expanded and merged within the source file to produce a transitory source file, which the standard calls a Translation unit. Translation units are also known as compilation units.

The C preprocessor, often known as cpp, is a macro processor that is used automatically by the C compiler to transform a C program before compilation. To perform just preprocessing operation use the following command:

[bash]$ cpp hello.c > hello.i

The result is a file named hello.i which contains the source code with all macros expanded.

By convention, preprocessed files are given the file extension ‘.i’ for C programs and ‘.ii’ for C++ programs.

NOTE: By default the preprocessed file is not saved to disk unless the -save-temps option is used in gcc so we are just using the redirection operator to save a copy of preprocessed file.

By using gcc's “-E” flag we can directly do the pre-processing operation.

[bash]$ gcc -E hello.c -o hello.i

Now we will try to check the contents of the preproccessed input file. Since the stdio.h file is fairly large the resultant output is cleaned up a bit.

# 1 "hello.c"
# 1 "/usr/include/stdio.h" 1 3
# 1 "/usr/include/_ansi.h" 1 3
# 1 "/usr/include/sys/config.h" 1 3
# 14 "/usr/include/sys/config.h" 3
# 25 "/usr/include/sys/config.h" 3
# 44 "/usr/include/sys/config.h" 3

# 40 "/usr/include/stdio.h" 2 3
# 1 "/usr/include/sys/reent.h" 1 3

int main(void){

printf ("My First Program - %s\n", "HELLO WORLD" );
return 0;
}

Since our program has requested the stdio.h header be included into our source which in turn, requested a whole bunch of other header files. So, the preprocessor made a note of the file and line number where the request was made and made this information available to the next steps in the compilation process. Thus, the lines,

# 40 "/usr/include/stdio.h" 2 3
# 1 "/usr/include/sys/reent.h" 1 3

indicates that the reent.h file was requested on line 40 of stdio.h. The preprocessor creates a line number and file name entry before what might be "interesting" to subsequent compilation steps, so that if there is an error, the compiler can report exactly where the error occurred.

The Compiler
The next stage of the process is the actual compilation of the preprocessed source code to assembly language, for a specific processor (Depending upon the target processor architecture the source code is converted into particular assembly language and it can be known as cross-compilation).

By using “-S” flag with gcc we can convert the preprocessed C source code into assembly language without creating an object file:

[bash]$ gcc -Wall -S hello.i -o hello.s

The resulting assembly language is stored in the file ‘hello.s’.

NOTE: The assembly code generated depends upon the PC architecture and other reasons. I am just attaching the assembly code generated with the Cygwin - Linux Emulator.


NOTE: Above Assembly code contains a call to the external printf function.

The Assembler
We know that MACHINES (i.e. a computer) can understand only Machine-Level Code. So we require an ASSEMBLER that converts assembly code in "hello.s" file into machine code. Eventhough it is a straightforward one-to-one mapping of assembly language statements to their machine language counterparts, it is tedious and error-prone if done manually.

NOTE: ASSEMBLER was one of the first software tools developed after the invention of the digital electronic computer.

If there are any calls to external functions in the assembly code, the Assembler leaves the addresses of the external functions undefined, to be filled in later by the Linker.

The Assembler as in gcc can be invoked as shown below.

[bash]$ as hello.s -o hello.o

As with gcc, the output file is specified with the -o option. The resulting file ‘hello.o’ contains the machine level code for 'hello.c' program.

or

By using “-c” flag in gcc we can convert the assembly code into machine level code:

[bash]$ gcc -c hello.c

The Linker
The final stage of the compilation process is producing a single executable program file by linking set of object files. An object file and an executable file come in several formats such as ELF (Executable and Linking Format) and COFF (Common Object-File Format). For example, ELF is used on Linux systems, while COFF is used on Windows systems.

In practice, an executable file requires many external functions from system and C run-time libraries. The linker will resolve all of these dependencies and plug in the actual address of the functions.

The linker also does a few additional tasks for us. It combines our program with some standard routines that are needed to make our program run. For example, there is standard code required at the beginning of our program that sets up the running environment, such as passing in command-line parameters and environment variables. Also, there is code that needs to be run at the end of our program so that it can pass back a return code, among other tasks. It turns out that this is no small amount of code.

Actually the mechanism used internally by gcc to link up different files is a bit complicated. For example, the full command for linking the 'hello.c' program might look as shown below:

[bash]$ ld -dynamic-linker /lib/ld-linux.so.2/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i686/3.3.1/crtbegin.o-L/usr/lib/gcc-lib/i686/3.3.1 hello.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh/usr/lib/gcc-lib/i686/3.3.1/crtend.o /usr/lib/crtn.o

Luckily we are never asked to type the above command directly -- the entire linking process is handled transparently by gcc when invoked as follows:

[bash]$ gcc hello.o

This links the object file ‘hello.o’ to the C standard library, and produces an executable file ‘a.out’.

[bash]$ ./a.out
My First Program - Hello World

An object file for a C++ program can be linked to the C++ standard library in the same way with a single g++ command.

Compiling a simple C program using GCC

Let us see how to compile a simple C program using gcc compiler, for this we will try out with classical hello world program in C language which is given below:

#include <stdio.h>
int main (void)
{
printf ("Hello, world!\n");
return 0;
}

We will save the above 'C' code in a file named 'hello.c'. Inorder to compile a C file with gcc, use the following command:

[bash]$ gcc -Wall hello.c -o hello

This compiles the source code in ‘hello.c’ to machine code and stores it in an executable file ‘hello’.

NOTE: The output file for the machine code is specified using the -o option. This option is usually given as the last argument on the command line. If it is omitted, the output is written to a default file called ‘a.out’. If a file with the same name as the executable file already exists in the current directory it will be overwritten.

The option -Wall turns on all the most commonly-used compiler warnings---it is recommended that you always use this option! There are many other warning options, but -Wall is the most important. GCC will not produce any warnings unless they are enabled. Compiler warnings are an essential aid in detecting problems when programming in C and C++.

In this case, the compiler does not produce any warnings with the -Wall option, since the program is completely valid. Source code which does not produce any warnings is said to compile cleanly.

To run the program, type the path name of the executable like this:

[bash]$ ./hello
Hello, world!

This loads the executable file into memory and causes the CPU to begin executing the instructions contained within it. The path ./ refers to the current directory, so ./hello loads and runs the executable file ‘hello’ located in the current directory.

For a detailed view about how the who compilation process goes checkout Compilation process in GCC.

Running Linux from a USB Drive

I successfully installed LINUX on my kingston Datatraveller 2GB USB and it worked quickly and flawlessly.

Things Needed to Begin

1. USB Storage Device - (256mb or larger recommended using USB 2.0)


2. PC that can boot from a USB Device (check your BIOS or your User Manual)


3. Damn Small Linux (DSL) Distro


4. Syslinux 3.11


5. HP USB Disk Storage Format Tool
   

Formatting The USB Storage Device

1. Insert your USB Storage Device into an empty USB slot on your PC


2. Download and Install the HP USB Disk Storage Format Tool. Once the usb disk storage format tool is installed, run it


3. Use the following settings in the HP USB Disk Storage Format Tool
1. Device: The name and capacity of your storage device
2. File system: FAT
3. Volume label: Name it what you want (I chose LINUX)
4. Confirm the Format by clicking Yes.
5. Once the Format is complete it will give you a list of information about the file system, volume, etc. about your device. Click OK.
   

Extracting Necessary Files

1. Download and Extract the Damn Small Linux distro (dsl-4.2.4-embedded.zip) to your USB device using Win-Zip or any extraction software.


2. Download and Extract all the files from syslinux-3.11 to a folder named Syslinux on your primary hard drive (mine is C:)


3. In Command Prompt type cd c:\syslinux\win32 (substitute c: for the drive letter of your hard drive) and Press Enter


4. Type syslinux.exe -f F: (F: reprents the drive letter of my USB Device. Yours may be different. GET THIS RIGHT). Press Enter.


5. Exit from Command Prompt
   

Booting to Linux

Keep your USB Device plugged in and Reboot your PC. Enter your BIOS setup (usually by pressing F2 or DEL) and set your Boot order to boot from the USB Device First. Exit your BIOS and Save the Changes. Since there are MANY different BIOS you must figure out on your own if your PC supports booting from USB.

Voilla it works fine for me

REFERENCES
1. http://www.althack.com/