$ go version
go version go1.11.4 windows/amd64
go version go1.12beta2 windows/amd64
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set CGO_CFLAGS=-g -O2
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\florin\AppData\Local\Temp\go-build732947326=/tmp/go-build -gno-record-gcc-switches
run the application and make a request with curl -i http://localhost:8080/
run set returnStatus = 404 in delve then resume the application
What did you expect to see?
The debugger should be able to change the value of the function parameter before the call happens.
What did you see instead?
The debugger was unable to change the value and the old value was used.
My expectation is that if I compile the application using -gcflags="all=-N -l" such optimization is removed and I can do what I need to do with my program to debug it.
I also noticed that if I swap lines 22 and 23 and keep the breakpoint on line 22 then the result is the expected one. So the optimization applied here is not consistently applied either (should I open a separate bug for it?).
the instruction of interest is 0x75094b which sets one of the function arguments directly to the constant 0xc8 (200). The compiler noticed that the value of the variable is constant and optimized the read away.
The text was updated successfully, but these errors were encountered:
changed the title
cmd/compile: variable read should not be optimized hen using -gcflags="all=-N -l"Jan 29, 2019
This looks like it's a consequence of the fact that we haven't separated out required rewrites from optional rewrites in the opt passes. When I explicitly mark the opt and late opt compiler passes as not required, that fixes the problem.
There are only a few required rewrite rules; they shouldn't be hard to split out.
@randall77 I do have a question for you. Why is it that when swapping the lines 22 and 23 then this doesn't happen? And, perhaps the bigger question, why doesn't this optimization apply to line 23 in the original code as well? I would expect the behavior to be consistently applied for function calls, but it seems it's not? Is it related to the parameter type that the function expects?
Why is it that when swapping the lines 22 and 23 then this doesn't happen?
This is the difference between:
v := 5
v := 5
In the former, a simple rewrite rule can follow the flow of "5" to the argument slot of f. In the latter, it requires knowing that g does not modify v. That later knowledge is turned off with -N.
And, perhaps the bigger question, why doesn't this optimization apply to line 23 in the original code as well? I would expect the behavior to be consistently applied for function calls, but it seems it's not? Is it related to the parameter type that the function expects?
This is because Sprintf has a ... argument slot. With -N the backing array for the ... slice is always allocated on the heap, and the newobject call involved in that acts as the g above.
using go version go1.15.3 linux/amd64 this bug still exists and prevents assignments to variables in delve.
The thread above mentions "When I explicitly mark the opt and late opt compiler passes as not required, that fixes the problem."
What is the syntax to allow users to do that marking of compiler passes not required... until this bug is fixed?
The attached file reproduces the problem. rrm.go.txt