技术

下一个平台Agent 激发LLM涌现——提示工程 LLM微调理论及实践 大佬沉思 LLM外挂知识库 LLMOps 多模态LLM Python一些比较有意思的库 LLM部分技术源码学习 LangChain源码学习 通用分布式计算引擎Ray Python并发 go依赖注入 go collection gc的基本原理 golang性能分析及优化 数据湖 高性能计算与存储 Linux2.1.13网络源代码学习 《大数据经典论文解读》 三驾马车学习 Spark 内存管理及调优 Yarn学习 从Spark部署模式开始讲源码分析 容器狂占内存资源怎么办? 多角度理解一致性 golang io使用及优化模式 Flink学习 c++学习 学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器以及defer实现 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go堆内存分配 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 共识算法 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 容器日志采集 Kubernetes 控制器模型 容器狂占资源怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 如何分发计算 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂? 递归、回溯、动态规划 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型和jvm内存布局 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle/make使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

大模型推理服务框架 模型服务化(未完成) 大模型RHLF 大模型训练 大模型推理 从Attention到Transformer k8s设备管理 LLM工具栈 ddd从理念到代码 如何应用LLM 小鼠如何驾驭大象(LLM)? 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 AutoML和AutoDL 特征平台 实时训练 分布式链路追踪 helm tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 机器学习中的python调用c 机器学习训练框架概述 embedding的原理及实践 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从混部到统一调度 从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 tensorflow学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Admission Controller 与 Admission Webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 概率论 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 架构大杂烩 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

k8s设备管理 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 helm 从混部到统一调度 volcano特性源码分析 kubebuilder 学习 client-go学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 openkruise学习 基于Kubernetes选主及应用 Admission Controller 与 Admission Webhook k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? Kubernetes events学习及应用 CRI 资源调度泛谈 如何学习Kubernetes 以应用为中心 kubernetes operator kubernetes扩缩容 serverless 泛谈 什么是云原生 自定义CNI IPAM docker和k8s安全访问机制 Kubernetes监控 Kubernetes 控制器模型 Kubernetes资源调度——scheduler Kubernetes类型系统 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 Kubernetes源码分析——从kubectl开始 kubernetes yaml配置 CNI——容器网络是如何打通的 当我在说PaaS时,我在说什么 《深入剖析kubernetes》笔记 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件

C语言学习

2019年04月19日

简介

为什么 C 语言使用如此广泛呢?我认为原因有两个

  1. 有着远优于大部分其他语言的程序精确控制能力,C 语言在设计上对平台独立的低层次汇编指令进行了适度的抽象,在大多数情况下,它的代码可以直接映射到硬件平台上的机器指令。因此,我们能够更加灵活地控制程序的具体表现行为。比如可以直接控制代码中某个变量值的存放位置,视情况来决定将它存放在栈内存中,还是寄存器中。在某些特殊场景下,我们甚至可以直接在 C 代码中嵌入汇编代码
  2. 高效的运行时性能。

我们知道,c 语言代码gcc编译后可以直接执行,其语言与汇编代码具有比较直接的对应关系,笔者个人感觉C比汇编语言主要增强了两点:

  1. 变量的概念,内存分配变成了变量声明。
  2. 函数的概念,栈 + cpu出入栈寄存器 + 指令 封装出了函数概念,使得代码有机会(低水平的)模块化编程,简化了大规模开发的复杂度。

现在我们站在 C 语言设计者的角度想一想,一门既能写程序,又更容易让人类理解的语言要怎么设计?其实这门语言的“设计过程”,就是 C 语言对机器语言的抽象,也就是 C 语言对程序的抽象。C 语言是如何抽象程序的?

程序里的内容 抽象为C语言中的
数据 抽象为各种类型的变量,用于存放数据
操作 抽象为各种运算符,用于操作数据
运行 抽象成表达式和流程控制,控制程序的运行
一段完成特定功能的语句 抽象成函数,供别人调用

变量

C 语言的重要组成当然是 C 语言代码。这个说法当然没错,但代码只是一个统称。从不同层次抽象,里面的内容是不一样的:从高层次看代码中只有声明和定义,下一层看代码只有函数和变量,变量进一步分解还有不同的类型。一段程序从语法角度来说就是声明加上定义。

C 语言中经常容易混淆声明和定义这两个概念

  1. 声明是给变量、函数、结构体等命名,表明在程序代码中有该变量、函数、结构体。在 C 语言文法中仅仅需要有声明就可以,声明不会分配内存空间,只有声明的代码确实能编译成功,但链接的时候就不一定了。声明只是一种说明性质的东西,不产生机器指令
  2. 定义是具体给变量分配内存空间。,会产生对应的机器指令。

位(bit)是计算机中最小的存储单位,字节是最小的可寻址单位

  1. C 标准中规定,int 类型的大小为执行环境架构体系所建议的自然大小。而对于 Rust 和 Java 这些语言来说,它们的语言标准中直接规定了各类型的具体大小。编译器作为编程语言与硬件体系之间的抽象层,它可以确保上层类型在被编译到机器指令时,不会给程序的实际运行带来可观测的差异。
  2. 在 C 语言中,通过内联方式直接写到源代码中的字面量值一般被称为“常量”。使用 const 关键字修饰的变量定义语句,表示对于这些变量,我们无法在后续的程序中修改其对应或指针指向的值。因此,我们更倾向于称它们为“只读变量”,而非常量,编译器通常不会对只读变量进行内联处理。

对于大多数计算机而言,通常其内部会使用补码(Two’s-complement)的格式来存放有符号整数,使用直接对应的二进制位格式来存放无符号整数,使用 IEEE-754 标准编码格式来存放浮点数,也就是小数。使用补码来存放有符号整数的一个优点是,CPU 在针对有符号数进行加减法计算时,不需要由于加数的符号性不同而采用多个底层加法电路,这样便可减轻电路设计的负担,另一方面也可以降低 CPU 的物理尺寸。补码的英文名称是 two’s-complement,可直译为“对数字 2 的补充”。PS:补码 的内涵非常多

变量数据的存储

  1. 初始化的全局变量和静态变量,这类变量的值具有与应用程序同样长的生命周期,其值通常会被存放到进程 VAS(Virtual Address Space,虚拟地址空间)内的 .data 中。未初始化的全局变量和静态变量存放到进程 VAS 的 .bss中。
  2. 局部变量是我们在编写程序时最常使用的一种变量形式。一般来说,这些变量将被存放在寄存器或应用程序 VAS 的栈内存中,具体使用哪种方式则依赖于编译器的选择。
  3. 通过 malloc、calloc 等标准库函数创建的内存块中所包含的数据存放到进程 VAS 堆内存中。
  4. 由于常量本身的不可变特征,它们会按照数据的大小和类型被选择性存放到进程 VAS 的 .rodata 以及 .text 中。其中,.rodata 用于存放只读(Read-only Data)数据,而 .text 通常用于存放程序本身的代码。
  5. 在 C 语言中,每一个自定义枚举类型中的枚举值,都是以 int 类型的方式被存储的
  6. 结构只是对其内部所包含各类数据的一个封装,因此从编译产物的角度来看,只需要把它封装的这些数据连续地存放在内存中即可,细节上会考虑“数据对齐”。因此,此时的结构大小也会被作为 sizeof 运算符的最终计算结果。

运算

  1. 算数、关系、位、赋值这四类运算符在经过编译器处理后,一般都可以直接对应到由目标平台上相应机器指令组成的简单计算逻辑。
  2. 逻辑与运算符并没有可与之直接对应的汇编指令。并且,为了满足“短路”要求,编译器在非优化的实现中通常会使用条件跳转指令,比如 je。
  3. 对于取地址运算符 “&”,实际上它一般会直接对应到名为 lea 的汇编指令。这个指令的全称为 “Load Effective Address”,顾名思义,它主要用来将操作数作为地址,并将这个地址以值的形式传送到其他位置。 而解引用运算符 “*”的行为与取地址运算符完全相反。当需要对位于某个地址上的值进行传送时,我们可以直接使用 mov 指令。
  4. sizeof 运算符是一个编译期运算符,这意味着编译器仅通过静态分析就能够将给定参数的大小计算出来。运算符在编译过程中得到的计算结果值,将会以字面量值的形式直接“嵌入”到汇编代码中使用。
  5. 强制类型转换运算符,将变量 n 的值类型由原来的 int 转换为了 short。当 mov 指令将变量 n 的值移动到变量 f 所在的内存区域时,它仅移动了这个值从低位开始一个 WORD,即 16 位大小的部分。
  6. 循环语句和 if 语句的秘密在于比较指令和有条件跳转指令(jmp是无条件跳转指令),它们都用到了 EFLAGS 寄存器。

为什么会有头文件

理解C++中的头文件和源文件的作用

代码分拆,再通过编译器 + 方法声明(符号引用) 整合起来:

  1. 项目大了,一个.c 文件写不下,所以分成好几个.c 文件
  2. a.c 里有一个hello 方法, b.c 怎么知道并使用呢?b.c 可以先声明 有一个hello 方法,根据hello 方法声明找 hello 方法定义的工作交给编译器。编译器在编译b.c的时候会生成一个符号表(symbol table),像“void hello()”这样的看不到定义的符号,就会被存放在这个表中。在进行链接的时候,编译器就会在别的目标文件中去寻找这个符号的定义。
  3. 这里提到了两个概念,一个是“定义”,一个是“声明”。简单地说,“定义”就是把一个符号完完整整地描述出来:它是变量还是函数,返回什么类型,需要什么参数等等。而“声明”则只是声明这个符号的存在,即告诉编译器,这个符号是在其他文件中定义的,我这里先用着,你链接的时候再到别的地方去找找看它到底是什么吧。
  4. 如果hello 方法比较热门,在很多c 文件里都有用到了,那就要多次在使用方那里声明 hello 了。并且,使用hello 方法的人 不一定是hello 的作者,对hello 的声明可能会写错。
  5. 我们可以把hello 声明语句先写好,放在一个文件里,等到程序员需要它们的时候,就把这些东西全部copy进他的源代码中。
  6. 头文件便可以发挥它的作用了。所谓的头文件,其实它的内容跟.cpp文件中的内容是一样的,都是 C++的源代码。但头文件不用被编译。我们把所有的函数声明全部放进一个头文件中,当某一个.cpp源文件需要它们时,它们就可以通过一个宏命令“#include”包含进这个.cpp文件中,从而把它们的内容合并到.cpp文件中去。当.cpp文件被编译时,这些被包含进去的.h文件的作用便发挥了。

头文件的一个重要目的就是为了能够提供一套对外稳定的接口文档,供其他程序使用已经写好的 C 代码实现,以实现代码重用。但为什么其他语言没有借鉴类似的方式,这就说明这种方式并非一种好的设计。Why are header files bad design?

那对于c/cpp来讲呢,最常见到的,头文件和库文件分体设计就是最典型的di,只要是实现了同一个头文件的定义,那么class implementation随时都可以替换。比如我们经常可以通过宏,makefile或者configura.sh发现里面有代码通过判断本地平台是windows还是mac亦或者是linux而加载不同的类实现,而head是不变的。这其实跟java spring context来实现di并无二致,只不过这种注入是编译期发生的。

预处理

预处理器是在编译之前执行一段程序,可以部分的改变我们所写的程序。预处理只有十来个指令,也没有特别严谨的“语法”,但它仍然是一套完整自洽的语言体系,使用预处理也能够实现复杂的编程,解决一些特别的问题——虽然代码可能会显得有些“丑陋”“怪异”。预处理阶段编程的操作目标是“源码”,用各种指令控制预处理器,把源码改造成另一种形式,就像是捏橡皮泥一样。

  1. 预处理指令都以符号“#”开头,虽然都在一个源文件里,但它不属于 C++ 语言,它走的是预处理器,不受 C++ 语法规则的约束。一般来说,预处理指令不应该受 C++ 代码缩进层次的影响,不管是在函数、类里,还是在 if、for 等语句里,永远是顶格写。
     #                              // 预处理空行
     #if __linux__                  // 预处理检查宏是否存在
     #   define HAS_LINUX    1      // 宏定义,有缩进
     #endif                         // 预处理条件语句结束
     #                              // 预处理空行
    
  2. 预处理暂时没有办法调试,不过可以让 GCC 使用“-E”选项,略过后面的编译链接,只输出预处理后的源码。g++ test03.cpp -E -o a.cxx,多使用这种方式,对比一下源码前后的变化,你就可以更好地理解预处理的工作过程了。
  3. “#include”可以包含任意文件,所以可以写一些小的代码片段,再引进程序里;比如说,有一个用于数值计算的大数组,里面有成百上千个数,放在文件里占了很多地方,特别“碍眼”:
     static uint32_t  calc_table[] = {  // 非常大的一个数组,有几十行
         0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
         0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
         0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
         0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
         ...                          
     };
    

    这个时候,你就可以把它单独摘出来,另存为一个“*.inc”文件,然后再用“#include”替换原来的大批数字。这样就节省了大量的空间,让代码更加整洁。

     static uint32_t  calc_table[] = {
     #  include "calc_values.inc"        // 非常大的一个数组,细节被隐藏
     };
    
  4. 预处理变量 有两种状态:已定义和未定义。#define 指令把一个名字设定为预处理变量, #ifdef 和 #ifndef 用来检查预处理变量是否已定义。一旦检查结果为真,则执行后续操作直至遇到 #endif 指令为止。

编译

编译是预处理之后的阶段,它的输入是(经过预处理的)C++ 源码,输出是二进制可执行文件(也可能是汇编文件、动态库或者静态库)。和预处理阶段一样,在这里你也可以“面向编译器编程”,用一些指令或者关键字让编译器按照你的想法去做一些事情。

#include#define 都是预处理指令,是用来控制预处理器的。有没有用来控制编译器的“编译指令”呢?到了 C++11,标准委员会终于认识到了“编译指令”的好处,于是就把“民间”用法升级为“官方版本”,起了个正式的名字叫“属性”。你可以把它理解为给变量、函数、类等“贴”上一个编译阶段的“标签”,方便编译器识别处理。

[[noreturn]]               // 属性标签
int func(bool flag){       // 函数绝不会返回任何值
    throw std::runtime_error("XXX");
}

几个比较有用的(全部属性可参考GCC 文档)。

  1. constructor:函数会在 main() 函数之前执行,效果有点像是全局对象的构造函数。
  2. destructor:函数会在 main() 函数结束之后执行,有点像是全局对象的析构函数。
  3. hot:标记“热点”函数,要求编译器更积极地优化。

