https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #5 from Michael Karcher <gcc-bugzilla at mkarcher dot dialup.fu-berlin.de> --- The root issue now is that the ABI gcc implements on m68k is incompatible with the Go runtime shipped with gcc. The Go runtime uses the lowest two bits in the type information pointer as flags (called PRECISE and LOOP) and relies on the fact that the actual type information structure is aligned to a 32-bit boundary. The type descriptors are Go literals created by the Go frontend as standard Go structures. In the gcc backend for Go, the layout and alignment rules of Go structures match the rules for C structures (which is most likely necessary for interoperability). On m68k this means we get 16-bit alignment for historical reasons. The current interface between the go frontend and its backend has no interface to request stricter alignment, so the Go frontend is unable to ensure that type descriptors are aligned to 32-bit boundaries. A possible way of solving this would be to extend Backend::struct_type(vector<...> fields) by an (optional?) second parameter to communicate alignment requests, such that Gcc_backend::struct_type can use DECL_ALIGN before calling fill_in_struct. This enables the Go frontend to request the required alignment for its type descriptors. Requesting increased alignment for Go type descriptors is impossible to break legacy ABIs on m68k as there is no ABI involving Go type descriptors yet. This change should possibly go align with adding "__attribute__((aligned(4)))" to several types in libgo/runtime/go-type.h if type descriptors are ever created from the C side of things. Proof for the issue: (sid-m68)root:~# nm --dynamic /usr/lib/m68k-linux-gnu/libgo.so.9 | grep __go_td | head -n 6 00bcc410 V __go_td_AAAN5_uint8ee1e 00bcc440 V __go_td_AAAN5_uint8ee1e$gc 00bd0058 V __go_td_AAAN5_uint8eee 00bd0080 V __go_td_AAAN5_uint8eee$gc 00bfc4e6 V __go_td_AAAN6_uint329e3e16e 00bfc5d2 V __go_td_AAAN6_uint329e3e16e$gc shows unaligned type descriptors.
