Re: How to check what underlying commands are called by gcc?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

>
>
> 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.

>
>
> 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.


> --
> Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
> School of Aerospace Science and Technology, Xidian University
>
> --
Regards,
Peng



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux