Join GitHub today
cmd/compile: increased line number churn #20367
This problem has always existed with the SSA backend and my impression is that it got better during go1.9 development windows, however a recent commit, 00263a8, while trying to improve the situation actually made some things worse (although I'm sure it did actually improve numbering in other circumstances). For example in this program the function main.helloworld went from compiling (with -gcflags='-N -l') to:
To compiling to:
Note the line number of the LEA at 0x481b5f, there multiple examples of this happening in delve's test set.
Working on it, the problem comes from a poor combination of positioning "SB" (and "SP" and initial memory) and not positioning the LEAQ itself, which causes it to inherit the predecessor (SB) line number.
Minimal fix is to use src.NoXPos entryNewValue0, was wondering if it might not make more sense to use that for all the entryNewValueX generators. The reason for doing the larger-scope "fix" is that each of the entryNewValueX calls will stuff a "random" line number into the values in the entry Block (i.e., nonsensical for debugging), though the values so stuffed are all of the sort that get sunk down closer to their uses, which may or may not match their definitions.
It certainly makes sense to use src.NoXPos for things like OpSP.
It would be nice if the LEAQ had the line number of the return instruction, not the func declaration.