Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: debug_line can contain multiple entries for the same PC address in Go 1.15.4 #42484

Closed
aarzilli opened this issue Nov 10, 2020 · 14 comments
Closed
Labels
Milestone

Comments

@aarzilli
Copy link
Contributor

@aarzilli aarzilli commented Nov 10, 2020

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.main

decllinetest.go:7     0x9cda0                 f9400b81                MOVD 16(R28), R1                        
decllinetest.go:7     0x9cda4                 910003e2                MOVD RSP, R2                            
decllinetest.go:7     0x9cda8                 eb01005f                CMP R1, R2                              
decllinetest.go:7     0x9cdac                 540001e9                BLS 15(PC)                              
decllinetest.go:7     0x9cdb0                 f81d0ffe                MOVD.W R30, -48(RSP)                    
decllinetest.go:7     0x9cdb4                 f81f83fd                MOVD R29, -8(RSP)                       
decllinetest.go:7     0x9cdb8                 d10023fd                SUB $8, RSP, R29                        
decllinetest.go:8     0x9cdbc                 f90013ff                MOVD ZR, 32(RSP)                        
decllinetest.go:9     0x9cdc0                 b24003e0                ORR $1, ZR, R0                          
decllinetest.go:9     0x9cdc4                 f90013e0                MOVD R0, 32(RSP)                        
decllinetest.go:10    0x9cdc8                 f9000fff                MOVD ZR, 24(RSP)                        
decllinetest.go:11    0x9cdcc                 f94013e0                MOVD 32(RSP), R0                        
decllinetest.go:11    0x9cdd0                 f90007e0                MOVD R0, 8(RSP)                         
decllinetest.go:11    0x9cdd4                 f9000bff                MOVD ZR, 16(RSP)                        
decllinetest.go:11    0x9cdd8                 9400000a                CALL main.f1(SB)                        
decllinetest.go:12    0x9cddc                 f85f83fd                LDUR -8(RSP), R29                       
decllinetest.go:12    0x9cde0                 f84307fe                MOVD.P 48(RSP), R30                     
decllinetest.go:12    0x9cde4                 d65f03c0                RET                                     
decllinetest.go:7     0x9cde8                 aa1e03e3                MOVD R30, R3                            
decllinetest.go:7     0x9cdec                 97ff321d                CALL runtime.morestack_noctxt(SB)       
decllinetest.go:7     0x9cdf0                 17ffffec                JMP main.main(SB)                       
decllinetest.go:7     0x9cdf4                 00000000                ?                                       
decllinetest.go:7     0x9cdf8                 00000000                ?                                       
decllinetest.go:7     0x9cdfc                 00000000                ?                                       

With main.f1 following immediately after at 0x9ce00. Debug_line contains the following for address 0x9ce00:

[0x00026ce9]  Special opcode 120: advance Address by 12 to 0x9cde8 and Line by -4 to 7
[0x00026cea]  Special opcode 244: advance Address by 24 to 0x9ce00 and Line by 0 to 7
[0x00026ceb]  Extended opcode 1: End of Sequence

[0x00026cee]  Extended opcode 2: set Address to 0x9ce00
[0x00026cf9]  Set File Name to entry 2 in the File Name Table
[0x00026cfb]  Advance Line by 8 to 9
[0x00026cfd]  Special opcode 9: advance Address by 0 to 0x9ce00 and Line by 5 to 14

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

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Nov 10, 2020

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.

Loading

@aarzilli
Copy link
Contributor Author

@aarzilli aarzilli commented Nov 10, 2020

I haven't looked, I'll look tomorrow but I'd be surprised if it didn't.

Loading

@thanm
Copy link
Contributor

@thanm thanm commented Nov 10, 2020

I'll take a look.

Loading

@cagedmantis cagedmantis added this to the Backlog milestone Nov 10, 2020
@cherrymui cherrymui removed this from the Backlog milestone Nov 10, 2020
@cherrymui cherrymui added this to the Go1.15.5 milestone Nov 10, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 10, 2020

Change https://golang.org/cl/268937 mentions this issue: cmd/compile: do not emit an extra debug_line entry for the end of seq addr

Loading

@thanm
Copy link
Contributor

@thanm thanm commented Nov 11, 2020

@gopherbot please open a backport issue for 1.15.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 11, 2020

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.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 12, 2020

Change https://golang.org/cl/269517 mentions this issue: [release-branch.go1.15] cmd/compile: do not emit an extra debug_line entry for the end of seq addr

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 15, 2020

Change https://golang.org/cl/270197 mentions this issue: cmd/link: regression test for issue #42484

Loading

derekparker pushed a commit to go-delve/delve that referenced this issue Nov 16, 2020
gopherbot pushed a commit that referenced this issue Nov 23, 2020
…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
gopherbot pushed a commit that referenced this issue Mar 14, 2021
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>
@gopherbot
Copy link

@gopherbot gopherbot commented May 11, 2021

Change https://golang.org/cl/318850 mentions this issue: [dev.typeparams] all: merge master (9b84814) into dev.typeparams

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented May 11, 2021

Change https://golang.org/cl/318989 mentions this issue: [dev.fuzz] all: merge master (9b84814) into dev.fuzz

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented May 13, 2021

Change https://golang.org/cl/319749 mentions this issue: [dev.fuzz] all: merge master (2a61b3c) into dev.fuzz

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented May 13, 2021

Change https://golang.org/cl/319890 mentions this issue: [dev.fuzz] all: merge master (7a7624a) into dev.fuzz

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented May 14, 2021

Change https://golang.org/cl/320050 mentions this issue: [dev.fuzz] all: merge master (d137b74) into dev.fuzz

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 6, 2021

Change https://golang.org/cl/333013 mentions this issue: [dev.cmdgo] all: merge master (912f075) into dev.cmdgo

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants