cmd/link: debug_line can contain multiple entries for the same PC address in Go 1.15.4 #42484
Comments
Does this happen on tip? CL 258422 is a backport of a CL on tip. So if that CL is causing problem, it probably also causes problem on tip. Thanks. |
I haven't looked, I'll look tomorrow but I'd be surprised if it didn't. |
I'll take a look. |
Change https://golang.org/cl/268937 mentions this issue: |
@gopherbot please open a backport issue for 1.15. |
Backport issue(s) opened: #42521 (for 1.15). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
Change https://golang.org/cl/269517 mentions this issue: |
Change https://golang.org/cl/270197 mentions this issue: |
…entry for the end of seq addr Uses DW_LNS_advance_pc directly, instead of calling putpclcdelta because the latter will create a new debug_line entry for the end of sequence address. Updates #42484. Fixes #42521. Change-Id: Ib6355605cac101b9bf37a3b4961ab0cee678a839 Reviewed-on: https://go-review.googlesource.com/c/go/+/268937 Trust: Than McIntosh <thanm@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/269517
This is caused by https://go-review.googlesource.com/c/go/+/258422, commit 8f14c18.
If the body of a function immediately follows the body of another function then the PC address of the second function will have two entries in debug_line, one with the file:line of the first line of the first function and the second with the first line of the second function.
For example, compiling https://raw.githubusercontent.com/go-delve/delve/master/_fixtures/decllinetest.go on linux/arm64 (this is important) with
-gcflags='-N -l'
will produce the following code for main.mainWith main.f1 following immediately after at 0x9ce00. Debug_line contains the following for address 0x9ce00:
Address 0x9cee is marked both as decllinetest.go:7 (first line of main.main) at 0x00026cea and then as decllinetest.go:14 (first line of main.f1) by 0x00026cfd.
This is a problem for Delve because it will pick the first entry in debug_line which in this case sytematically leads to a mistake. I tried changing it to always select the last entry for a given PC address but that causes problems with Go 1.14 which emitted multiple entries for each address but with the first one being the right one. I could change it to first look for the start of a sequence that matches the function entry point but that wouldn't work with older versions of Go that do not emit a sequence for each function.
The linker-side fix would be to not use putpclcdelta at the end of generateDebugLinesSymbol and instead issue a DW_LNS_const_add_pc followed by a DW_LNS_advance_line manually.
cc @thanm
The text was updated successfully, but these errors were encountered: