Go on Solaris 10 amd64

[Alan Mock]

I am planning port Go to Solaris. I saw that there was some
discussion about this in November but it didn't provide a resolution
and I don't see a Solaris port in the code so I'm wondering if anyone
is currently working on this or not. If not, I plan to start on this
in January. If someone is working on it I'd be interested in
providing help if help is desired.

[Minhao.Dong]

Sorry for late reply. I did try to port go to solaris on x86. I can make
the compiler work. but the compiler is not give me the correct binary file.

In the first place, the binary file could not found TLS support, and I
fixed it by add a DT_NEEDED entry with libc.so.1 in dynamic section.

But then I got signal fault when I execute binary file, and I could not
found the way to fix it.

[khush...@gmail.com]

Ah progress on a port to Sol?

[Aram Hăvărneanu]

Dave Cheney, Minux and myself are working on it. I've taken a break in
the last month or so, but I plan to resume work as soon as I can.

--
Aram Hăvărneanu

[Aram Hăvărneanu]

> Dave Cheney, Minux and myself are working on it. I've taken a break in
> the last month or so, but I plan to resume work as soon as I can.

You can take a look or help here: https://bitbucket.org/4ad/go-sunos

--
Aram Hăvărneanu

[Aram Hăvărneanu]

Currently it links a go_bootstrap binary that segfaults. Work has been
done so programs compiled with the Plan 9 C compilers work. The
current focus is making use of libc instead of making system calls
directly.

Thanks for your interest.

--
Aram Hăvărneanu

[Aram Hăvărneanu]

There's an alt runtime inside src/pkg/runtime which has a Plan 9
mkfile that demonstrates this. You need Plan 9 mk if you want to do
any work, but if you don't have it you can read the mkfile to see how
it's done.

You can get mk from plan9port, Inferno, and perhaps other sources.

--
Aram Hăvărneanu

[Khushil Dep]

Does it build as yet on sunos? I'll take a look at getting involved where I can once I work out where it's at.

---

W. A. Khushil Dep - khush...@gmail.com -  07905 374 843

High Performance Web Platforms Architect & Engineer

@khushil

[Khushil Dep]

Where could I being to understand the process of getting the Plan 9 compiler output to work?

---

W. A. Khushil Dep - khush...@gmail.com -  07905 374 843

High Performance Web Platforms Architect & Engineer

@khushil

[drago....@gmail.com]

Hello,
I compiled Go master branch on a Ubuntu amd64 machine from the here:
https://code.google.com/p/go
Made a simple Hello World application in Go.
Cross-Compiled this application a.go with:
GOOS=solaris GOARCH=amd64 GOPATH=~/go-src/go ~/go-src/go/bin/go build

Copied the resulting executable to Solaris 10u10, but it fails with:
ld.so.1: a: fatal: relocation error: file /a: symbol sem_reltimedwait_np: referenced symbol not found
Killed

ldd a
libc.so => /lib/64/libc.so
libm.so.2 => /lib/64/libm.so.2

file a
a: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped

From that patch I see that this function needs librt.so, but it is not linked to that executable.
https://bitbucket.org/4ad/go-sunos/commits/a349a071c0484b9b86d142a4116a71f44c8b7388

Any ideas, that can help me with the port? I am willing to read about ELF file format, etc., but need some initial directions.

Thanks

[Aram Hăvărneanu]

+CC iant, minux

> From that patch I see that this function needs librt.so, but it is not
> linked to that executable.
> https://bitbucket.org/4ad/go-sunos/commits/a349a071c0484b9b86d142a4116a71f44c8b7388
>
> Any ideas, that can help me with the port? I am willing to read about ELF
> file format, etc., but need some initial directions.

The problem is that in Solaris 11 and illumos some functions were
moved from libraries like librt.so and libpthread.so to libc.so. The
previous libraries became what are known as "filter libraries", they
use libc.so and provide a view of the symbols that's compatible with
the previous code that was there. Code that used to link with these
should continue to work in Solaris 11.

I don't know why code produced by the Go linker breaks this
assumption. In particular, if you link with libfoo.so on Solaris 10,
you get the correct symbol address when you reference it, but on
Solaris 11 you'll only get a NULL value. We are probably doing
something wrong. I don't know what yet, so I can't offer much advice.
Perhaps we use a relocation type that is not supported when using
filter libraries. That seems unlikely. I don't know what's wrong, I
haven't studied in detail how filter libraries work.

For this reason, we always link with libc.so at the expense of Solaris
10 support.

Perhaps Ian or Minux know more about this.

--
Aram Hăvărneanu

[Dragomir Ivanov]

Current Golang mainline uses forkx() system call. This call is not present in Solaris 10. Since Is there any particular reason for using this system call, and can I replace it with plain fork(), and siggetmask()/sigsetmask() blocking SIGCHLD signal in the parent process?

Thanks,

Dragomir

[minux]

On Thu, May 8, 2014 at 7:31 AM, Aram Hăvărneanu <ara...@mgk.ro> wrote:

+CC iant, minux

> From that patch I see that this function needs librt.so, but it is not
> linked to that executable.
> https://bitbucket.org/4ad/go-sunos/commits/a349a071c0484b9b86d142a4116a71f44c8b7388
>
> Any ideas, that can help me with the port? I am willing to read about ELF
> file format, etc., but need some initial directions.

The problem is that in Solaris 11 and illumos some functions were
moved from libraries like librt.so and libpthread.so to libc.so. The
previous libraries became what are known as "filter libraries", they
use libc.so and provide a view of the symbols that's compatible with
the previous code that was there. Code that used to link with these
should continue to work in Solaris 11.

I don't know why code produced by the Go linker breaks this
assumption. In particular, if you link with libfoo.so on Solaris 10,
you get the correct symbol address when you reference it, but on
Solaris 11 you'll only get a NULL value. We are probably doing

Is there any Solaris 10 machine available that I could take a look at this problem?

[Aram Hăvărneanu]

> Current Golang mainline uses forkx() system call. This call is not present
> in Solaris 10. Since Is there any particular reason for using this system
> call, and can I replace it with plain fork(), and siggetmask()/sigsetmask()
> blocking SIGCHLD signal in the parent process?

Sure, but all the other problems still remain.

--
Aram Hăvărneanu

[Aram Hăvărneanu]

> Is there any Solaris 10 machine available that I could take a look at this
> problem?

I don't have any Solaris 10 machine any more, but the problem actually
happens on Solaris 11. On Solaris 10 libthread.so and librt.so are
regular libraries, on Solaris 11 they are filter libraries.

--
Aram Hăvărneanu

[Aram Hăvărneanu]

Sorry, I meant now there's no reason not to use fork. Forkx was first
used because that code was written in a time where signal functions
didn't work yet.

Sorry for the confusion.

--
Aram Hăvărneanu

[Dragomir Ivanov]

Yes, I want first want to have running go programs on Solaris10, then I will think how can modified code be integrated into the mainline.

Thanks, I will try that and will post results here.

[Aram Hăvărneanu]

> Is there any Solaris 10 machine available that I could take a look at this
> problem?

If you are interested in this, you can download Solaris 10 from here:
http://www.oracle.com/technetwork/server-storage/solaris10/downloads/index.html

--
Aram Hăvărneanu

[Dragomir Ivanov]

Hello,

I am trying to add:
#pragma dynimport libc·sigprocmask sigprocmask "libc.so" 
from pkg/runtime/os_solaris.c
to pkg/runtime/syscall_solaris.goc

and using #pragma dynimport libc·close close "libc.so" as a template to do that, but this library function is defined by two different ways in the both files:

in pkg/runtime/os_solaris.c as:

#pragma dynimport libc·close close "libc.so"
extern uintptr libc·close;
int32
runtime·close(int32 fd)
{
        return runtime·sysvicall6(libc·close, 1, (uintptr)fd);
}

and in pkg/runtime/syscall_solaris.goc as:
#pragma dynimport libc·close close "libc.so"
extern uintptr libc·close;
#pragma textflag NOSPLIT
func close(fd uintptr) (err uintptr) {
        LibCall c;

        c.fn = (void*)libc·close;
        c.n = 1;
        c.args = (void*)&fd;
        runtime·asmcgocall(runtime·asmsysvicall6, &c);
        err = c.err;
}

Any ideas why is that? Thanks.

[Aram Hăvărneanu]

I am not sure what you are asking, so I will try to answer what I
think you might be asking. Goc files are pre-processed by a tool[1],
the output is just C. Write the function definition as if it were Go
(with some caveats), but the body as if it were C (with other
caveats).

Now, what are you actually asking. If you're curious about goc2c, see [1].

If you are curious why there are two close functions, please note that
the latter is part of the syscall package namespace (althogh it's
physically located in the runtime directory). This allows the Go code
in the syscall package to actually call it without other hacks.

If you're curious why the body of the function is different, there are
a few distinct reasons. Because of goc2c's operation, the .goc variant
needs to end with err = <something>; so this automatically makes them
different.

That's not the main reason however. .goc functions use stack-memory to
pass context to runtime·asmcgocall. You will see that
runtime·sysvicall6 doesn't use stack memory, it use memory from the
per-thread m struct (this is fine because a system call is tied to a
m). The reason for that is that there's usually not enough stack; all
these functions are NOSPLIT, so you have 120 bytes of stack (in
reality these all run on g0 stack, so it's plenty of stack, but the
linker doesn't know about this, where we can't cheap our way we use an
assembly function that lies by managing its own stack pointer).

Did I answer your question?

[1] https://code.google.com/p/go/source/browse/src/cmd/dist/goc2c.c

--
Aram Hăvărneanu

[c0ps...@gmail.com]

Wondering if you got anywhere with this?
Noob trying to run make.bash, using (what appears to be) preferred bootstrap on Solaris.

I'm heading toward cross-compiling toolchain, before attempting to build apps on Sol10u11, Sol11.3.

What I'm reading here, however, is that each of those two mentioned os' will require two separate binaries.
PLEASE correct me if I'm wrong -- however, I no doubt will find out soon enough.

Thanks!

[Aram Hăvărneanu]

What's the question?

Go works on Solaris 11 and later only (including illumos). It does not
work on Solaris 10 and likely never will because Solaris 10 lacks
event ports.

--
Aram Hăvărneanu

[mi*ke]

Ok, thanks for the clarification. 
That's what I needed.

--

__ MIke Nichols __
email:c0ps...@gmail.com
xmpp:mi...@myownsoho.net
sms:0xcf42a64d
pgp:4096R/7EF5C63700A0F93C

<img src="https://www.eff.org/files/2014/11/17/eff-badge-rec-2015.png" alt="EFF Member" />