• CSAPP阅读笔记-gcc常用参数初探-来自第三章3.2的笔记-P113


    gcc是一种C编译器,这次我们根据书上的代码尝试着使用它。

    使用之前,先补充前置知识。编译器将源代码转换为可执行代码的流程:首先,预处理器对源代码进行处理,将#define指定的宏进行替换,将#include包含的文件插入,随后,编译器生成源文件对应的汇编代码,以.s结尾。然后汇编器会将汇编代码转换为机器代码,以.o结尾,最后,链接器将多个机器代码(如果有多个的话)以及代码中用到的库函数(如printf)合并,产生可执行文件。

    若要比较详细地了解gcc常用参数,可以参考这篇文章:

    https://www.cnblogs.com/zhangsir6/articles/2956798.html

    里面讲得比较详细,当然,如果像我一样想要以书为导向,看到不懂的再学,可以先不看那个,先继续看下面的文章。

    为了演示gcc的用法,书中演示了命令行 gcc -Og -o p p1.c p2.c的运行效果,我们需要做下实验:

    我使用的是MAC,直接打开终端就可输入命令行来实验了,要注意的是p1.c和p2.c需要自己生成,且这两个文件必须位于当前目录下。

    首先用xcode新建个c程序,名为p1.c,里面敲入最简单的代码,如下:

     同理,再创建个p2.c,随后将两个文件放到想要测试的目录下,比如我在桌面新建了"测试gcc"文件夹:

    打开终端,使用cd指令进入到此目录下(暂时不会linux,先用最简单的方法,打下cd,随后拖动对应目录进终端,会自动把路径导入,如下图)

     

     

    按回车,进入此目录:

    先尝试下

     gcc -Og -o p p1.c p2.c  这条指令,会发现居然报错了!结果如下:

    因为p1.c和p2.c都有main函数,导致报错了,好,那现在就把p2.c的主函数注释掉吧,如下:

    重新执行指令,效果如下:

    生成了名为p的可执行文件,可以看到它没有后缀,点开看看有什么惊喜:

    看到那个p1.clogout没?那是p1.c的main函数中输出的东西。

    至此,书上的代码执行完毕,开始思考。

    1.gcc的是区分大小写的,这点自己试试就能发现。

    2.-Og(注意,是大写的字母O,不是数字0)代表要求gcc编译器使用符合原始C代码整体结构的机器代码的优化等级,说白了就是编译器在把源代码变成机器语言时会作一定程度的优化,导致产生的机器代码出现了变形。同样的,也有-O1,-O2,-O3,-O4等等优化等级,数字越大优化等级越高。-Og是在gcc 4.8版本引入的,基本相当于没有优化。

    3.编译时可以指定文件生成到流程的哪一步,比如-S用来指定生成汇编代码(以.s结尾),-c可以指定生成到机器代码(以.o结尾),若什么都不输入,则默认生成到可执行文件,展示如下:

     

    可以看到,生成的.s以及.o文件默认都是和源文件同名的,可执行文件则默认命名为a.out。

    3.-o是用来指定目标名称的,可以在指定名字的时候加上对应的后缀,以生成不同类型的文件,比如hello.exe,hello.asm等,如下图所示:

     

    这里有个疑问,若我不生成可执行文件,只生成.s或者.o文件,但不想用默认的p1.s作为名字,是否能通过-o改呢?另外,改的时候如果没有用.s作后缀名,会怎样呢?下面是结果:

    可以看到,不仅仅是可执行文件,即使是.s文件,也是可以用-o的方式改名的。另外,虽然这个时候名字被改变了,乃至后缀都变了,比如那个test,但其实内容和直接生成的p1.s是一样的,可以看到它们的大小都是相同的,用文本编辑器打开会发现内容相同。当然了,为什么test.s和p1.s大小不同就不懂了,试着打开了test.s,结果是乱码。。。难道是生成了机器码嘛?

    当然,以上结果对.o文件应该也适用,简便起见就没做测试了。

    4.我发现一个奇怪的现象,似乎gcc编译器对语法的检测是有限制的?

    现象如下:我先把p1.c里的main函数改个名,如mafin,此时居然能生成.s和.o文件,直到生成可执行文件时才报出错来:

     

    按我以前了解的知识,编译器在编译的时候不应该就直接检测语法错误了吗?为什么生成.s时不报错?难道以前是我记错了,是在链接的时候检测的?

    我做了另一个实验,把main改正常,并在main函数里随便打了一串字符,结果如下:

    这次倒是对了,生成.s文件的时候肯定进行了语法检测,那只能说明main改成mafin不算语法错误?不可思议,我又尝试把main函数注释掉,加了个函数进去,结果和第一次一样,如下:

    .s和.o能直接生成,也是到了生成可执行文件才报错。

    好吧,我没有耐心了,后面还有很多东西要看,姑且暂时认为main函数里出了错不算语法错误吧,可能需要学完编译原理才能解释这个现象。

    5.还记得当时测试书上的代码时我们同时编译了p1.c和p2.c吗?如果按照那个方式写,编译器会分别对二者生成到.o并链接,最后生成可执行文件,显然,有两个main函数会报错的,那如果我们不生成可执行文件,仅仅是同时生成.s和.o文件,在存在两个main函数的情况下,会报错吗?结果如下:

     

    答案是:不会报错,能同时生成。

    那么如果同时对两个文件生成.s,且要同时分别命名是否可以呢?结果如下:

    根据提示来看,是不支持的,不管你是用gcc -S -o test1 p1.c p2.c还是妄图施展gcc -o test1  -S p1.c -o test2 -S p2.c这样的骚套路,统统都是行不通的。。

    当然,gcc的命令参数很多很多,这儿仅仅是基于书上的内容作的一些测试和拓展,想要了解更多请看开头的链接,让我们愉快地结束这一节吧。

    (有疑惑的,请看博客的“写在前面”一章)

  • 相关阅读:
    第十一篇:Mysql系列
    mysql八:ORM框架SQLAlchemy
    mysql七:视图、触发器、事务、存储过程、函数
    mysql六:数据备份、pymysql模块
    工厂方法模式
    execution表达式
    CentOS系统下安装SVN及常用命令
    Spring Boot 表单验证、AOP统一处理请求日志、单元测试
    SSH文件上传代码片段
    JPA 实体映射
  • 原文地址:https://www.cnblogs.com/czw52460183/p/10012610.html
Copyright © 2020-2023  润新知