liblink: code doesn't have frame pointers
4ad opened this issue · 8 comments
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 notifications@github.com
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 notifications@github.com
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 notifications@github.com
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?
Yes.
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.