the handle of inline is incorrect

[fumeboy]

the current handle in this repo is incorrect, it fills the caller's funcID instead of the callee's to the InlinedCall.funcID

https://github.com/pkujhd/goloader/blob/master/inlinetree.go#L32

in go source code (go1.19.6), the funcID is got from other object file by linker.Package[SymRef.Pkg][SymRef.SymIndex].funcID

but we cannot do this because we are unable to obtain these original Go object files used when compiling at runtime.

I suggest to use the -l option of go tool compile to disable inline

go source code (go1.19.6)

        // genInlTreeSym generates the InlTree sym for a function with the
	// specified FuncInfo.
	func genInlTreeSym(ctxt *Link, cu *sym.CompilationUnit, fi loader.FuncInfo, arch *sys.Arch, nameOffsets map[loader.Sym]uint32) loader.Sym {
		ldr := ctxt.loader
		its := ldr.CreateExtSym("", 0)
		inlTreeSym := ldr.MakeSymbolUpdater(its)
		// Note: the generated symbol is given a type of sym.SGOFUNC, as a
		// signal to the symtab() phase that it needs to be grouped in with
		// other similar symbols (gcdata, etc); the dodata() phase will
		// eventually switch the type back to SRODATA.
		inlTreeSym.SetType(sym.SGOFUNC)
		ldr.SetAttrReachable(its, true)
		ldr.SetSymAlign(its, 4) // it has 32-bit fields
		ninl := fi.NumInlTree()
		for i := 0; i < int(ninl); i++ {
			call := fi.InlTree(i)
			val := call.File
			nameoff, ok := nameOffsets[call.Func]
			if !ok {
				panic("couldn't find function name offset")
			}

			inlTreeSym.SetUint16(arch, int64(i*20+0), uint16(call.Parent))
			inlFunc := ldr.FuncInfo(call.Func)

			var funcID objabi.FuncID
			if inlFunc.Valid() {
				funcID = inlFunc.FuncID()
			}
			inlTreeSym.SetUint8(arch, int64(i*20+2), uint8(funcID))

			// byte 3 is unused
			inlTreeSym.SetUint32(arch, int64(i*20+4), uint32(val))
			inlTreeSym.SetUint32(arch, int64(i*20+8), uint32(call.Line))
			inlTreeSym.SetUint32(arch, int64(i*20+12), uint32(nameoff))
			inlTreeSym.SetUint32(arch, int64(i*20+16), uint32(call.ParentPC))
		}
		return its
	}

[pkujhd]

@fumeboy, it is a bug, we could read funcId from objsymbolMap[inl.Func].Func.FuncID.

[pkujhd]

could you give me a testcase for it

[fumeboy]

@fumeboy, it is a bug, we could read funcId from objsymbolMap[inl.Func].Func.FuncID.

我的意思是, 比如我内联了 fmt 包的一个函数, 但是我没有 fmt 包的 object file, 怎么能根据 symidx 找到它是哪个符号, 并获取 funcID 呢

我也很惊讶这样似乎也能正常运行; 我目前也构造不了错误 case

[pkujhd]

是的，如果是外部包是无法得到信息的，所以如果查不到符号，用了默认值funcID_Normal

[pkujhd]

要处理的话，golang1.12-1.15可以直接去读firstmodule的_func查到funcID，因为较早版本的obj里存了名字（但是1.15的名字是空的,应该是即将使用新的obj结构引入的问题）； 1.16以后，就需要把fmt包读进来，才能知道相应的id是的symbol的名字是啥，现在对于外部包resolveSymRef回来的名字都是空字符串。
所以关闭inline也是可选的，毕竟1.9才开始支持，之前都没有inline， 1.12才算比较好用

[fumeboy]

直接使用 FuncID_normal 没问题吗, 为什么呢

[pkujhd]

直接使用 FuncID_normal 没问题吗, 为什么呢

大部分情况下都是FuncID_normal ，实际上遇到的函数应该都是FuncID_normal 的， 而且这个inlineTree只在输出stack的时候用，对于执行应该没有太大的影响。 对于系统函数是错的，目前除了上面说的方案没有更好的方案.

[fumeboy]

直接使用 FuncID_normal 没问题吗, 为什么呢

大部分情况下都是FuncID_normal ，实际上遇到的函数应该都是FuncID_normal 的， 而且这个inlineTree只在输出stack的时候用，对于执行应该没有太大的影响。 对于系统函数是错的，目前除了上面说的方案没有更好的方案.

感觉并不是那么简单, 因为我看 inlineTree funcID 被 gentraceback 使用, gentraceback 应该和 GC 有关

[pkujhd]

gentraceback

是和栈相关，因为runtime.morestack, runtime.systemstack和cgocall会改变栈结构，所以需要特殊处理

[fumeboy]

看了下 funcID 的非 0 值对应的函数, 都不可能被内联, 那看来直接设置成 normal 是没问题的, 但既然如此为啥他们还要保留这个字段呢 ..

[pkujhd]

看了下 funcID 的非 0 值对应的函数, 都不可能被内联, 那看来直接设置成 normal 是没问题的, 但既然如此为啥他们还要保留这个字段呢 ..

这个玩意之前没有，1.12版本加进去的