go.arm64
go.arm64 copied to clipboard
4ad
liblink: code doesn't have frame pointers
Because of the lack of frame pointers we can't have stack traces in mdb.
It's very easy to produce stack traces without frame pointers, even without frame-size information, Plan 9 does it, after all. But this is all too complicated for gdb.
We need to add frame pointers. They will not be used by anything, generated code won't refer to them, they will only be used for stack walking.
Instead of wasting a register, why not add pc/frame tables to the data space if they can't go in the executable? Would that not work?
On 5 February 2015 at 11:22, Aram Hăvărneanu [email protected] wrote:
Because of the lack of frame pointers we can't have stack traces in mdb.
It's very easy to produce stack traces without frame pointers, even without frame-size information, Plan 9 does it, after all. But this is all too complicated for gdb.
We need to add frame pointers. They will not be used to anything, so generated code won't refer t them, they will always be used for stack walking.
— Reply to this email directly or view it on GitHub https://github.com/4ad/go/issues/101.
There already are pc/frame tables, but gdb doesn't know how to read them. I'm told you can do some DWARF magic to teach gdb to use them, but I have no idea how that works, sounds complicated.
Alternatively, we can write a python script that uses the Plan 9 algorithm to generate stack traces. Unfortunately, I don't know python, and interfacing with gdb through python sounds complicated too.
Or, we can just port acid to unix, but then we have to deal with ptrace and write more of the arm64 libmach.
On 5 February 2015 at 11:29, Aram Hăvărneanu [email protected] wrote:
I'm told you can do some DWARF magic to teach gdb to use them, but I have no idea how that works, sounds complicated.
I meant just putting them in a section in RAM, similar to the function names and line tables that I think Go includes. What do the other go ports do about gdb?
Oh, it doesn't work well on any platforms. I think it works worse on platforms with a link register though. It's not too important on other platforms because there you have a stable runtime, which needs to be debugged less, and you have working panic(), which is implemented in Go and knows how to walk its own stacks. But we're not there yet.
On 5 February 2015 at 12:28, Aram Hăvărneanu [email protected] wrote:
. It's not too important on other platforms because there you have a stable runtime, which needs to be debugged less,
Is this mainly in aid of debugging the run-time, then?
Not only for debugging of the runtime, the iOS 64-bit ABI requires x29 must always address a valid frame record so that stack traces will always be meaningful, even without debug information.
see https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
