On Wed, 2021-04-21 at 06:33 -0500, Peng Yu wrote: > > > On Wed, Apr 21, 2021 at 3:59 AM Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> > wrote: > > On Wed, 2021-04-21 at 08:23 +0100, Jonathan Wakely via Gcc-help > > wrote: > > > On Wed, 21 Apr 2021, 08:04 Tadeus Prastowo wrote: > > > > > > > On Wed, Apr 21, 2021 at 6:33 AM Peng Yu <pengyu.ut@xxxxxxxxx> > > wrote: > > > > > > > > > > > > > > > Since it is *link*-time optimization, I suppose it is ld who > > does > > > > > the > > > > > actual work? > > > > > > > > Yes. > > > > > > > > > > > > > Well, sort of. > > > > > > The linker uses a plug-in to invoke the compiler again. The linker > > > doesn't > > > do the optimization itself, because it doesn't know how. > > > > > > So the gcc driver runs collect2 which runs ld which uses the lto- > > > plugin.so > > > to run the compiler again, then ld finishes linking. > > > > > > The optimization happens *during* linking, but it's still done by > > the > > > compiler. > > > > > > > > > > > > > > If it were implemented in a shell language, it would be easier > > to > > > > > see > > > > > what is going on below the surface, instead of relying on the > > > > > -v > > > > > option. > > > > > > > > Yes. > > > > > > > > > (Probably it is easier to maintain shell scripts rather than C > > > > > code? Also, just for calling others programs, it seems shell > > > > > is > > a > > > > > better implementation language than C.) > > > > > > > > Maybe. > > > > GCC is never designed to be a tool for teaching or learning. It's a > > compiler, for compiling programs in real-life. Basically -v is only > > intended to debug GCC itself. > > > > For learning, as I insisted you need a textbook, > > > > > But there is not a textbook that covers the details offered by gcc -v > -Wl, -v. So this analogy is nonsense for people wants to know the > details. Then you should blame the teachers (or the universities, because they don't have a proper mechanism to encourage the teachers to write such a textbook or open such a course), not GCC. GCC is never designed to let people know all the details. And from your previous posts it can be shown that you don't quite understand the basic concepts, then you shouldn't jump into the details too early. For example, you should at least read CS:APP for the topic about linking. > > instead of doing some > > experiment on a complex system and trying to parse something out of > > the > > result. The "features" or "difficulties" in a real system often > > makes > > learning hard. It's just like you can't learn classical mechanics > > by > > doing some experiments on your car, and you shouldn't say "it would > > be > > better to have a transparent hood for the car". > > > > Unfortunately, while every physics teacher knows he/she shouldn't > > use > > a > > car to teach mechanics, many CS101 teachers keep telling the student > > "if > > you don't understand something, just do a experiment". IMO it's > > pure > > laziness. > > > > And the GCC driver is not only calling other programs. For example, > > the > > driver handles -march=. For -march=native the driver checks local > > CPU > > feature and rewrite a value like -march=icelake-client. It also > > sets > > flags like -mavx2 for different -march= values. The driver also > > parses > > the spec file (I think there is no way to parse a complex file with > > shell). > > > > > You missed the point. Shell should be used as a glue. For low level > things like this, it still should be made in C. It is just that it > could be called by shell. GCC is GPL'ed. So you can fork it and rewrite the driver in shell, then (optionally) send the changes to gcc-patches. Nobody will prevent you. > > Even if using a shell script is possible, it will be very difficult > > and > > may introduce many bugs. Some of those bugs may be extremely > > dangerous: > > I remember several bugs occured in shell scripts, invoking "rm -rf > > /*" > > for some unexpected corner case. > > > > > I have to say that is just improper designed script. For C code, you > also are opened to all sorts of vulnerability that C inherits. It is > hard to tell in which way vulerabities are less without quantitatively > measuring it. At least the C compiler would reject the code if you used a wrong variable name. Again, nobody will prevent you if you really want to write the shell code, just a warning here. > > You can read libtool code, for example. Libtool is basically a > > compatibility wrapper for gcc/ld/ar. I'm sure everyone will feel > > disgusting by reading 12562 lines of shell code in it. > > > > > Many shell scripts used in practice are not separated into proper > sourceable files. This makes them hard to understand. Once they are > separated and are accompanied by use case code, it would be easier to > understand. The same thing applies to C, as you could write 10000 > lines C code in a single file, that will also be hard to read and > maintain. It will slow down the compilation of large code base, as for each invocation the shell must read all those script files and parse them. -- Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
