Anatomy of a simple Linux utility

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.

Listing 9

Kernel Definition of execve()


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? */

Listing 10

Tracing Calls to and from do_execve()


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.

Listing 12

Is Executable Format Supported?


Listing 11

SystemTap Trace


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/ 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

Listing 13

The printf() Library Function Call


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

Listing 14

SystemTap Output with Simple Program


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.

Listing 15

Statically Compiled Program


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:

    (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)

Listing 16

Tracing Locations


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.

Listing 17

Output of ls on ext4 Filesystem


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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Tracing Tools

    Programs rarely reveal what they are doing in the background, but a few clever tools, of interest to both programmers and administrators, monitor this activity and log system functions.

  • USENIX LISA: Ted T'so Helps with System Crashes and Presents SystemTap

    Linux kernel developer Ted T'so shared his know-how in a number of tutorials at the USENIX LISA conference in San Diego. One theme was getting first help for system crashes, and in the process, he took the opportunity to present SystemTap.

  • UKUUG Linux Conference 2006

    Blue skies, lots of sun, a great conference venue, and about 200 Linux enthusiasts – that’s the perfect recipe for another successful UKUUG summer meeting at the University of Sussex, Brighton.

  • Fedora 13 is Live

    The latest release features improved device access, improved virtualization.

  • Bash Tuning

    In the old days, shells were capable of little more than calling external programs and executing basic, internal commands. With all the bells and whistles in the latest versions of Bash, however, you hardly need the support of external tools.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More