-buildmode=shared features for 1.5 release

[Michael Hudson-Doyle]

Hi everyone,

Thanks for everyone for the reviews and comments on my shared library
CLs. There is now only one CL still in review for basic
-buildmode=shared/-linkshared functionality, which I think is pretty
amazing progress.

There are still a few obvious missing features and gaps that should be
taken care of before the 1.5 release and I just wanted to check that
my expectations line up with the wider group's.

These are the things I expect to work on and fix before release:

* Some version of the ABI checks described in the "go execution
modes" document. I have a draft CL at http://golang.org/cl/8773 that
basically works, but it needs some tidying and probably some
discussion here of how to define an ABI mismatch.
* Checking that all versions of the same package in the same process
are compiled from the same code, also from the execution modes
document, and testing that this situation actually works
* Fixing dwarf generation for linkshared (I'd like to talk to someone
who knows about dwarf for this)
* Adding some tests of -buildmode=shared
* Having the go tool rebuild stale shared libraries

Things I should probably do, but seem a bit lower in priority:

* Assess the performance impact of shared vs default and try to fix
any gross problems
* Support -buildmode=shared for gccgo

Things I am not intending to work on:

* Support for GOOS/GOARCH other than linux/amd64 (although I might
get to this, and would certainly hope to for 1.6)
* Internal linking for shared libraries
* -buildmode=plugin, or support for dlopen vs -buildmode=c-shared
* Enabling the race detector with -buildmode=shared

I'm open to input on this likely/probably not/unlikely categorization,
and super interested to hear about anything that I've missed. I have
a trello board with these things on at
https://trello.com/b/zsQx5BCY/go-shared-library-stuff, but be warned
that I just set this up for myself so card descriptions may not be
super comprehensible if you are not me.

Cheers,
mwh

[Ian Lance Taylor]

On Tue, Apr 21, 2015 at 6:04 PM, Michael Hudson-Doyle
<michael...@canonical.com> wrote:
>
> Thanks for everyone for the reviews and comments on my shared library
> CLs. There is now only one CL still in review for basic
> -buildmode=shared/-linkshared functionality, which I think is pretty
> amazing progress.

Thanks for working on it.

> There are still a few obvious missing features and gaps that should be
> taken care of before the 1.5 release and I just wanted to check that
> my expectations line up with the wider group's.
>
> These are the things I expect to work on and fix before release:
>
> * Some version of the ABI checks described in the "go execution
> modes" document. I have a draft CL at http://golang.org/cl/8773 that
> basically works, but it needs some tidying and probably some
> discussion here of how to define an ABI mismatch.
> * Checking that all versions of the same package in the same process
> are compiled from the same code, also from the execution modes
> document, and testing that this situation actually works
> * Fixing dwarf generation for linkshared (I'd like to talk to someone
> who knows about dwarf for this)
> * Adding some tests of -buildmode=shared
> * Having the go tool rebuild stale shared libraries

The code freeze starts in 10 days. I don't know if all of this is
going to get done. It would be great if it did, of course.

I think the highest priority should be some tests. They don't have to
be comprehensive or anything. And you don't have to work on
them--anybody want to volunteer to write a few?

In that list, I think DWARF generation is the lowest priority. It's
not like our DWARF generation is great anyhow, and somebody who needs
it can rebuild without shared libraries.

Ian

[jto...@gmail.com]

Things I am not intending to work on:

 * Support for GOOS/GOARCH other than linux/amd64 (although I might
get to this, and would certainly hope to for 1.6)

We're very interested in this (support for linux/arm) and would be willing to invest time/resources in such an effort. For initial planning purposes from someone more familiar than me, what's the rough scope of work here?

-JT

[Ian Lance Taylor]

Adding support for -buildmode=shared and -linkshared for linux/arm
should not require much in the way of actual coding. I would estimate
fewer than 100 lines of code would be required, scattered across the
toolchain. However, it requires a lot in terms of understanding. You
need to understand how ELF shared libraries work on ARM, how code
generation changes for shared libraries, what relocations they use,
and how those relocations are used. You need to implement any
required code generation changes in the ARM compiler and
assembler--there may not be any, I don't know. And you need to
generate any required relocations in the ARM linker.

I've never looked into ARM ELF details myself, so I can't be more
specific. Michael Hudson-Doyle might know more.

Ian

[Michael Hudson-Doyle]

I actually have code that implements this that I will be bashing into
shape and submitting for review soon. It's in this (absurdly named)
branch: https://github.com/mwhudson/go/tree/dismember-R_ADDRARM64
along with lots of other stuff.

It is implemented along the lines proposed in
https://go-review.googlesource.com/#/c/13170/ so any thoughts people
have on that would be appreciated :-)

Cheers,
mwh

[JT Olds]

Great! Fantastic to hear. We'll take a look and let you know if we have any thoughts. In the mean time, are there any discrete work units that might be helpful for us to try and grab?

[Michael Hudson-Doyle]

Testing and thoughts on code structure would definitely be great.
Also, and this is much more involved, thoughts on the code being
generated would be great. I have the feeling there is quite a lot of
low hanging fruit in ARM code generation (in the default case, never
mind for PIC) but I'm not really an expert on it.

Cheers,
mwh

[Vincent Batts]

Is there a tracker for shared object support on linux/386?

vb

> --
> You received this message because you are subscribed to the Google Groups "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Ian Lance Taylor]

On Wed, Aug 26, 2015 at 7:50 AM, Vincent Batts <vba...@gmail.com> wrote:
> Is there a tracker for shared object support on linux/386?

Not that I know of. Go ahead and open one if you like.

Ian

[Vincent Batts]

done. https://github.com/golang/go/issues/12346

thanks.
vb