《计算机基础实战课》

  1. C 语言变量经过编译器的加工,其变量名变成了汇编语言中的标号,也就是地址。变量空间由汇编语言中.byte.word 等操作符分配空间,有的空间存在于二进制文件中,有的空间需要 OS 加载程序之后再进行分配。
  2. C 语言运算符被转换成了对应的 CPU 运算指令
  3. C 语言函数会被编译器“翻译”成一段带有标号的汇编代码,从一个标号开始到返回指令结束,里面包含了流程控制指令(比如跳转指令)和各种运算指令。这些指令能修改 PC 寄存器,使之能跳转到相应的地址上运行,实现流程控制。
    1. call func完成了两个动作:一是把 call 下一条指令的地址保存到 ra 寄存器中;二是把后面 func 标号地址赋值给 pc 寄存器,实现程序的跳转。PS: 切函数 就是将函数当前位置 保存在 寄存器 一会儿返回,切goroutine 就是函数当前位置(还有栈信息)保存在 g(gobuf、stack)里 等轮到下次执行g了再切回来。
    2. 返回指令 把 ra 寄存器赋值给 pc 寄存器,这样就能实现函数的返回。
  4. 比如说,在汇编语言中调用 C 语言,或者反过来在 C 语言里调用汇编语言。这些情况要怎么办呢?这时候就需要有一种调用约定或者规范。C 语言调用规范解决了函数之间的调用约束,比如哪些寄存器由调用者根据需要保存和恢复,哪些寄存器由被调用者根据需要保存和恢复,函数之间如何传递参数,又如何接收函数的返回值等等的问题。

ELF

LF 的全称是 Executable Linkable Format,是一种二进制文件格式。Linux 下的目标文件、可执行文件和 CoreDump 都按照该格式进行存储。

使用“头部(header)”来保存可执行文件的基本信息。而其他数据则按照功能被划分在了以 Section 或 Segment 形式组织的一系列单元中。

// elf.c
#include <stdio.h>
int main (void) {
  const char* str = "Hello, world!";
  printf("%s", str);
  return 0;
}

操作系统通过 Magic 字段来判断该文件是不是一个标准的 ELF 格式文件,该字段一共长 16 个字节,每个字节代表着不同含义。ELF 头中还包含有 ELF 文件类型、程序的入口加载地址(0x4004b0),即程序运行时将会执行的第一条指令的位置,以及该可执行文件适用的目标硬件平台和目标操作系统类型等信息。ELF 作为一种文件格式,不仅在可执行文件中被使用,静态链接库、动态链接库,以及核心转储文件等也都可以采用这种格式。

ELF 文件格式的基本组成结构可以被划分为 ELF 头、Section 和 Segment 三大主要部分。其中,各个 Section 中包含有按照功能类别划分好的、用于支撑 ELF 功能的各类数据。这些数据共同组成了 ELF 文件的静态视图,以用于支持 ELF 文件的链接过程。而众多的 Segment 则组成了 ELF 文件的动态视图,该视图描述了 ELF 文件在被操作系统加载和执行时,其依赖的相关数据在进程 VAS 内的分布情况。

在 ELF 格式中,Section 用于存放可执行文件中按照功能分类好的数据,而为了便于操作系统查找和使用这些数据,ELF 将各个 Section 的相关信息都整理在了其各自对应的 Section 头部中,众多连续的 Section 头便组成了 Section 头表。Section 头表中记录了各个 Section 结构的一些基本信息,例如 Section 的名称、长度、它在可执行文件中的偏移位置,以及具有的读写权限等。而操作系统在实际使用时,便可直接从 ELF 头部中获取到 Section 头表在整个二进制文件内的偏移位置,以及该表的大小。在 ELF 格式中,众多的 Section 组成了描述该 ELF 文件内容的静态视图。

众多的 Segment 则组成了描述可执行文件的动态视图。每个 Segment 也都有其对应的头部,以描述该 Segment 的一些基本信息,我们一般将其称为 Program 头。Program 头中包含着各个 Segment 的类型、偏移地址、大小、对齐情况,以及权限等信息。其中,被标注为 “LOAD” 类型的 Segment 将会在程序运行时被真正载入到进程的 VAS 中,而其余 Segment 则主要用于辅助程序的正常运行(比如进行动态链接)。

通常来说,各个 Segment 与 Section 之间会有一定的对应关系。

