On 2014-May-24 02:34:44 +0300, Konstantin Belousov <[email protected]> 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 down >> >> 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 i386 >> >> kernel - but the net result doesn't work. >> >> >> >> Can anyone offer any suggestions as to how to resolve this? >Provide the minimal test case.
The following go program, compiled on i386 and run on amd64 will die
with a segmentation violation or bus error:
-------
package main
import "fmt"
func main() {
fmt.Println("Hello World")
}
-------
>> >>
>> > We don't emulate i386_set_ldt().
>> >
>> > The 32 bit version of libc on amd64 has a different implementation
>> > that calls sysarch(I386_SET_FSBASE, ..) and friends. Normally this is
>> > handled transparently by static linking, but obviously that's an issue
>> > for Go.
>>
>> Actually, that's an even more interesting question. WHY are they using
>> i386_set_ldt()? Where is it coming from? As near as I can tell, libc,
>> libthr etc call I386_SET_GSBASE for tls.
As installed, the code is in /usr/local/go/src/pkg/runtime/sys_freebsd_386.s
"runtime·setldt", which calls "runtime·i386_set_ldt" which uses "int 128".
>We do support ldt for 32bit binaries on amd64.
I thought it was supported.
--
Peter Jeremy
pgphxCH3P7xDq.pgp
Description: PGP signature
