{"id":467,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:00","modified_gmt":"2020-08-22T20:26:00","slug":"this-is-the-page-title-toplevel-300","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=467","title":{"rendered":"Executing Programs"},"content":{"rendered":"\nExecuting Programs<\/title>\n<p>\nIn Linux, as in Unix <sup><font size=-4><tt>T<\/tt>M<\/font><\/sup>, programs and commands are normally executed by a command\ninterpreter.\nA command interpreter is a user process like any other process and is called a <tt>shell<\/tt>\n<a href=\"#tthFtNtAAC\" name=tthFrefAAC><sup>2<\/sup><\/a>.\n<p>\nThere are many shells in Linux, some of the most popular are <tt>sh<\/tt>, <tt>bash<\/tt> and\n<tt>tcsh<\/tt>.\nWith the exception of a few built in commands, such as <font face=\"helvetica\">cd<\/font> and <font face=\"helvetica\">pwd<\/font>, a\ncommand is an executable binary file.\nFor each command entered, the shell searches the directories in the process’s <em>search\npath<\/em>, held in the <tt>PATH<\/tt> environment variable, for an executable image with a matching\nname.\nIf the file is found it is loaded and executed.\nThe shell clones itself using the <em>fork<\/em> mechanism described above and then the new child\nprocess replaces the binary image that it was executing, the shell, with the contents of\nthe executable image file just found.\nNormally the shell waits for the command to complete, or rather for the child process\nto exit.\nYou can cause the shell to run again by pushing the child process to the\nbackground by typing <tt>control-Z<\/tt>, which causes a <tt>SIGSTOP<\/tt> signal to be sent to\nthe child process, stopping it.\nYou then use the shell command <font face=\"helvetica\">bg<\/font> to push it into a background, the\nshell sends it a <tt>SIGCONT<\/tt> signal to restart it, where it will stay\nuntil either it ends or it needs to do terminal input or output.\n<p>\nAn executable file can have many formats or even be a script file.\nScript files have to be recognized and the appropriate interpreter run to handle\nthem; for example <tt>\/bin\/sh<\/tt> interprets shell scripts.\nExecutable object files contain executable code and data together with enough\ninformation to allow the operating system to load them into memory and execute\nthem.\nThe most commonly used object file format used by Linux is ELF but, in theory,\nLinux is flexible enough to handle almost any object file format.\n<p>\n<img decoding=\"async\" src=\"binfmt.gif\">\n<p>\nFigure: Registered Binary Formats\n<p>\n<p>As with file systems, the binary formats supported by Linux are either built\ninto the kernel at kernel build time or available to be loaded as modules.\nThe kernel keeps a list of supported binary formats (see figure <a href=\"#binfmt-figure\"\n> 4.3<\/a>)\nand when an attempt is made to execute a file, each binary format is tried\nin turn until one works.\n<p>\nCommonly supported Linux binary formats are <tt>a.out<\/tt> and <tt>ELF<\/tt>.\nExecutable files do not have to be read completely into memory, a technique\nknown as demand loading is used.\nAs each part of the executable image is used by a process it is brought into memory.\nUnused parts of the image may be discarded from memory.\n<p>\n<h3>ELF<\/h3>\n<p>\nThe <tt>ELF<\/tt> (Executable and Linkable Format) object file format, designed\nby the Unix System Laboratories, is now firmly established as the most\ncommonly used format in Linux.\nWhilst there is a slight performance overhead when compared with other\nobject file formats such as <tt>ECOFF<\/tt> and <tt>a.out<\/tt>, ELF is felt to be more flexible.\nELF executable files contain executable code, sometimes refered to as <em>text<\/em>,\nand <em>data<\/em>.\nTables within the executable image describe how the program should be placed into the\nprocess’s virtual memory.\nStatically linked images are built by the linker (<font face=\"helvetica\">ld<\/font>), or link editor, into one\nsingle image containing all of the code and data needed to run this image.\nThe image also specifies the layout in memory of this image and the address in the\nimage of the first code to execute.\n<p>\nFigure: ELF Executable File Format<\/center>\n<p>\n<p>The figure above shows the layout of a statically linked ELF executable\nimage.\n<p>\nIt is a simple C program that prints “hello world” and then exits.\nThe header describes it as an ELF image with two physical headers (<tt>e_phnum<\/tt> is 2)\nstarting 52 bytes (<tt>e_phoff<\/tt>) from the start of the image file.\nThe first physical header describes the executable code in the image.\nIt goes at virtual address <em>0x8048000<\/em> and there is 65532 bytes of it.\nThis is because it is a statically linked image which contains all of the library\ncode for the <tt>printf()<\/tt> call to output “hello world”.\nThe entry point for the image, the first instruction for the program, is not at\nthe start of the image but at virtual address <em>0x8048090<\/em> (<tt>e_entry<\/tt>).\nThe code starts immediately after the second physical header.\nThis physical header describes the data for the program and is to be loaded into\nvirtual memory at address <em>0x8059BB8<\/em>.\nThis data is both readable and writeable.\nYou will notice that the size of the data in the file is 2200 bytes (<tt>p_filesz<\/tt>)\nwhereas its size in memory is 4248 bytes.\nThis because the first 2200 bytes contain pre-initialized data and the next 2048 bytes\ncontain data that will be initialized by the executing code.\n<p>\nWhen Linux loads an ELF executable image into the process’s virtual address space, it\ndoes not actually load the image.\n<p>\nIt sets up the virtual memory data structures, the process’s <tt>vm_area_struct<\/tt> tree and\nits page tables.\nWhen the program is executed page faults will cause the program’s code and data to be\nfetched into physical memory.\nUnused portions of the program will never be loaded into memory.\nOnce the ELF binary format loader is satisfied that the image is a valid ELF executable\nimage it flushes the process’s current executable image from its virtual memory.\nAs this process is a cloned image (<em>all<\/em> processes are) this, old, image is the\nprogram that the parent process was executing, for example the command interpreter shell\nsuch as <tt>bash<\/tt>.\nThis flushing of the old executable image discards the old virtual memory data structures\nand resets the process’s page tables.\nIt also clears away any signal handlers that were set up and closes any files that are\nopen.\nAt the end of the flush the process is ready for the new executable image.\nNo matter what format the executable image is, the same information gets set up in the\nprocess’s <tt>mm_struct<\/tt>.\nThere are pointers to the start and end of the image’s code and data.\nThese values are found as the ELF executable images physical headers are read and the\nsections of the program that they describe are mapped into the process’s virtual address\nspace.\nThat is also when the <tt>vm_area_struct<\/tt> data structures are set up and the process’s page\ntables are modified.\nThe <tt>mm_struct<\/tt> data structure also contains pointers to the parameters to be passed to\nthe program and to this process’s environment variables.\n<p>\n<h4>ELF Shared Libraries<\/h4>\n<p>\nA dynamically linked image, on the other hand, does not contain all of the code and data\nrequired to run.\nSome of it is held in shared libraries that are linked into the image at run time.\nThe ELF shared library’s tables are also used by the <em>dynamic linker<\/em> when the\nshared library is linked into the image at run time.\nLinux uses several dynamic linkers, <tt>ld.so.1<\/tt>, <tt>libc.so.1<\/tt> and <tt>ld-linux.so.1<\/tt>, all\nto be found in <tt>\/lib<\/tt>.\nThe libraries contain commonly used code such as language subroutines.\nWithout dynamic linking, all programs would need their own copy of the these libraries\nand would need far more disk space and virtual memory.\nIn dynamic linking, information is included in the ELF image’s tables for every\nlibrary routine referenced.\nThe information indicates to the dynamic linker how to locate the library routine and link\nit into the program’s address space.\n<h3>Script Files<\/h3>\n<p>\nScript files are executables that need an interpreter to run them.\nThere are a wide variety of interpreters available for Linux; for example <font face=\"helvetica\">wish<\/font>,\n<font face=\"helvetica\">perl<\/font> and command shells such as <font face=\"helvetica\">tcsh<\/font>.\nLinux uses the standard Unux <sup><font size=-4><tt>T<\/tt>M<\/font><\/sup> convention of having the first line of a script file\ncontain the name of the interpreter. So, a typical script file would start:\n<pre>\n#!\/usr\/bin\/wish\n<\/pre>\n<p>\nThe script binary loader tries to find the intepreter for the script.\n<p>\nIt does this by attempting to open the executable file that is named in the\nfirst line of the script.\nIf it can open it, it has a pointer to its VFS inode and it can go ahead\nand have it interpret the script file.\nThe name of the script file becomes argument zero (the first argument) and all\nof the other arguments move up one place (the original first argument becomes the\nnew second argument and so on).\nLoading the interpreter is done in the same way as Linux loads all of its executable\nfiles.\nLinux tries each binary format in turn until one works.\nThis means that you could in theory stack several interpreters and binary formats\nmaking the Linux binary format handler a very flexible piece of software.\n","protected":false},"excerpt":{"rendered":"<p>Executing Programs In Linux, as in Unix TM, programs and commands are normally executed by a command interpreter. A command interpreter is a user process like any other process and is called a shell 2. There are many shells in … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=467\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-467","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=467"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/467\/revisions"}],"predecessor-version":[{"id":553,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/467\/revisions\/553"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}