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. |
cagedmantis
added
the
WaitingForInfo
|
I'll take a look. |
cagedmantis
added
NeedsInvestigation
|
Change https://golang.org/cl/268937 mentions this issue: |
thanm
added
NeedsFix
|
@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
Adds test to check that the compiler does not emit duplicate debug_line entries for the end of sequence address. Updates #42484 Change-Id: I3c5d1d606fcfd758aa1fd83ecc51d8edc054398b Reviewed-on: https://go-review.googlesource.com/c/go/+/270197 TryBot-Result: Go Bot <gobot@golang.org> Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com> Trust: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Than McIntosh <thanm@google.com>
|
Change https://golang.org/cl/318850 mentions this issue: |
|
Change https://golang.org/cl/318989 mentions this issue: |
|
Change https://golang.org/cl/319749 mentions this issue: |
|
Change https://golang.org/cl/319890 mentions this issue: |
|
Change https://golang.org/cl/320050 mentions this issue: |
|
Change https://golang.org/cl/333013 mentions this issue: |
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: