On Tue, Aug 11, 2020 at 8:12 AM <evan.mesterh...@gmail.com> wrote: > > I am attempting to build a simple hello-world go program for a custom > operating system that provides compatibility with a subset of Linux syscalls > through the INT 0x80 syscall inferface. > > My understanding is that go uses the Linux vDSO for time functions, but that > otherwise it uses INT 0x80 for syscalls. What I am not 100% sure of is > whether go automatically uses INT 0x80 on i386 if the kernel does not provide > a pointer to the vDSO in the aux vector. I found this issue on the tracker, > but it addresses amd64 instead of i386.
The same thing happens on 386 GNU/Linux. If the VDSO is not found at program startup time, because there is no AT_SYSINFO_EHDR aux value, then the runtime will fall back to using int 0x80. > 1. Is it possible to completely disable use of the vDSO for i386/Linux > programs? If so, is this done at build time, or automatically by the go > runtime? There is no way to disable use of the VDSO if it is present on the system. > Secondly, I need to use a custom linking script to build my program so that > it can be loaded into the user address space designated by the OS. I tried > doing this with the following command, but this seems to have linked my > hello-world program with glibc code and introduced gratuitous usage of the > vDSO via CALL *%gs:0x10. > > > CGO_ENABLED=0 GOARCH=386 go tool link -v -linkmode external -extldflags > "-static -Ti386.ld" hello.o This will link against libc, but I wouldn't expect it to actually use anything from libc. Where are the VDSO references coming from? > 2. Is it possible to feed a linker script into the default go linker similar > to gcc's "-T" option? No. You can use the -T option to set the text segment address, but there is no support for general linker scripts. > 3. Is it possible to link go programs using gcc without also linking in glibc > code? The command above generates the host link command below, which seems to > link lpthread. I don't think so, at least not easily. Once you invoke the external linker, it's going to expect to use the glibc startup code. > One idea I had for this is to use the gccgo front end to compile the program > under the assumption that I will be able to have more control over the linker > flags since the assembler will output a standard object file instead of go's > proprietary format. Is there merit to this approach? Yes, that is likely true. > I am also curious why lpthread is linked at all when using -linkmode > external. I thought that the go runtime provided its own threading > implementation, making lpthread unnecessary. It's also unclear to my why > glibc code would be linked in considering that CGO_ENABLED=0 is set. Am I > misunderstanding what the linker is doing here? The external linker normally expects that you are using cgo. When using cgo, threads are created using pthread_create. Only when not using cgo, and not using glibc, does the Go runtime use the clone system call directly. Ian -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX%3DOTp%3D2DJK2jZJL37YCZSzUZ55wW-6Zn3Q1GE_Vgteyw%40mail.gmail.com.
