WEBVTT 00:00.820 --> 00:08.140 Welcome to the fascinating assembly phase where the magic of generating real machine code unfolds in 00:08.140 --> 00:09.310 this pivotal stage. 00:09.310 --> 00:15.550 The assembly language files generated during the compilation phase take center stage as the input. 00:15.550 --> 00:21.700 So the output of this phase is a collection of object files also referred to as modules. 00:21.700 --> 00:28.150 So these object files encapsulate the machine instructions that hold the potential to be executed by 00:28.150 --> 00:29.380 the processor. 00:29.380 --> 00:37.510 However, before we can revel in the glory of fully operational binary executable, there are three 00:37.510 --> 00:40.060 more essential steps to undertake. 00:40.060 --> 00:46.390 So it's important to note that each source file typically corresponds to an assembly file, and in turn 00:46.390 --> 00:50.380 each assembly file corresponds to an object file. 00:50.380 --> 00:59.950 So to generate an object file, you can simply append the C flag to your GCC here. 00:59.950 --> 01:08.360 So in order to do that, we will again use the My app dot C and GCC here. 01:08.360 --> 01:14.990 And after that C parameter C flag and I'm sorry here. 01:14.990 --> 01:15.560 Yeah. 01:15.560 --> 01:24.950 And after that we will enter our my app dot C and here we created a new file and now we're going to 01:24.950 --> 01:25.880 open it. 01:26.360 --> 01:32.210 Mouse pad my app dot Oh here. 01:32.870 --> 01:38.390 And as you can see, this document is not UTF eight valid, but we will still going to open it. 01:38.390 --> 01:38.840 But. 01:38.960 --> 01:42.020 And as you can see, we are seeing nothing here. 01:42.020 --> 01:46.220 So you can use the you can also use the file utility here. 01:46.580 --> 01:50.300 File my app dot. 01:51.240 --> 01:51.990 All here. 01:52.170 --> 02:00.330 And with this file utility, this is a handy utility that it will return, that it will return some 02:00.330 --> 02:02.310 of the information about this here. 02:02.310 --> 02:04.950 And we will also learn that in next lectures. 02:05.130 --> 02:15.150 And here with this file here, we are confirming that the produced file, my app, that all here is 02:15.150 --> 02:16.860 indeed an object file. 02:16.860 --> 02:25.110 So as you can see here, the file shows up as Elf 64 bit LSB relocatable file. 02:25.260 --> 02:27.680 And what exactly does this mean? 02:27.690 --> 02:35.430 So this the first part of the file output shows that the file conforms to the Elf specifications for 02:35.430 --> 02:39.540 binary executables, which we will learn later in this course. 02:39.540 --> 02:49.620 And more specifically, it's a 64 bit Elf file since you are compiling for x86 and 64 in this example 02:49.620 --> 02:58.420 here and it is LSB meaning that numbers are ordered in memory with their least significant byte first. 02:58.420 --> 03:06.790 So but most important, you can see that this file is relocatable and Relocatable files don't rely on 03:06.790 --> 03:10.030 being placed at any particular address in memory. 03:10.030 --> 03:15.730 Rather, they can be moved around and it will without breaking any assumptions in the code. 03:15.730 --> 03:23.650 So when you see the term relocatable in the file output, you know you are dealing with an object file 03:23.650 --> 03:26.530 and not with an executable. 03:26.710 --> 03:36.160 And there are also position independent relocatable executables, but these show up in file as shared 03:36.160 --> 03:38.230 objects rather than relocatable files. 03:38.230 --> 03:44.650 So you can tell them apart from ordinary shared libraries because they have an entry point addresses 03:44.650 --> 03:45.160 here. 03:45.370 --> 03:46.270 So. 03:48.210 --> 03:54.750 Object files are compiled independently from each other, so the assembler has no way of knowing the 03:54.750 --> 03:59.370 memory addresses of the other object files when assembling an object file. 03:59.370 --> 04:03.000 So that's why object files need to be relocatable. 04:03.000 --> 04:03.450 Right. 04:03.450 --> 04:09.620 So that way you can link them together in any order to form a complete binary executable. 04:09.630 --> 04:14.820 So if object files were not relocatable, this would not possible. 04:14.820 --> 04:19.140 So you will see the contents of the object files later in this course. 04:19.140 --> 04:23.010 So when you are ready to disassemble a file for the first time.