A very good article on linux program execution flow

Linux x86 Program Start Up

Advertisements

The C++ compilation process

Copied from: http://faculty.cs.niu.edu/~mcmahon/CS241/Notes/compile.html

The C++ compilation process

C++ compilation process

Compiling a source code file in C++ is a four-step process. For example, if you have a C++ source code file named prog1.cpp and you execute the compile command

   g++ -Wall -ansi -o prog1 prog1.cpp

the compilation process looks like this:

  1. The C++ preprocessor copies the contents of the included header files into the source code file, generates macro code, and replaces symbolic constants defined using #define with their values.
  2. The expanded source code file produced by the C++ preprocessor is compiled into the assembly language for the platform.
  3. The assembler code generated by the compiler is assembled into the object code for the platform.
  4. The object code file generated by the assembler is linked together with the object code files for any library functions used to produce an executable file.

By using appropriate compiler options, we can stop this process at any stage.

  1. To stop the process after the preprocessor step, you can use the -E option:
       g++ -E prog1.cpp
    

    The expanded source code file will be printed on standard output (the screen by default); you can redirect the output to a file if you wish. Note that the expanded source code file is often incredibly large – a 20 line source code file can easily produce an expanded file of 20,000 lines or more, depending on which header files were included.

  2. To stop the process after the compile step, you can use the -S option:
       g++ -Wall -ansi -S prog1.cpp
    

    By default, the assembler code for a source file named filename.cpp will be placed in a file namedfilename.s.

  3. To stop the process after the assembly step, you can use the -c option:
       g++ -Wall -ansi -c prog1.cpp
    

    By default, the assembler code for a source file named filename.cpp will be placed in a file namedfilename.o.

Saving file with sudo without reopening

It happens many time that you open file in vim, make major changes and when you try to save, you realize that you needed to open it as a root.

Well, you do not need to reopen that file and you can save it as sudo with below command:

:w !sudo tee %

Hit enter after typing that in, you will be prompted for a password if required and then you will then get the following message.

Press ENTER or type command to continue

Press ENTER and assuming you actually made some changes, you will then get the following message.

Press ENTER or type command to continue
W12: Warning: File "/etc/vim/vimrc" has changed and the buffer was changed in Vim as well
See ":help W12" for more info.
[O]K, (L)oad File:

Press L and quit the file.

That’s all!

Store and Restore Sessions in VIM

Below commands once added in vimrc creates a session with F2 and restore using F3:

map <F2> :mksession! ~/vim_session <cr> " Quick write session with F2
map <F3> :source ~/vim_session <cr> " And load session with F3

You can make any number of sessions using “mksession” command and restore using “source” command from vim editor also.

Ask for confirmation before running bash command

Sometimes we need to confirm or give warning before running any command.

In my case, I need to check JAVA version before building android source.
Android L needs to be built with Java 1.7 and Android KK needs to be built with Java 1.6. So it is required to change JAVA version while switching between Android K and L.

If we forget to change JAVA version, it tries to build source with improper version consuming lots of time (as java version changes, it tries to rebuild all the things) and results in failure at some point.

To avoid this, I updated bash script so that before build command it checks for JAVA version and asks user if it is proper or not. Upon confirmation from user it proceeds further.

Below is script I wrote and included in bashrc using “source” command at end of bashrc.


#!/bin/bash

function jdkmsg {
echo -e "\e[38;5;82m"
echo "########################################################################"
echo -e "\tHope You are using correct JDK version\n"
echo -e "JAVA_HOME = $JAVA_HOME"
java -version
javac -version
echo -e "You can change java and javac versions using below commands:"
echo -e "sudo update-alternatives --config java and"
echo -e "sudo update-alternatives --config javac"
echo "########################################################################"
echo -e "\e[39;5;82m"
}

debug_trap () {
	if [[ "$BASH_COMMAND" == *"build.sh"* ]]
	then
		jdkmsg
		echo "Allow?"
		select choice in yes no
		do
			if [ "$choice" = "yes" ]
				then break
			elif [ "$choice" = "no" ]
			then return 1
			fi
		done
	fi
}

shopt -s extdebug
trap debug_trap DEBUG

Git send email

My git send-email config:

git config sendemail.smtpuser 
git config sendemail.smtpserver smtp.googlemail.com
git config sendemail.smtpencryption tls
git config sendemail.smtpserverport 587
git config sendemail.suppresscc self
git send-email --to <to_list> --in-reply-to="<message_id_of_message1>" --thread *.patch

This will generate patch in below way:
– Message 1
.           – Patch 1
.                       – Patch 2

This is how I prepared cover page followed by two patches:

git format-patch -2 --subject-prefix="PATCH v2" --cover-letter --thread=shallow
  • Here –cover-later would create a cover page. We need to modify subject and content.
  • The –thread=shallow flag specifies that all patches will be In-Reply-To your cover letter. Hence all patches would be in reply to cover page by default.
  • –subject-prefix=”PATCH v2″ would use given prefix in patch file.

This is how I sent this patches:

git send-email –to <to_id> –cc <cc_id> <patches>

The patch follows below sequence

  • Cover Page
    • Patch 1
    • Patch 2

References:
https://burzalodowa.wordpress.com/2013/10/05/how-to-send-patches-with-git-send-email/
http://git-scm.com/docs/git-send-email
example patch