may be a bug: the program handles thefindfunctab does not consider the case where the function address spans 4kb

[fumeboy]

// goloader/ld.go
	for k, _func := range linker._func {
		funcname := getfuncname(_func, module)
		x := linker.symMap[funcname].Offset
		b := x / pcbucketsize
		i := x % pcbucketsize / (pcbucketsize / nsub)
		for lb := b - len(funcbucket); lb >= 0; lb-- {
			funcbucket = append(funcbucket, findfuncbucket{
				idx: uint32(k)}) // notice here (A)
		}
		if funcbucket[b].subbuckets[i] == 0 && b != 0 && i != 0 { // and here (B)
			if k-int(funcbucket[b].idx) >= pcbucketsize/minfunc {
				return fmt.Errorf("over %d func in one funcbuckets", k-int(funcbucket[b].idx))
			}
			funcbucket[b].subbuckets[i] = byte(k - int(funcbucket[b].idx))
		}
	}

the findfunctab has bigbucket and subbucket.

first, this program set the bigbucket.idx with value of k, but should be k==0 ? 0 : k-1,
suppose the address of a function (k-1) happens to be [4096-100, 4096 + 100], and now pc is 4096+50, this program will determine that this pc belongs to the k th function, not the k-1 th function

首先, 这个程序假设每个大桶的起始索引, 都是起始地址在这 4096byte 内的第一个函数的索引, 然而有可能一个函数的地址, 恰好“骑”在这 4KB 的分界线上, 它的起始地址在前一个大桶, 但是终结地址在第二个 4096byte, 这意味着属于第二个 4096byte 的 pc 值, 有可能是第 k-1 函数, 而不是第 k 函数; 这个很危险, 会导致程序 throw

second, this program set the subbucket.idx but ignore the empty subbucket between 2 set subbucket, and these empty subbucket should be fill by prev bucket with non-zero value

其次, 这个程序设置了小桶的值后, 忽略了中间空桶的填充, 不过这个是小问题, 只是 findfunc 有可能从 0 开始查找, 这不会导致程序 throw

[fumeboy]

cc @eh-steve

[pkujhd]

the wrong func id won't cause a crash . it gives generate-stack function wrong function name.
but still a case will be panic. when the last function cross 4k boundary, it will be visit out of bounds of pclntable.
i will fix it