Thinking about programming of bare-metal programming and OS environment

The so-called bare-metal programming here refers to the "programming of hardware systems without OS support", while the actual programming requires an environment in which the programming and compiling environment is called "host" and the final program runs on the "target" (cross-compiling). and the OS environment programming means that the final running program is running in an environment with operating system support, while the programming and compiling environment may be the machine running the program (local compilation) or not (cross-compiling).

Bare-metal programming is now mainly on the low-end embedded systems, such as SCM (single Chip machine), all kinds of MCU, DSP and so on. Of course, writing a PC's bootloader is certainly also part of bare-metal programming.

The most primitive way of bare-metal programming is to use assembly language (a one by one notation of a machine instruction, plus some simple assembly pseudo-instructions), with only a very limited set of instructions, and each line of code can only do tiny things. So now that bare-metal programming is generally used in more advanced languages (usually C), the process of converting from C to assembly language is called compiling. The compiler translates generic C code into specific machine code based on different machines, and only a very small amount of machine code still needs to be compiled, which is actually a mixed programming pattern. The compiler is a very important tool, and the theoretical and practical knowledge of compiling is very rich.

Programming in an OS-enabled environment is more convenient. First, the OS manages and expands the entire machine resource, and provides a common API system calling interface, which is used by programmers to deal with hardware resources, so programming on the OS requires no consideration of machine features, in other words, portability is best. As a resource extension, the OS provides a number of mechanisms (including processes, memory management, device operations, and so on) and library files (which are reusable code), making it easier to write utilities.

Secondly, the relationship between the compiler and the OS is very close, the OS environment programming is very few people use the assembly code, but can use various levels and types of high-level language. It is easy to see that the compiler used by the OS environment programming is much more versatile than the bare-metal programming compilers, although they are closely linked. For example, the GCC compiler is able to compile A/C + + program for a variety of hard software platforms: You can use GCC to compile local programs, or you can cross-compile the target machine's program with XXX-XXX-GCC on the host, you can compile bare-metal programs with GCC, or you can compile programs in an OS environment. In general, the GCC compiled OS environment executable file is a "superset" of the bare metal environment executable. Take a look at the simplest makefile code below:

Key_led.bin:crt0. S  key_led.c       arm-linux-gcc-g-c-o crt0.o crt0. S       arm-linux-gcc-g-c-o key_led.o key_led.c       arm-linux-ld-ttext 0x0000000-g  crt0.o key_led.o-o key_led_elf       arm-linux-objcopy-o binary-s key_led_elf key_led.binclean:       rm-f key_led.dis key_led.bin key_led_elf *.o   

This code writes a program that controls the LEDs on an arm target machine with a key. The compilation of GCC first links it to an elf-formatted file, and then uses the Objcopy tool to convert it into a bare-metal code bin file. Because the elf executable file format is the standard support format for Linux systems, this file contains not only binary machine code, but also (if necessary) a lot of symbolic and control information (often text format), these symbols and control information can let the program interact with the OS, and get the support of the OS. When executing a program on bare metal, only the binary machine code bin file that is directly recognizable by the machine is required, which is a pure binary machine code file. As you can see from this process, the relationship between the compiler and the OS is really tight.

===================================================================

The following examines the actual program description in the Linux/unix system (based on Linux programing 4th edition).

Outline

Linux applications behave as two types of files: executables and script files. Executables can run directly, and they contain binary machine code and some control information that the OS must understand. Script file is interpreted by the execution of a sentence, in advance did not compile into the lowest machine code. There are many kinds of script files, such as Python, Shell and so on, Java virtual machine is similar to an interpreter, but it interprets Java intermediate code, performance is better than general interpreter.

The shell is the human-computer interface of Linux, which in essence is an interpreter that interprets every instruction the user has entered and, of course, explains the user-written script. The Linux standard program execution search paths are:

/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin

Optional operating system components and third-party applications may be installed in the/OPT directory, where the user adds the default search directory through the PATH environment variable. Programs executed from the shell inherit the shell's environment variables, but the program's modifications do not affect the parent program shell in reverse.

A text editor in Linux can select tools such as Vim, Emacs, or more visual eclipse.

Development environment:

1 , applications. /bin:/usr/bi:/sbin:/usr/sbin These directories typically store the most commonly used system programs, and later add programs that tend to be stored in/opt:/usr/local, which separate the system from the original program and subsequent additions to the program. For individual programs or development programs, it is best to store it in the/home directory. (usr doesn't mean the user, the year!!) is UNIX software Resource!!! )

The GCC driver is usually stored in/usr/bin or/usr/local/bin, which calls the GCC compiler's other applications, which may be stored in/usr/local/bin, or where other GCC knows.

As to which programs are system programs, this is hard to define, and the Linux kernel itself does not carry any programs, just provides an API interface. A minimal simplified version of the system program configuration such as BusyBox contains commonly used such as the shell and its commands, etc., just as the volume of hundreds of K.

2 , header files. when designing in C or other languages, the purpose of a header file is generally defined as a constant, or a declaration of system functions and library function calls (these definitions and declarations can originate from a user or from a standard library or an extended library). The header files for C in Linux are always located in/usr/include, and the header files that depend on a particular version are usually located in/usr/include/sys or/usr/include/linux.

3 , library files. Library, a set of pre-compiled functions that are written according to reusable principles. Standard system library files are stored in the/lib and/usr/lib directories, and other extension libraries may be stored in other LIB directories. The name of the library must be the beginning of Lib, followed by the function of the library. A represents a static library,. So represents a dynamic library, and there may be a. La file (* note). Although library files and header files are generally stored in a standard location, you can also compile with "-l" to search for a special location. In a program, if you reference a dynamic library, at compile time to explain the location of the dynamic library, the program run state also needs the library in the specified location.

For Linux, the program that is responsible for loading the dynamic library and parsing the functions referenced by the client program (the dynamic loader) is ld.so, or ld-linux.so.2/ld-lsb.so.2/ld-lsb.so.3. The program runs in search of additional locations in the dynamic library, which can then be configured in file/ETC/LD.SO.ETC. You can also use the LDD program to view a dynamic library that a program needs to run.

* Note: The detailed http://blog.flameeyes.eu/2008/04/what-about-those-la-files of the. La file

A summary is:
1, can hide the specific operating system of the shared library implementation of the difference, such as Linux is So,windows is a DLL. With. LA, the unified connection. La file is ready.
2. When connecting to a static library, you can get the dependency of the static library from it. The dynamic library (ELF based. So file) itself preserves this information and does not need. LA to get this information.
The. La file is theoretically not possible, and if you want to achieve true multilib support, you must not be able to. la files.
If you do not use the. La file, you can theoretically use pkg-config–static to obtain a dependency (library) when connecting to a static library.
But now, not all libraries provide the corresponding. pc files

Now some Gentoo developers and users are trying to remove the. La file from the system and fix the problems that follow, in order to lay a realistic foundation for Portage Perfect Multilib support in the future.

• Report

For more information on this, refer to:

Deep understanding of the Linux kernel · Third edition of the 20th chapter of the implementation of the procedure

"Linux Programming" · Fourth edition of the 4th Chapter Linux Environment

Standardized content for OS environment programming can be found in:

"Linux Programming" · Fourth edition, chapter 18th, Linux Standard

Advanced Programming for the UNIX environment · The second edition of the 2nd Chapter UNIX Standardization and implementation

From:http://www.cnblogs.com/andrew-wang/archive/2012/12/13/2816897.html

Thinking about programming of bare-metal programming and OS environment