Date: Sat, 24 May 2014 10:41:01 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Peter Jeremy <peter@rulingia.com> Cc: freebsd-amd64@freebsd.org Subject: Re: i386 Go programs crash on amd64 Message-ID: <20140524074101.GI74331@kib.kiev.ua> In-Reply-To: <20140524033944.GA96083@server.rulingia.com> References: <20140523225300.GA14433@server.rulingia.com> <537FD853.3000505@wemm.org> <537FD9A2.2010607@wemm.org> <20140523233444.GH74331@kib.kiev.ua> <20140524033944.GA96083@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Xdd9Z8fLQ2awL3hZ
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, May 24, 2014 at 01:39:44PM +1000, Peter Jeremy wrote:
> On 2014-May-24 02:34:44 +0300, Konstantin Belousov <kostikbel@gmail.com> =
wrote:
> >On Fri, May 23, 2014 at 04:28:34PM -0700, Peter Wemm wrote:
> >> On 5/23/14, 4:22 PM, Peter Wemm wrote:
> >> > On 5/23/14, 3:53 PM, Peter Jeremy wrote:
> >> >> I've been playing with Go (lang/go) and found that i386 Go binaries
> >> >> segfault when run on amd64 (9.x, 10.x or HEAD). I've narrowed it d=
own
> >> >> to the LDT handling but am not sure whether it's on the FreeBSD or =
Go
> >> >> side.
> >> >>
> >> >> As far as I can see, the i386 binary is correctly calling i386_set_=
ldt()
> >> >> and the i386_set_ldt() emulation in the amd64 kernel matches the i3=
86
> >> >> kernel - but the net result doesn't work.
> >> >>
> >> >> Can anyone offer any suggestions as to how to resolve this?
> >Provide the minimal test case.
>=20
> The following go program, compiled on i386 and run on amd64 will die
> with a segmentation violation or bus error:
> -------
> package main
>=20
> import "fmt"
>=20
> func main() {
> fmt.Println("Hello World")
> }
> -------
No, this is not consumable.
I need a self-contained minimal example written in C/asm.
If this is too hard to produce, give the the self-contained
binary, again as small as possible (small by comparing the
number of syscalls before the issue manifests itself).
As the absolute minimum I could start with the output on ctty
with machdep.uprintf_signal=3D1, but it is only for beginning.
>=20
> >> >>
> >> > We don't emulate i386_set_ldt().
> >> >
> >> > The 32 bit version of libc on amd64 has a different implementation=
=20
> >> > that calls sysarch(I386_SET_FSBASE, ..) and friends. Normally this =
is=20
> >> > handled transparently by static linking, but obviously that's an iss=
ue=20
> >> > for Go.
> >>=20
> >> Actually, that's an even more interesting question. WHY are they using=
=20
> >> i386_set_ldt()? Where is it coming from? As near as I can tell, libc,=
=20
> >> libthr etc call I386_SET_GSBASE for tls.
>=20
> As installed, the code is in /usr/local/go/src/pkg/runtime/sys_freebsd_38=
6.s
> "runtime=9Esetldt", which calls "runtime=9Ei386_set_ldt" which uses "int =
128".
>=20
> >We do support ldt for 32bit binaries on amd64.
>=20
> I thought it was supported.
>=20
> --=20
> Peter Jeremy
--Xdd9Z8fLQ2awL3hZ
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQIcBAEBAgAGBQJTgE0NAAoJEJDCuSvBvK1BR5oQAIWy6L9Iiy6u2yypGIaZy9rs
y0p4vgbnCvdEJ4t+J87R2EltywRTkgxvkmNDjwzW+mTpdGNnruHxi9ZDHCltYDe0
OsnKnxVDIsFfGXicszc2fCpcBJ+Ga8XJBBr0/cyodOIKdoffPn8+cYG4h5qZTCF/
z7JGMcxOcspCTSZVwC8rB78PoT1NaUh7DiCYg8QsVWMyxEMACR1g4MeeghT1L84Z
GEjMgmATRrbIK3p+OufGAKjysIuaroneJGqy5noWo2OA5MD6rw0ISCcwimDAGU7/
CvairxUsTQHo66rKorJ+FPw9lLOGPuv6P9Cm3cUuHKqjeXIM19S1E8xAWTpZ4Z+F
8PACveSXREA0WOPi4TIvTqX8X93x0uSlFDjSWG3KOPfQgMvbvgMl6g2yMOy7cgxr
VnyZmjJA3BtYxh2/125vIJrcOHBdM3IlI05YEY24rVoy0cp7RkSrl/KUFKb16sLP
XPjEJimW+fIwMrwNdfJ/x77T51Y8kb4OniDRwEVQse9ex7IC1d4TnLu0k2PXfov4
rR02vEr9Vtg0dRT5bcKfVEO83GJ5TSlCc1i40WdXcKI0c/YBz4gdBgx0zqcaS3Pv
1eF+Ady0/x/LQ+zj5kLmeGjqGCP/DQg4RaWgMtYbJnS3O5DEkvctvLFm/J1CzOS7
87AtDROdmBx4qTGtSFR6
=FDOV
-----END PGP SIGNATURE-----
--Xdd9Z8fLQ2awL3hZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140524074101.GI74331>