在上一篇文章的golang代码中，函数add的上一行，增加了一条注释语句： //go:noinline 。在bpftrace追踪时，是否可以去掉？有什么作用？
为了说明该问题，设计一个例子。
golang代码中，有两个求和函数。其中，add1加上 //go:noinline ，另一个add2不加。代码如下：
bpftrace程序分别对函数add1和add2的输入参数、返回值进行追踪，代码如下：
执行程序后，可以看到bpftrace程序能够正常追踪到函数add1，但是无法追踪到函数add2。
通过上文中的示例代码，可以看到，没有加 //go:noinline 的函数无法被bpftrace程序追踪到。通过查阅golang相关文档，可以知道， //go:noinline 表示该函数在编译时，不会被内联。
使用 objump -S 生成golang程序的汇编代码如下：
通过汇编代码，我们可以看到，主函数中，地址 0x498e52 处 callq 498e00 调用了add1函数，地址 0x498ebb 处 movq $0x4,(%rsp) 直接计算求值。
因此，golang编译器在编译代码时，会对代码进行分析，并按照内联规则，将某些函数生成内联代码。一旦函数被内联，bpftrace将无法追踪到对应函数。也就是，上文中函数 add2 无法被追踪到。
针对golang程序中编译器内联的问题，可以通过禁止内联的方式来解决。禁止内联的方式有：
在实践中，可以通过 go build -gcflags="-m -m" 来查看，哪些函数会在编译时执行内联，如：
从输出中，可以看到：
关于golang编译器进行内联的场景，可以参考golang源码：https://github.com/golang/go/blob/master/src/cmd/compile/internal/inline/inl.go。
由于golang编译器内联优化，bpftrace可能无法正常追踪golang程序。在编写bpftrace脚本时，可以先使用 nm 命令查看一下可执行程序，是否存在需要追踪的函数的符号信息。如果没有则bpftrace将不能对其进行追踪。
前面的示例中，都是对 int 类型的参数进行追踪，那对于 string 类型的参数，是否也可以用同样的方式进行追踪？将在下一篇中进行讨论。
在Go语言中，规定的方式是，函数返回错误信息。这没什么。如果一个文件并不存在，op.Open函数会返回一个错误信息。这没什么。如果你向你一个中断了的网络连接里写数据，net.Conn里的Write方法会返回一个错误。这没什么。这种状况在这种程序中是可以预料到的。这种操作就是容易失败，你知道程序会如何运行，因为API的设计者通过内置了一种错误情况的结果而让这一切显得很清楚。
从另一方面讲，有些操作基本上不会出错，所处的环境根本不可能给你提示错误信息，不可能控制错误。这才是让人痛苦的地方。典型的例子；一个程序执行
x[j]，j值超出数组边界，这才痛苦。像这样预料之外的麻烦在程序中是一个严重的bug，一般会弄死程序的运行。不幸的是，由于这种情况的存在，我们很难写出健壮的，具有自我防御的服务器——例如，可以应付偶然出现的有bug的HTTP请求处理器时，不影响其他服务的启动和运行。为解决这个问题，我们引入了恢复机制，它能让一个go例程从错误中恢复，服务余下设定的调用。然而，代价是，至少会丢失一个调用。这是特意而为之的。引用邮件中的原话：“这种设计不同于常见的异常控制结构，这是一个认真思考后的决定。我们不希望像java语言里那样把错误和异常混为一谈。”
我刚开始提到的那篇文章里问“为什么数组越界造成的麻烦会比错误的网址或断掉的网络引出的问题要大？”答案是，我们没有一种内联并行的方法来报告在执行x[j]期间产生的错误，但我们有内联并行的方法报告由错误网址或网络问题造成的错误。
使用Go语言中的错误返回模式的规则很简单：如果你的函数在某种情况下很容易出错，那它就应该返回错误。当我调用其它的程序库时，如果它是这样写的，那我不必担心那些错误的产生，除非有真正异常的状况，我根本没有想到需要处理它们。
有一个你需要记在心里的事情是，Go语言是为大型软件设计的。我们都喜欢程序简洁清晰，但对于一个由很多程序员一起开发的大型软件，维护成本的增加很难让程序简洁。异常捕捉模式的错误处理方式的一个很有吸引力的特点是，它非常适合小程序。但对于大型程序库，如果对于一些普通操作，你都需要考虑每行代码是否会抛出异常、是否有必要捕捉处理，这对于开发效率和程序员的时间来说都是非常严重的拖累。我自己做开发大型Python软件时感受到了这个问题。
Go语言的返回错误方式，不可否认，对于调用者不是很方便，但这样做会让程序中可能会出错的地方显的很明显。对于小程序来说，你可能只想打印出错误，退出程序。对于一些很精密的程序，根据异常的不同，来源的不同，程序会做出不同的反应，这很常见，这种情况中，try
+
catch的方式相对于错误返回模式显得冗长。当然，Python里的一个10行的代码放到Go语言里很可能会更冗长。毕竟，Go语言主要不是针对10行规模的程序的。
就是要说明这一点：Go语言程序员认为，把error作为一种内置的类型是非常重要的。
