In-depth study of c language article 3, in-depth study of c Article 3

In-depth study of c language article 3, in-depth study of c Article 3

This article studies other tools in TC2.0. At the same time, let's take a look at the TC process from the source code to the exe program.

1. Use TCC to compile the following program into a. obj file

We know that TCC is divided into the following two steps in the default compilation to connect a c language source program a. c:

(1). TCC compiles the source program file into a. obj.

Hosts file.

We also know that the optional TCC parameters are as follows:

We can see this option: Compile only (Compile only ). This should be the option to compile only the. obj file. The verification is as follows:

We can see that only the. obj file is generated in the folder:

2. Compile the following program using the C: \ C \ tcc a. c method:

Let's look at the source program. Obviously, f functions are not defined and implemented. Let's look at the error prompt during the compilation connection process:

As expected, the error message is displayed: f function is not found in a. c.

The error message is displayed. No f function is found in a. c. It is easy to think, isn't it more than searching for f Functions in a. c? Or is it possible to search not only from A.C? We also think that the TCC function has the option to compile multiple. c files at the same time. We try to write two files and compile them together:

Compile the connection process:

No error message is displayed. And a.exe is generated under the folder. Run and view:

We can see that the same program is written in two files, and the program can be compiled and connected normally.

3.TLIB.exe

We can see from the book that tc2.0has provided us with a tool named tlib.exe. you can use tlib.exe to add the code in A. obj file to a. lib file.

First, parse the parameters of tlib.exe. We follow the TCC method and run TLIB in cmd. The parameter table is as follows:

We can see that its parameter + is to add a file to the lib file. Let's try:

We can see that the attribute is indeed modified.

Then we try to compile a. c again. No error prompt found:

We load it into debug and find the code of the main function and f function of the program:

We can see that there is only one call command in the main function. According to the code comparison, we know that f function is called here. Let's look at the code of the f function:

Run: The f () function called by a. c is actually the f function in 4_1.c.

In our entire process, we can come up with this theory. Although we didn't write the program f, the code of function f in a.exe is obtained from cs. lib during the connection process.

4. Compile the following program as f. obj and add f. obj to c: \ c \ cs. lib.

Program f. c is as follows:

The program below is compiled and connected to B .exe.

After compilation is complete, go to debug to view the information. The main function code is as follows:

We can see that the call method is used in function calls, and the call location is far from that of the main function. That is to say, the call function is not consecutive with the main function. We can jump to the called part. View its code.

We can see that the three subprograms are actually the statements implemented by the f1, f2, and f3 functions. Besides, although f3 is not called in B, the code of f3 is also in B.

Obviously, after modifying cs.lib, we can call f1,f2, which indicates that the code in B .exe is added from cs. lib during connection.

So, is it because these three functions are added to cs. lib in the same file that they are loaded at the same time?

We take out f3 separately and add cs. lib (in this process, cs. lib is restored to cs. lib that comes with tc2.0)

At this time, we are compiling and connecting to B. c, and then entering debug loading:

We can see that there is no f3 here. So is it stored elsewhere? Let's see where it should be when f3 is called.

Let's modify B .C so that he can call f3.

Go to debug loading to view details.

We can see that the sub-functions implemented by f3 are behind f1 and f2. That is, if f3 is called, its address is after f2. If f3 is not followed by f2, that is, f3 is not called. In this way, it denies the inference that f3 is placed elsewhere. It is further explained that the solution of compiling and adding cs. lib respectively can implement which function can be used and the code of which function can be loaded.

5. Replace printf

Use TLIB. EXE to convert the printf function code in cs. lib into the code of the following program:

Through the previous programs, we know that the printf function code also exists in cs. lib. Then, we cannot add. obj to cs. lib as in the previous programs. It should be replaced. We looked at the TLIB. EXE parameter table and found that-+ was replaced. Let's try:

No error message is found. We compile a program as follows to test whether printf has been replaced successfully:

Run the following command after compiling the connection:

It is confirmed that printf is replaced with our own printf.

6. Thinking:

What are the advantages of TCC? First, we know that cs. lib contains some common functions, so that TCC does not need to include header files when compiling programs with basic functions. Secondly, we know that functions in the same file are generally correlated. Some of them call each other to implement a common function, while others implement different functions but operate on the same type of data. These functions are written in the same file and included in the file at the same time. This reduces the number of errors caused by no inclusion. In addition, you can replace the functions in a customized manner, ensuring the diversity of programs and convenient modification features.