你写的代码是如何跑起来的?在我们编写的代码编译完生成可执行程序之后,下一步就是使用 shell 把它加载起来并运行之。一般来说 shell 进程是通过fork+execve来加载并运行新进程的。fork ==> do_fork ==> copy_process 在 copy_process 函数中为新进程申请 task_struct(拷贝父进程),并用当前进程自己的地址空间、命名空间等对新进程进行初始化,并为其申请进程 pid。执行完后,进入 wake_up_new_task 让新进程等待调度器调度。不过 fork 系统调用只能是根据当的 shell 进程再复制一个新的进程出来,具体加载可执行文件的工作是由 execve 系统调用来完成的。在 execve 系统调用中,首先会申请一个 linux_binprm 对象。在初始化 linux_binprm 的过程中,会申请一个全新的 mm_struct 对象,准备留着给新进程使用。还会给新进程的栈准备一页(4KB)的虚拟内存。还会读取可执行文件的前 128 字节。接下来就是调用 ELF 加载器的 load_elf_binary 函数进行实际的加载。Linux 不是写死只能加载 ELF 一种可执行文件格式的(还有比如out文件,Linux可执行文件加载器,有点java classloader的味道了)。它在启动的时候,会把自己支持的所有可执行文件的解析器都加载上。对于 ELF 文件加载器 elf_format 来说, load_binary 函数指针指向的是 load_elf_binary。 load_elf_binary 大致会执行如下几个步骤:

  1. ELF 文件头解析
  2. Program Header 读取
  3. 清空父进程继承来的资源,使用新的 mm_struct 以及新的栈
  4. 执行 Segment 加载,将 ELF 文件中的 LOAD 类型的 Segment 都加载到虚拟内存中
  5. 为数据 Segment 申请内存,并将堆的起始指针进行初始化
  6. 最后计算并跳转到程序入口执行

其它

void* 是一种特殊的指针类型,可用于存放任意对象地址,不同的是,我们对该地址中到底是个什么类型的对象并不了解。利用void* 指针能做的事儿比较有限:拿它和别的指针比较、作为函数的输入输出,或者赋给另外一个void* 指针,不能直接操作 void* 指针所指的对象。

redis 源码的部分体会

带有详细注释的 Redis 3.0 代码(annotated Redis 3.0 source code)

Redis是一个用ANSI C 编写的开源数据结构服务器。Redis的代码非常容易读懂,代码写的很整洁,并且代码量相对较小(4.5w行,其实也不是很小)。大部分都是单线程的,几乎不依赖其它库。

Redis 没有直接使用 C 语言传统的字符串表示(以空字符结尾的字符数组,以下简称 C 字符串), 而是自己构建了一种名为简单动态字符串(simple dynamic string,SDS)的抽象类型,sds 头文件

struct sdshdr {
    int len;
    int free;
    char buf[];
};
static inline size_t sdslen(const sds s) {
    struct sdshdr *sh = (void*)(s-(sizeof(struct sdshdr)));
    return sh->len;
}
static inline size_t sdsavail(const sds s) {
    struct sdshdr *sh = (void*)(s-(sizeof(struct sdshdr)));
    return sh->free;
}
sds sdsnewlen(const void *init, size_t initlen);
sds sdsnew(const char *init);
sds sdsempty(void);
size_t sdslen(const sds s);
sds sdsdup(const sds s);
void sdsfree(sds s);
size_t sdsavail(const sds s);
sds sdsgrowzero(sds s, size_t len);
sds sdscatlen(sds s, const void *t, size_t len);
sds sdscat(sds s, const char *t);
sds sdscatsds(sds s, const sds t);
sds sdscpylen(sds s, const char *t, size_t len);
sds sdscpy(sds s, const char *t);
...

非常优雅的代码,定义一个结构体,包含各种方法,sds 作为大部分方法的第一个参数,以一个java 开发者的视角来看,这就是在定义一个对象。PS:很多语法、语言特性可能就是在一系列最佳实践的基础上发现的。笔者日常码代码也有类似的体会:每一个细节都保持优雅,自然可以发现重构、复用的地方

Java 程序员眼里的 gcc