-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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/asm: assembly language debugging with gdb broken in master tip #25191
Comments
Will look, I wonder if this has something to do with inlining changes because I made a point of (in theory) not modifying the assembly language pass. |
Change https://golang.org/cl/110816 mentions this issue: |
The assembler does not produce pcstmt symbols, writeline should be able to work even if no pcstmt symbol exists for a given function. Fixes #25216, #25191 Change-Id: I41e16df1e7c8ca59d27e7514537609e309a51c51 Reviewed-on: https://go-review.googlesource.com/110816 Reviewed-by: David Chase <drchase@google.com>
I have pulled the change https://golang.org/cl/110816, but I still can't make a breakpoint in an assembly file and see the assembly code. If I make the breakpoints like this: b math/big.addVV, then the program will paused at the entry of function big.addVV, however I can't see the code of addVV but the Go code of the caller of big.addVV. |
The bug is in link/internal/ld/dwarf.go, fixed here https://go-review.googlesource.com/c/go/+/102435/25/src/cmd/link/internal/ld/dwarf.go as part of a much larger CL. The code that thought it had to reset is_stmt to 1 after each function was wrong-headed, and thus would (I think, have not verified this exactly) disable the is_stmt flag for every second function in an asm file. |
This seems to be working now, so closing. Please comment if you disagree. |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?master tip
Does this issue reproduce with the latest release?
No -- I can debug assembly in 1.10.1 and earlier releases
What operating system and processor architecture are you using (
go env
)?Linux (Ubuntu 16.04)
What did you do?
Tried to debug assembly on both AMD64 and s390x
If possible, provide a recipe for reproducing the error.
cd /src/golang.org/x/crypto/curve25519
go test -c
gdb curve25519.test
break ladderstep_amd64.s:18
What did you expect to see?
break ladderstep_amd64.s:18
Breakpoint 1 at 0x4e6eaa: file
/src/golang.org/x/crypto/curve25519/ladderstep_amd64.s, line 18.
What did you see instead?
No source file named ladderstep_amd64.s
NOTES:
version of gdb:
gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
(on both s390x and AMD64)
I also couldn't step into an assembly function from a go language file. Again, this works fine on go1.10.1 and earlier releases.
The text was updated successfully, but these errors were encountered: