这个家伙很懒, 什么也没留下
能力说明:
掌握计算机基础知识,初步了解Linux系统特性、安装步骤以及基本命令和操作;具备计算机基础网络知识与数据通信基础知识。
阿里云技能认证
详细说明# 为什么go的返回值写在后面 go一直被鼓吹语法比java好, 性能跟c一样. 让我们来看一看go语言各部分对应的二进制指令, 是如何实现的 现在的想法是写个一系列文章, 把go的所有语法的实现方式都分析一遍, 不知道会不会半途而废 ### 本文所有的分析方法, 结论都是本人猜测的, 查各种文档太费时间了, 当然不是乱猜, 都是有依据的 先看栈回溯最基本的方法, rbp, r
# go string 内部实现 这个string的探索 来来个例子 ``` func boo(a int, b int)(int, string){ return a + b, "abcd" } ``` ``` 81079 000000000044dfa0 : 81080 44dfa0:>------48 c7 44 24 18 00 00 >--movq $0x0
# movq %rcx, %gs:0x80000000不能通过编译 今天有同事提问, 为什么 ``` movq %rcx, %gs:0x7fffffff //可以通过编译 movq %rcx, %gs:0x80000000 //不能通过编译 ``` 其实就是一个立即数的差别, 应该是无差的, 好吧, 让我们来研究一下 # 第一步 先看一下```movq %rcx, %g
在写go的时候, 经常会有这样的情况 ``` a, err := x() b, err := y() ``` 虽然第二行是使用:=, 但是还是和第一行的err是一个值 但是当下面这种情况 ``` a, err := x() if true { b, err := y() } ``` 就不是一个值了, 因为有了{}这个作用域 总结就是=都用旧值, :=的之后至
gdb调试kernel的时候, 如果设置通用函数断点, 比如vfs_read, 就会遇到一堆撞到断点的地方, 比如tty输入一个字符, 就是vfs_read, 没办法调试具体的某一个进程 一种办法就是条件断点, 其实不是很好用, 比如用pid, 但是有时候这个进程还没启动, 比如task的comm来判定, 但是kernel中是不支持strcmp来判断字符串是否相等, 因为需要跑函数 g
lmbench有很多测试集, lat_mem_rd是用来测试内存延迟的 # 使用方法 ./bin/x86_64-linux-gnu/lat_mem_rd 1 16 #./bin/x86_64-linux-gnu/lat_mem_rd 1(范围, 单位M) 16(步长) "stride=16 0.00049 1.584(单位M, 512字节范围内, 步长16访问延迟, 为什么显示
gdb调试kernel的时候, 如果设置通用函数断点, 比如vfs_read, 就会遇到一堆撞到断点的地方, 比如tty输入一个字符, 就是vfs_read, 没办法调试具体的某一个进程 一种办法就是条件断点, 其实不是很好用, 比如用pid, 但是有时候这个进程还没启动, 比如task的comm来判定, 但是kernel中是不支持strcmp来判断字符串是否相等, 因为需要跑函数 g
# 简介 最近在upstream上, Johannes Weiner发了一个memdelay的patch, 主要是衡量系统内存的健康程度, 在对它进行分析和优化之后, 做了一个简单的总结 memdelay是衡量一个系统(memcg)中内存的健康程度的一个监控系统, 可以用来评价一个memcg的limit是否设置得合理 # 主要功能 - 监控每个task因为内存短缺导致的延迟 -
今天在调试内核的时候, 发现一个变量指针在一个函数中变了, 但是代码中又没有改变他的值 ``` (gdb) p sc $13 = (struct scan_control *) 0xffffc900079b3da8 (gdb) n (gdb) p sc $14 = (struct scan_control *) 0xffff880a4c55a800 ``` 根据以往的经验, 肯定是
linux的crash有个好处就是可以方便打印结构体成员变量的offset, 有时候对汇编的时候, 需要偏移, 可惜crash需要一个活体才行, 不能单纯的vmlinux, 因为它就是这么设计的 gdb天生没有这个功能, 不过python可以实现 cat offset.py import gdb class Offsets(gdb.Command): def __in
这几天在做性能的优化, 主要是在kernel的调度模块加了信息采集, 导致延迟增加了100ns, 在经过一系列的优化之后, 延迟较少到了50ns, 不过在检查最后汇编代码的时候 发现有个地方gcc工作得不是很好, 仔细研究了一下. 以下是记录 ``` c代码 void memdelay_enqueue_task(struct task_struct *p, int flags) {
别的文章都会做很多说明, 铺垫, 我就不多说了, 直接来重点 vim写代码的时候, 有一种情况不是很好处理, 比如 struct a{int x; int y; iny z} struct b{int x; int y; iny z} pb->z想从这里跳到到结构体b的定义需要编辑器理解pb的含义, 而不是简单的字符查找 那就让我们来用source insight吧 以
新手来说, 调试内核c代码经常上下乱跳, 但是O0又无法通过编译, 做了一个实验, 对于所有的c文件, 先尝试O0, 如果错误的话, 用O1来编译, 但是最后有一些符号找不到, 因为O0会多调用一些函数, 在这些问题都解决了之后, 最后居然报出, 某个section太大了, 看来这个问题很复杂 下面是一个简单得方法, 不要一口气把所有的文件都O0, 需要调试哪个, 把具体文件O0就行了
之前写过很多kernel的gdb debug, 其实用户态也是可以调试的, 只是在共享库的动态地址上不是很好处理, 最近同事有调试系统启动过程中systemd的需求, 简单研究了一下 其实qemu kvm打断点并不区别kernel还是用户态, 都是rip的值等于某个地址或者遇到断点指令了, 所以开机的时候把断点打到systemd的main上就可以了 但是其实另外一个问题是, 用户态的地
简单一点, 有时候我们调试代码的时候, 比如ls, ps某些不是自己写的代码的时候, 经常被O2搞得跳来跳去, 来个O0就很简单, 但是自己下载下来的源代码的configure很复杂, O0有时候加了这里, 还有那里, 这里有一个简单方法 就是在c文件的第一行加上 ``` #pragma GCC optimize("O0") ``` 就可以了, 不需要管gcc的参数了, 这个优先级高
在gcc使用-g3编译的时候, gdb可以查看对应c语言的宏. ``` gdb a.out -ex 'list main' -ex 'info macro XXXX' -ex 'q' Defined at /xvdc/w.c:6 #define XXXX ppppppppppppp ``` 但是o文件却看不了对应的宏, ``` gdb w.o -ex 'list ma
很多时候在前台调试好程序, 但是放到后台就一直没有结果, 比如说crontab, systemd之类的, 而且不大好调试, 因为后台程序的启动者不是自己, 这种情况都是不同的env造成的. 比如前台的时候有path变量, 可以直接执行cmd, 但是后台没有path变量, 就不能执行了, 那么问题来了, 前台如何造一个后台一样的环境呢 ``` 1. 获取后台的env, 比如crontab的
工作中, 经常会读取proc或者sys目录下的很多文件, 比如cat /proc/cmdline, cat /proc/uptime之类的, 有时候我们想看看对应的内核实现, 却不知道从哪里找起, 老司机们当然很容易从源代码中根据经验和某种规律找出来, 但是新手就困难得多. 下面有一种办法是很容易得获得这些接口文件对应的内核函数 trace-cmd trace-cmd record -
今天看了一本书, linux内核技术手册, 很多东西豁然开朗, 里面有一些东西写点总结给大家看一下 其实我还挺喜欢看手册之类的书, 因为看完之后, 可以对某个工具的所有功能有个大概的了解, 比如Makefile手册, vim手册, gcc手册. 虽然所有的用法不会都去尝试一遍, 但是知道了有这个东西, 哪天用得时候就会想起来, 不然的话, 需要解决一个问题的时候, 都不知道有这个东西的存在,
今天在vmlinux上设置断点的时候出现4个地址, 超乎认知了, 仔细得看了一下原因 ``` (gdb) b sched_clock Breakpoint 1 at 0xffffffff8101cf00: sched_clock. (4 locations) (gdb) i b Num Type Disp Enb Address What
今天同事问我, linux的中断可以嵌套吗? 我说我也不知道啊, 印象中是cpu是可以中断嵌套的, 但是linux关掉了, 所以linux是不允许中断嵌套的, 如何证明, 找代码, 突然跳到另一个领域, 哪有这么快能找到, 看代码不如看系统 直接开个vm, 把状态停到中断函数里面, 比如do_timer ``` Breakpoint 1, do_timer (ticks=1) at k
这是以前研究生的时候写的一篇文章 今天看了一篇文章关于cpu乱序执行的讲解,主题思想是cpu能并行的处理指令,这里的并行不是多核并行的处理,而是在某种情况下,上下2条指令可以被一个核一起送行,还有可能在下面的指令先运行,称为乱序执行,out of order,这也带来了超标量,1个时钟周期可以运行大于1条指令。这在以前是不可想象的,在理想情况下,一个时钟最多执行1条,但是创新是无界限的。
内核调试中, 经常会有race, 方便的调试方法可以手动造一个环境出来模拟一下我们想要的时序, 来验证想法. * * * 比如说, a, b, 2个task, 想让a跑到某行指令的时候, 暂停运行, 然后让b运行来尝试进入共有的临界区, 一种最简单的想法就是在a的代码中加入sleep, sleep其实会引发调度, 所以就改成while 1, 改成while 1, 其他task跑
大家都知道lseek就是移动文件的读写位置, 也就是对应内核中file结构体中的某一个变量, 今天就是特别想看一下具体之间的关系. 软件就在于实践 首先需要有一个很方便调用lseek的环境, 这样才不会影响我们调试的兴趣, 希望能达到像python, matlab这样每个函数可以手动跑, 而不像c语言一样要编写, 然后编译, 然后执行, 然后再修改, 编译. gdb可以 1. 先准备文件