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

Jump to bottom

runtime,cmd/compile,cmd/internal/obj/ppc64: set up stack on ppc64/ppc64le to more closely match the PPC64 ABI #46850

Open
laboger opened this issue Jun 21, 2021 · 1 comment
Open

runtime,cmd/compile,cmd/internal/obj/ppc64: set up stack on ppc64/ppc64le to more closely match the PPC64 ABI #46850

laboger opened this issue Jun 21, 2021 · 1 comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@laboger
Copy link
Contributor

laboger commented Jun 21, 2021

Some tools on Power are broken because the stack created by Go does not match the PPC64 ABI, In particular the backchain is expected to be at offset 0 of the stack and the link register value should be at offset 16 of the caller's stack.

One example is when using the backtrace function in glibc which expects the backchain at offset 0. That is the issue here: #46374

Others have reported problems with perf when mixing Go and C.

There are other advantages to doing this -- this should eliminate some code to move fields around when calling between C and Go and should simplify the race code to name a few.

I have tried some experiments with this and am able to generate the prolog and epilog to do this but have hit other issues and I am working my way through them.

@pmur
@cherrymui
Copy link
Member

Changing the frame layout will complicates the compiler and runtime. Currently for all LR architectures we have pretty much the same frame layout (modulo frame pointer & fixed frame size). If we change that there will be more special cases.

Also, changing the frame layout will break existing assembly code. Or do you want to change only ABIInternal functions' frame layout but leave ABI0 ones as before? That might work, but I think it will make the stack unwinder quite complicated. And it may not help tools as long as there is an old-style ABI0 frame on the stack.

I'm not sure we want to do that.

Is it possible for the tools to read e.g. debug info instead of using fixed offsets?

@cherrymui cherrymui added this to the Unplanned milestone Jun 21, 2021
@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 21, 2021
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@toothrot @gopherbot @laboger @cherrymui