You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
1.8
What operating system and processor architecture are you using (go env)?
darwin/amd64
What did you do?
This is extracted from a larger debugging problem to be self-contained, so it does not run.
When debugging, it can happen that when you set a breakpoint on a line, you'll actually end up stopping "somewhere else" because value unspills are tagged with the source line of the value, but may be located far from the rest of the code for that line.
It might make more sense to give these regalloc-inserted instructions the same line numbers as their predecessors or some other sort of "not really that line" annotation.
The text was updated successfully, but these errors were encountered:
Restores could be given the line of the value the restore is triggered for.
Restores during edge processing are a special case, not sure what their line should be.
josharian
changed the title
Line numbers attached to value spill/unspills (StoreReg/LoadReg/Copy) put line numbers in funny places
cmd/compile: line numbers attached to value spill/unspills (StoreReg/LoadReg/Copy) put line numbers in funny places
Feb 2, 2017
I'm trying both copying the preceding line and src.NoXPos, and both seem to give a decent gdb debugging experience. They may mean the same thing; there's no difference in the line number table sizes.
The test for #18902 reads the assembly stream to be sure
that the line number does not change too often (this is an
indication that debugging the code will be unpleasant and
that the compiler is probably getting line numbers "wrong").
It checks that it is getting "enough" input, but the
compiler has gotten enough better since the test was written
that it now fails for lack of enough input. The old
threshould was 200 instructions, the new one is 150 (the
minimum observed input is on arm64 with 184 instructions).
Fixes#22494.
Change-Id: Ibba7e9ff4ab6a7be369e5dd5859d150b7db94653
Reviewed-on: https://go-review.googlesource.com/74357
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?1.8
What operating system and processor architecture are you using (
go env
)?darwin/amd64
What did you do?
This is extracted from a larger debugging problem to be self-contained, so it does not run.
When debugging, it can happen that when you set a breakpoint on a line, you'll actually end up stopping "somewhere else" because value unspills are tagged with the source line of the value, but may be located far from the rest of the code for that line.
https://play.golang.org/p/nyZdpigPAa
This can be seen in the assembly language output, either from
go build -gcflags -S baddwarf.go
:or (and this helps with spotting the cause)
GOSSAFUNC='(*gcSortBuf).flush' go build baddwarf.go
:which can be seen to come from v175, v180, v61,v242,v214
It might make more sense to give these regalloc-inserted instructions the same line numbers as their predecessors or some other sort of "not really that line" annotation.
The text was updated successfully, but these errors were encountered: