gccgo vs latest go.crypto

[Albert Strasheim]

Hello all

With the latest addition to go.crytpo, gccgo can no longer build it:

http://code.google.com/p/go/source/detail?r=83d3a9be6c0e8de01619d01b48a5d4b0b1760a3c&repo=crypto# 

# code.google.com/p/go.crypto/curve25519

src/code.google.com/p/go.crypto/curve25519/const_amd64.s: Assembler messages:

src/code.google.com/p/go.crypto/curve25519/const_amd64.s:8: Error: no such instruction: `data ·REDMASK51(SB)/8,$0x0007FFFFFFFFFFFF'

src/code.google.com/p/go.crypto/curve25519/const_amd64.s:9: Error: no such instruction: `globl ·REDMASK51(SB),$8'

src/code.google.com/p/go.crypto/curve25519/const_amd64.s:11: Error: no such instruction: `data ·_121666_213(SB)/8,$996687872'

src/code.google.com/p/go.crypto/curve25519/const_amd64.s:12: Error: no such instruction: `globl ·_121666_213(SB),$8'

src/code.google.com/p/go.crypto/curve25519/const_amd64.s:14: Error: no such instruction: `data ·_2P0(SB)/8,$0xFFFFFFFFFFFDA'

src/code.google.com/p/go.crypto/curve25519/const_amd64.s:15: Error: no such instruction: `globl ·_2P0(SB),$8'

src/code.google.com/p/go.crypto/curve25519/const_amd64.s:17: Error: no such instruction: `data ·_2P1234(SB)/8,$0xFFFFFFFFFFFFE'

src/code.google.com/p/go.crypto/curve25519/const_amd64.s:18: Error: no such instruction: `globl ·_2P1234(SB),$8'

How is it supposed to work in this case?

Regards

Albert

[Adam Langley]

On Fri, Mar 16, 2012 at 5:54 AM, Albert Strasheim <ful...@gmail.com> wrote:
> With the latest addition to go.crytpo, gccgo can no longer build it:

That package uses the _amd64 in the filenames to exclude other
platforms from building the amd64 specific asm. Maybe the .s files
also need a // +build comment to exclude gccgo? The // +build comment
in the generic code would then need to express gccgo || !amd64. I have
seen documentation on the // +build comments in the past, but I can't
find it now.

Cheers

AGL

[Ian Lance Taylor]

Albert Strasheim <ful...@gmail.com> writes:

Gccgo will either have to use the generic Go implementation or somebody
will have to translate the assembly code to work with /usr/bin/as.

Ian

[Albert Strasheim]

Hello

On Friday, March 16, 2012 4:32:22 PM UTC+2, Ian Lance Taylor wrote:

Albert Strasheim writes:

> With the latest addition to go.crytpo, gccgo can no longer build it:

> How is it supposed to work in this case? 

Gccgo will either have to use the generic Go implementation or somebody
will have to translate the assembly code to work with /usr/bin/as.

So I guess this is at least a "go build" bug, in that it should have used the generic code? And maybe go.crypto needs some +build flags to enable that.

I made a note of this issue and the problem with compiling the latest goprotobuf in this issue:

http://code.google.com/p/go/issues/detail?id=3246 

By the way, I've been looking at using the new AES-NI instructions to speed up crypto/aes. The Java folks have some impressive results:

http://blog.fuseyism.com/index.php/2012/03/13/openjdk-icedtea-nss-icedtea7-results/ 

This will mean more assembler that one probably doesn't want to maintain in two forms in two places. Any thoughts on where this is headed? Can object files produced by [568]a be linked into gccgo binaries?

Regards

Albert

[Adam Langley]

On Fri, Mar 16, 2012 at 7:52 AM, Albert Strasheim <ful...@gmail.com> wrote:
> By the way, I've been looking at using the new AES-NI instructions to speed
> up crypto/aes. The Java folks have some impressive results:

AES-NI would be very welcome. The only reason that we don't already
have it is that I don't have a machine that supports it :)

However, in that case the support doesn't cut along platform lines the
support should probably mirror the way that CRC32 support is done in
hash/crc32.

Cheers

AGL

[Russ Cox]

I don't know what our story is for separating out gcc assembly
from Go assembly. Right now package go/build really only
works with gccgo for pure Go packages. The assumptions
about .c and .s files are really only applicable to the gc compilers.
I do not think we can fix this before Go 1 - it is too big a change -
but it is something I'd like to fix after Go 1.

Russ

[Ian Lance Taylor]

Albert Strasheim <ful...@gmail.com> writes:

> Can object
> files produced by [568]a be linked into gccgo binaries?

I do not think that would be feasible.

Ian