On Wed, Sep 9, 2020 at 1:45 PM 'Dan Kortschak' via golang-nuts
<[email protected]> wrote:
> I think it comes down to these lines in src/cmd/internal/sys/arch.go
> [1]
>
> ```
> var ArchARM = &Arch{
> Name: "arm",
> Family: ARM,
> ByteOrder: binary.LittleEndian,
> PtrSize: 4,
> RegSize: 4,
> MinLC: 4,
> }
>
> var ArchARM64 = &Arch{
> Name: "arm64",
> Family: ARM64,
> ByteOrder: binary.LittleEndian,
> PtrSize: 8,
> RegSize: 8,
> MinLC: 4,
> }
> ```
> this line in src/cmd/compile/internal/gc/main.go [2]
> ```
> Widthreg = thearch.LinkArch.RegSize
> ```
>
> and these lines in src/cmd/compile/internal/gc/align.go [3]
> ```
> case TINT64, TUINT64, TFLOAT64:
> w = 8
> t.Align = uint8(Widthreg)
> ```
>
> [1]https://golang.org/src/cmd/internal/sys/arch.go
> [2]https://golang.org/src/cmd/compile/internal/gc/main.go
> [3]https://golang.org/src/cmd/compile/internal/gc/align.go
Thank you very much for the thorough investigation.
If the intent is to have Go alignments/offsets of types compatible
with the C ABI then I think it's safe to say this is a bug.
And the existence of the syscall package, in some cases passing
Go-defined structs to the kernel that must be binary compatible with
their C definitions, IMO suggests that the intent is indeed there.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UFLsy0%3DSAWR3CM2YqVTWcEAgfQpkRaAn0LWkSQ%3DWeTcw%40mail.gmail.com.
