-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
segfault in compiler on interface mismatch #80
Labels
Comments
Owner changed to r...@golang.org. Status changed to Started. |
This issue was closed by revision e5636d6. Status changed to Fixed. Merged into issue #-. |
Issue #122 has been merged into this issue. |
minux
pushed a commit
to minux/goios
that referenced
this issue
Feb 27, 2015
…m us The compilers don't behave properly and expect liblink to figure out a->name from an Addr with a->type=D_ADDR. In reality, a good citizen would set a->name=D_AUTO when it wants the effective address of an automatic. In fact, the compilers do this sometimes, but not always. It is too hard to fix the compilers, and we don't want to touch non-arm64 code anyway, so we do for arm64 what other liblinks do. Unfortunately, on arm64 this is complicated by the fact that ZR and SP are the same register (R31). Another idiosyncrasy of liblink is that it represents zero constants by setting a->reg=REGZERO, but that clashes with REGSP. Fortunately, a->reg is set only when a->offset is zero, and usually a->offset is non-zero when asking for effective stack address (it makes no sense to ask for a zero offset, since then you can just use the stack pointer itself with no constant), so we use a->offset as a distinguishing marker. In reality, there is no reason that $0 should use a different encoding than $42, because aclass only cares about a->offset when returning C_ZCON. If $0 would have a->reg=NREG (32), like other constants, then we could use a->reg itself to distinguish D_NONE from D_AUTO/D_PARAM. Unfortunately, the author's efforts to normalize the encoding of constants have failed. If we use NREG for $0, the code is missasembled in subtle ways. We abandon that effort for now, and we continue with this hack. Fixes golang#80
mwhudson
pushed a commit
to mwhudson/go
that referenced
this issue
May 22, 2015
Update golang#80 7g and 9g do not use componentgen and so fall back to the generic behaviour in sgen which is broken, golang#80. This PR reactivates parts of componentgen so sgen can use it for TINTER, which fixes golang#80 with respect to passing interface values to functions. All other fat types are still broken. Arguably we could reactivate the other parts of componentgen but that would be masking a latent issue in generic sgen. Anyway, this gets @mwhudson and I a little further, and I'll work on fixing sgen properly.
CL https://golang.org/cl/35073 mentions this issue. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by kirklin.mcdonald:
Attachments:
The text was updated successfully, but these errors were encountered: