How Does the Shell Execute ls?

Once the file corresponding to the typed command is found, a call to the execve() system call is made from the function shell_execve() in the file execute_cmd.c. The call is defined in the kernel (fs/exec.c) as shown in Listing 9.

Effectively, the do_execve() function does the work. do_execve() has the following prototype:

int do_execve (struct filename *filename,
 const char __user *const __user *__argv,
 const char __user *const __user *__envp)

Using the SystemTap script shown in Listing 10, I place a probe at the do_execve() function; struct filename is defined in include/linux/fs.h as follows:

struct filename {
  const char *name; /* pointer to actual string */
  const __user char *uptr; /* original userland pointer */
  struct audit_names *aname;
  bool  separate; /* should "name" be freed? */
};

Hence, I use $file->name to retrieve the filename of the binary that is being executed.

Invoking this SystemTap script with the following

stap -v do_execve.stap

and executing ls in another terminal window produces:

The process ID of the executing ls process is 26013, and the binary corresponding to the command that is executed is /bin/ls. Several other things have to happen before the binary /bin/ls is executed. For example, the program has to be read from the disk, its binary format needs to be found, and the appropriate handling code must read the binary into memory.

The SystemTap script in Listing 11 probes some of the key functions that show how the /bin/ls binary is loaded into memory. If you run the SystemTap script and execute the ls command in another window, you will see output similar to Listing 12 in the SystemTap window.

The search_binary_handler() function iterates through the list of currently supported binary formats and, once it finds that the executable is a supported format, proceeds to call the appropriate function to load the binary. In this case, it is the function load_elf_binary().

Dynamic and Static Linking

You can see that the glibc loader (/lib64/ld-linux-x86-64.so.2) is opened, because ls dynamically loads glibc into memory.

To see how things are different when you compile a program statically, compile the C program in Listing 13 with

gcc -o simple simple.c

and execute it while keeping the SystemTap script in Listing 11 running (see Listing 14).

Next, compile the program, passing the -static flag to gcc as

gcc -o simple_static simple.c -static

and execute the program. On Fedora 21, you need to have the glibc-static package. You should see the output shown in Listing 15 in the SystemTap window.

In this case, you can see that the loader is not being opened any more. Now, a number of things have to happen before the program is executed, including setting up the memory areas and copying over the arguments, as well as a handful of other tasks.

Retrieving the Files List from Disk

At this stage, the program is in memory and ready to execute when it gets a chance. So, how does ls read the directories and files from disk, and what happens in the kernel space to make that happen?

The ls utility uses the readdir(3) function to read the directory contents, which in turn invokes the getdents() system call defined as follows in fs/readdir.c:

SYSCALL_DEFINE3\
    (getdents, unsigned int, fd, struct linux_dirent __user*, \
     dirent, unsigned int,count)

The getdents() system call invokes the iterate_dir() function, also defined in the same file. This function reads the list of files in the directory by consulting the underlying filesystem's inode entries. Depending on which filesystem the path specified to ls is formatted, the function used to read the directory contents will vary. On ext4, the ext4_readdir() function in fs/ext4/dir.c is the function that does this, and the filldir() function in fs/readdir.c is called for every entry it finds.

The SystemTap script in Listing 16 traces the retrieval of the directory listing. The filldir() function prototype is:

static int filldir(void * __buf, const char * name, int namlen, \
    loff_t offset, u64 ino, unsigned int d_type)

The argument name corresponds to the file name of a file in the directory in which ls is invoked; hence, I print it in the SystemTap script. If you run the above SystemTap script and execute ls in another terminal window, you should see output similar to Listing 17 in the SystemTap window.

In Listing 17, you can see that besides the lines showing filldir, each of the filenames in the directory in which ls is executed is shown, including hidden files. Once the entries have been retrieved, the getdents() system call returns and the list of files appears in your terminal window.