Re: [go-nuts] Running golang C-shared library in an OS that uses cooperative scheduling.
On Wed, Sep 9, 2020 at 7:39 PM Yonatan Gizachew wrote: > > This might be trivial, but could you explain me the relationship between the > following? > 1. value returned by __tls_get_addr This is the address of the TLS control block. The exact definition depends on the architecture. All TLS variables are at some offset from this value. > 2. runtime.g A TLS variable that holds the current goroutine, a pointer to a g struct. > 3. runtime.g0 A global variable that holds the g struct used for the initial goroutine. > 4. runtime.m0 A global variable that holds the m struct used for the initial thread. > 5. runtime.m gccgo no longer uses this. In earlier releases it was a TLS variable that holds the current thread, a pointer to an m struct. In current releases gccgo uses g->m for this. 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/CAOyqgcXZPrfi1i1vR_bYCkrSOkUd9NWp2YoCQMrBF-0Zj%3DDazQ%40mail.gmail.com.
Re: [go-nuts] Running golang C-shared library in an OS that uses cooperative scheduling.
This might be trivial, but could you explain me the relationship between the following? 1. value returned by __tls_get_addr 2. runtime.g 3. runtime.g0 4. runtime.mo 5. runtime.m Thanks:) On Thursday, September 10, 2020 at 11:31:21 AM UTC+9 Ian Lance Taylor wrote: > On Wed, Sep 9, 2020 at 7:26 PM Yonatan Gizachew wrote: > > > > Is there any known problems that could appear when we run golang > C-shared libraries in an OS that uses a non-preemptive scheduling > mechanism. I am experiencing some problems related to TLS (more > specifically runtime.m0 and runtime.g0). > > FYI - the C-shared library was built suing the gccgo compiler as: > > go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go > > Note that runtime.m0 and runtime.g0 are not themselves TLS variables. > runtime.g is a TLS variable. > > As gccgo has not been tested on your platform, any number of problems > are possible. How does your OS handle scheduling non-preemptively? > Only schedule on system calls? I think that could work with typical > Go programs, although it could longer GC pauses with gccgo. > > 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/d17f2ac0-d311-4eb1-b301-2d92fd6a4140n%40googlegroups.com.
Re: [go-nuts] Running golang C-shared library in an OS that uses cooperative scheduling.
I see. Thanks for the explanation. It basically use function interposition to redirect Pthreads function calls made from golang to Pth. In that case a thread runs until it reaches a pth yield instruction, which transfers control to the scheduler and activates another available thread. On Thursday, September 10, 2020 at 11:31:21 AM UTC+9 Ian Lance Taylor wrote: > On Wed, Sep 9, 2020 at 7:26 PM Yonatan Gizachew wrote: > > > > Is there any known problems that could appear when we run golang > C-shared libraries in an OS that uses a non-preemptive scheduling > mechanism. I am experiencing some problems related to TLS (more > specifically runtime.m0 and runtime.g0). > > FYI - the C-shared library was built suing the gccgo compiler as: > > go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go > > Note that runtime.m0 and runtime.g0 are not themselves TLS variables. > runtime.g is a TLS variable. > > As gccgo has not been tested on your platform, any number of problems > are possible. How does your OS handle scheduling non-preemptively? > Only schedule on system calls? I think that could work with typical > Go programs, although it could longer GC pauses with gccgo. > > 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/02b65d23-4a5b-4282-8d12-566ef90b5363n%40googlegroups.com.
Re: [go-nuts] Running golang C-shared library in an OS that uses cooperative scheduling.
On Wed, Sep 9, 2020 at 7:26 PM Yonatan Gizachew wrote: > > Is there any known problems that could appear when we run golang C-shared > libraries in an OS that uses a non-preemptive scheduling mechanism. I am > experiencing some problems related to TLS (more specifically runtime.m0 and > runtime.g0). > FYI - the C-shared library was built suing the gccgo compiler as: > go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go Note that runtime.m0 and runtime.g0 are not themselves TLS variables. runtime.g is a TLS variable. As gccgo has not been tested on your platform, any number of problems are possible. How does your OS handle scheduling non-preemptively? Only schedule on system calls? I think that could work with typical Go programs, although it could longer GC pauses with gccgo. 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/CAOyqgcVO01_SaUxG9GZettfYNcqBxiey-B7Fjo9JTk7KeD7%2Bqg%40mail.gmail.com.
[go-nuts] Running golang C-shared library in an OS that uses cooperative scheduling.
Is there any known problems that could appear when we run golang C-shared libraries in an OS that uses a non-preemptive scheduling mechanism. I am experiencing some problems related to TLS (more specifically runtime.m0 and runtime.g0). FYI - the C-shared library was built suing the gccgo compiler as: go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go -- 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/ac19eb39-4290-4909-ac37-c6db2f4243bdn%40googlegroups.com.
[go-nuts] Go 1.15.2 and Go 1.14.9 are released
Hello gophers, We have just released Go versions 1.15.2 and 1.14.9, minor point releases. View the release notes for more information: https://golang.org/doc/devel/release.html#go1.15.minor You can download binary and source distributions from the Go web site: https://golang.org/dl/ To compile from source using a Git clone, update to the release with "git checkout go1.15.2" and build as usual. Thanks to everyone who contributed to the releases. Cheers, Dmitri and Alex for the Go team -- 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/CA%2BON-PGaP5Q_LsdRsHANqQaFFPYF1-Cjv5NYqAptMq4Vvvsd3Q%40mail.gmail.com.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, Sep 9, 2020 at 8:17 PM Ian Lance Taylor wrote: > Exact alignment/offset compatibility with the C ABI is not a goal. > Sorry. (It's actually harder than one might think to maintain that > kind of compatibility. For example, on x86, the C ABI uses one > alignment for double variables and a different alignment for double > variables that appear as a field in a struct. Unless, of course, you > use the -malign-double option. And more generally some platforms have > multiple C ABIs, including x86 if you count the MCU psABI.) > > The Go structs in the syscall package that need to match C structs are > carefully written to work correctly. > > You may find the cgo -godefs option to be helpful, as it provides Go > structs that exactly match C structs, given a particular set of > compiler options. Thanks a lot for the clarification. Assuming that IIRC, cgo -godefs acquire the alignment/offset info by invoking the C compiler, it's unfortunately not a good option for a project that aims to avoid CGo in the first place. But I now think there's a feasible solution to this problem, having not as high a cost as I feared first when reading your answer. I shall see tomorrow. Thanks again. -- 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/CAA40n-Vq1d2mFwmb4FVjuAdmCfa%3Du%2BoNBqEoGmY%2B_ba2j5WBWw%40mail.gmail.com.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, Sep 9, 2020 at 4:59 AM Jan Mercl <0xj...@gmail.com> wrote: > > If the intent is to have Go alignments/offsets of types compatible > with the C ABI then I think it's safe to say this is a bug. > > And the existence of the syscall package, in some cases passing > Go-defined structs to the kernel that must be binary compatible with > their C definitions, IMO suggests that the intent is indeed there. Exact alignment/offset compatibility with the C ABI is not a goal. Sorry. (It's actually harder than one might think to maintain that kind of compatibility. For example, on x86, the C ABI uses one alignment for double variables and a different alignment for double variables that appear as a field in a struct. Unless, of course, you use the -malign-double option. And more generally some platforms have multiple C ABIs, including x86 if you count the MCU psABI.) The Go structs in the syscall package that need to match C structs are carefully written to work correctly. You may find the cgo -godefs option to be helpful, as it provides Go structs that exactly match C structs, given a particular set of compiler options. 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/CAOyqgcW%2ByA%2BzE4afZ81GJHCXm%3De9tfz-8gD99EQiEe%2Bk7xOKRw%40mail.gmail.com.
Re: [go-nuts] [ generics ] Added constraint type inference to the design draft
On Tue, Sep 8, 2020 at 9:25 PM Ian Lance Taylor wrote:
>
> I think that it's really crucial for type inference rules to be as simple
> and clear as possible. There must never be any confusion as to what an
> inferred type might be. In complicated cases, it's fine to explicitly list
> the type arguments. In fact, it's more than fine: it's desirable.
>
This doesn't seem to be a complicated case. We just have a type parameter
that needs pointer methods in order to be passed to another function. I
wouldn't suggest making the inference rules more clever to compensate for
this case. As I mentioned, the compiler probably shouldn't be smart enough
to figure this out as written.
I think the difficulty is coming from conflicting requirements. For element
type inference, you want the freedom to be able to provide arbitrary named
composite types as arguments and get the element type based on structural
matching. But for derived type constraints, you really actually don't want
that extra degree of freedom in the identity of the composite type.
Instead, you want to constrain the specific derived type. Maybe it would be
better to allow derived types to be constrained directly:
https://go2goplay.golang.org/p/cLVkk4HGWre
type Constraint interface{
Method()
}
func Foo[T any, *T Constraint](_ T) {}
func Bar[T any, *T Constraint](t T) {
Foo(t)
}
It might seem weird to have a "parameter" which has to be a specific type
in relation to other parameters, but that's already what was happening with
constraint type inference. This is sort of similar to the original idea of
having pointer type constraints, except you need both T and *T as
parameters, with each being constrained separately.
This doesn't cover the use case of accepting named slice types and
inferring the element type, so constraint type inference would still be
needed. Of course, part of what makes constraint type inference appealing
is that it gets two birds with one stone, but it seems like the conflicting
requirements of the two use cases is undermining the value of both.
On Tue, Sep 8, 2020 at 9:25 PM Ian Lance Taylor wrote:
> On Tue, Sep 8, 2020 at 5:47 PM Steven Blenkinsop
> wrote:
>
> >
>
> > Reading over the pointer method example, I noticed that a derived type
> cannot be inferred in a nested call while leaving method constraints intact:
>
> >
>
> > type DerivedTypeConstraint[T any] interface {
>
> > type *T
>
> > Method()
>
> > }
>
> >
>
> > func Foo[T any, PT DerivedTypeConstraint[T]](_ T) {}
>
> >
>
> > func Bar[T any, PT DerivedTypeConstraint[T]](t T) {
>
> > Foo(t) // Error: *T has no methods
>
> > }
>
> >
>
> > type S struct{}
>
> >
>
> > func (S) Method() {}
>
> >
>
> > func main() {
>
> > Bar(S{}) // This is fine, PT gets inferred as *S, which implements Method
>
> > }
>
> >
>
> >
>
> > https://go2goplay.golang.org/p/9GMdhTbcMDs
>
> >
>
> > Obviously, you can work around this by passing PT explicitly rather than
> letting *T be inferred. It's just unfortunate that, even though *T must
> have any methods in the constraint on PT (any other type with the same
> underlying type would have no methods), the compiler isn't, and most likely
> shouldn't be, smart enough to figure that out. I'm not sure how to solve
> this, but I think it makes the design feel a little less polished.
>
>
>
> I think that it's really crucial for type inference rules to be as
>
> simple and clear as possible. There must never be any confusion as to
>
> what an inferred type might be. In complicated cases, it's fine to
>
> explicitly list the type arguments. In fact, it's more than fine:
>
> it's desirable.
>
>
>
> 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/CANjmGJuAZv7AJ-mrBAmOENYj%3Dtn0NmmMtDPmY%2B_BeOuZEO1ACQ%40mail.gmail.com.
Re: [go-nuts] Is there any lib like CMSSignedData in GOLANG?
Can you share the code or any info for decryption with pkcs7? On Wednesday, June 8, 2016 at 7:51:40 AM UTC+7 18126...@163.com wrote: > It's great. > > In fact , I have found some code using pkcs7 to decode, and it works very > well now. > > Thank you very much. > > 在 2016年6月8日星期三 UTC+8上午1:59:10，Konstantin Khomoutov写道： > >> On Tue, 7 Jun 2016 01:21:26 -0700 (PDT) >> 18126...@163.com wrote: >> >> > I don't know the server how to encrypt and signed data, but i have >> > the CMSSignedData class in Java to decode data, the CMSSignedData >> > class is from org.bouncycastle.cms.*, it's contained in the jar >> > "bcpkix-jdk15on-1.52.jar". >> > Is there similar lib in GOLANG, then i can use it to decode the >> > server data easily. >> >> Out of curiosity, I have googled for you, and judging from [1], >> [2] might be a way to go. >> >> 1. >> https://www.bouncycastle.org/docs/pkixdocs1.4/org/bouncycastle/cms/CMSSignedData.html >> >> 2. https://godoc.org/github.com/fullsailor/pkcs7 >> > -- 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/97a53860-5580-4b8f-a12f-120e8882fd6fn%40googlegroups.com.
[go-nuts] "go run" vs. "go install" and $GOPATH
Hi, On my system "go run" creates ~/go and places pkg there, even though $GOPATH is set. Whereas "go install" places pkg under $GOPATH. Ideally, I would like ~/go to never be created. $ ls ~/go ls: /Users/foo/go: No such file or directory $ echo $GOPATH /Users/foo/Google Drive/programming/golang/workspace $ pwd /Users/foo/Google Drive/programming/golang/workspace/github.com/foo/project $ go mod init github.com/foo/project go: creating new go.mod: module github.com/foo/project $ go install go: finding module for package github.com/google/gopacket go: finding module for package github.com/google/gopacket/pcap go: finding module for package github.com/google/gopacket/layers go: downloading github.com/google/gopacket v1.1.18 go: found github.com/google/gopacket in github.com/google/gopacket v1.1.18 go: found github.com/google/gopacket/layers in github.com/google/gopacket v1.1.18 go: found github.com/google/gopacket/pcap in github.com/google/gopacket v1.1.18 $ project [...] $ ls ~/go ls: /Users/foo/go: No such file or directory $ go run ./main.go go: downloading github.com/google/gopacket v1.1.18 [...] $ ls ~/go pkg Thank you for any help you can provide! -- 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/85d5a52a-1b4e-49bf-83df-2332a80079f9n%40googlegroups.com.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, Sep 9, 2020 at 1:45 PM 'Dan Kortschak' via golang-nuts
wrote:
> I think it comes down to these lines in src/cmd/internal/sys/arch.go
> [1]
>
> ```
> var ArchARM = {
> Name: "arm",
> Family:ARM,
> ByteOrder: binary.LittleEndian,
> PtrSize: 4,
> RegSize: 4,
> MinLC: 4,
> }
>
> var ArchARM64 = {
> Name: "arm64",
> Family:ARM64,
> ByteOrder: binary.LittleEndian,
> PtrSize: 8,
> RegSize: 8,
> MinLC: 4,
> }
> ```
> this line in src/cmd/compile/internal/gc/main.go [2]
> ```
> Widthreg = thearch.LinkArch.RegSize
> ```
>
> and these lines in src/cmd/compile/internal/gc/align.go [3]
> ```
> case TINT64, TUINT64, TFLOAT64:
> w = 8
> t.Align = uint8(Widthreg)
> ```
>
> [1]https://golang.org/src/cmd/internal/sys/arch.go
> [2]https://golang.org/src/cmd/compile/internal/gc/main.go
> [3]https://golang.org/src/cmd/compile/internal/gc/align.go
Thank you very much for the thorough investigation.
If the intent is to have Go alignments/offsets of types compatible
with the C ABI then I think it's safe to say this is a bug.
And the existence of the syscall package, in some cases passing
Go-defined structs to the kernel that must be binary compatible with
their C definitions, IMO suggests that the intent is indeed there.
--
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/CAA40n-UFLsy0%3DSAWR3CM2YqVTWcEAgfQpkRaAn0LWkSQ%3DWeTcw%40mail.gmail.com.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, 2020-09-09 at 13:21 +0200, Jan Mercl wrote:
>
>
> On Wed, Sep 9, 2020 at 1:09 PM 'Dan Kortschak' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> > What does cgo -godefs give you? On my amd64 and arm64 I get this:
> >
> > ```
> > ~/cznic $ cat main.go
> > package main
> >
> > /*
> > struct s {
> > long long i;
> > } x;
> > */
> > import "C"
> >
> > type S struct {
> > i int64
> > }
> >
> > type C_s C.struct_s
> >
> > ~/cznic $ go tool cgo -godefs main.go
> > // Code generated by cmd/cgo -godefs; DO NOT EDIT.
> > // cgo -godefs main.go
> >
> > package main
> >
> > type S struct {
> > i int64
> > }
> >
> > type C_s struct {
> > I int64
> > }
> > ```
>
> amd64
> =
>
>
> jnml@e5-1650:~/tmp$ go version
> go version go1.15.1 linux/amd64
> jnml@e5-1650:~/tmp$ cat main.go
> package main
>
> /*
> struct s {
> long long i;
> } x;
> */
> import "C"
>
> type S struct {
> i int64
> }
>
> type C_s C.struct_s
> jnml@e5-1650:~/tmp$ go tool cgo -godefs main.go
> // Code generated by cmd/cgo -godefs; DO NOT EDIT.
> // cgo -godefs main.go
>
> package main
>
> type S struct {
> i int64
> }
>
> type C_s struct {
> I int64
> }
> jnml@e5-1650:~/tmp$
>
> arm
> =
> ==
>
> pi@raspberrypi:~/src/tmp.tmp $ go version
> go version go1.15.1 linux/arm
> pi@raspberrypi:~/src/tmp.tmp $ cat main.go
> package main
>
> /*
> struct s {
> long long i;
> } x;
> */
> import "C"
>
> type S struct {
> i int64
> }
>
> type C_s C.struct_s
> pi@raspberrypi:~/src/tmp.tmp $ go tool cgo -godefs main.go
> // Code generated by cmd/cgo -godefs; DO NOT EDIT.
> // cgo -godefs main.go
>
> package main
>
> type S struct {
> i int64
> }
>
> type C_s struct {
> I int64
> }
> pi@raspberrypi:~/src/tmp.tmp $
>
> No difference between the outputs AFAICT. Seems good to me.
>
>
I think it comes down to these lines in src/cmd/internal/sys/arch.go
[1]
```
var ArchARM = {
Name: "arm",
Family:ARM,
ByteOrder: binary.LittleEndian,
PtrSize: 4,
RegSize: 4,
MinLC: 4,
}
var ArchARM64 = {
Name: "arm64",
Family:ARM64,
ByteOrder: binary.LittleEndian,
PtrSize: 8,
RegSize: 8,
MinLC: 4,
}
```
this line in src/cmd/compile/internal/gc/main.go [2]
```
Widthreg = thearch.LinkArch.RegSize
```
and these lines in src/cmd/compile/internal/gc/align.go [3]
```
case TINT64, TUINT64, TFLOAT64:
w = 8
t.Align = uint8(Widthreg)
```
[1]https://golang.org/src/cmd/internal/sys/arch.go
[2]https://golang.org/src/cmd/compile/internal/gc/main.go
[3]https://golang.org/src/cmd/compile/internal/gc/align.go
--
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/9faee5b3868886c3c7415ecc1c2469f2e008abe2.camel%40kortschak.io.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, Sep 9, 2020 at 1:09 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> What does cgo -godefs give you? On my amd64 and arm64 I get this:
>
> ```
> ~/cznic $ cat main.go
> package main
>
> /*
> struct s {
> long long i;
> } x;
> */
> import "C"
>
> type S struct {
> i int64
> }
>
> type C_s C.struct_s
>
> ~/cznic $ go tool cgo -godefs main.go
> // Code generated by cmd/cgo -godefs; DO NOT EDIT.
> // cgo -godefs main.go
>
> package main
>
> type S struct {
> i int64
> }
>
> type C_s struct {
> I int64
> }
> ```
amd64
=
jnml@e5-1650:~/tmp$ go version
go version go1.15.1 linux/amd64
jnml@e5-1650:~/tmp$ cat main.go
package main
/*
struct s {
long long i;
} x;
*/
import "C"
type S struct {
i int64
}
type C_s C.struct_s
jnml@e5-1650:~/tmp$ go tool cgo -godefs main.go
// Code generated by cmd/cgo -godefs; DO NOT EDIT.
// cgo -godefs main.go
package main
type S struct {
i int64
}
type C_s struct {
I int64
}
jnml@e5-1650:~/tmp$
arm
===
pi@raspberrypi:~/src/tmp.tmp $ go version
go version go1.15.1 linux/arm
pi@raspberrypi:~/src/tmp.tmp $ cat main.go
package main
/*
struct s {
long long i;
} x;
*/
import "C"
type S struct {
i int64
}
type C_s C.struct_s
pi@raspberrypi:~/src/tmp.tmp $ go tool cgo -godefs main.go
// Code generated by cmd/cgo -godefs; DO NOT EDIT.
// cgo -godefs main.go
package main
type S struct {
i int64
}
type C_s struct {
I int64
}
pi@raspberrypi:~/src/tmp.tmp $
No difference between the outputs AFAICT. Seems good to me.
--
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/CAA40n-Xj22QAWdU-CjxibUhBEwxChm-HOORUUxbpfG2ihY0Sjg%40mail.gmail.com.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, 2020-09-09 at 12:50 +0200, Jan Mercl wrote:
> On Wed, Sep 9, 2020 at 12:41 PM Dan Kortschak
> wrote:
>
> > I get the following
> >
> > ```
> > C alignof struct s: 8
> > Go alignof struct s: 8
> > Go alignofS: 8
> > ~/cznic $ go version
> > go version go1.15.1 linux/arm64
> > ~/cznic $ uname -a
> > Linux bildr 4.19.0-10-arm64 #1 SMP Debian 4.19.132-1 (2020-07-24)
> > aarch64 GNU/Linux
> > ```
> >
> > I have an arm64 linux running on my pi, maybe the armv7l behaviour
> > is
> > different.
>
> Seems to be the case as armv7l is AFAIK a 32 bit only CPU. And arm64
> is next on the list of my targets so thank you for the information.
>
> But the question is still the same. Is it a bug or is my assumption
> about Go and C agreeing on alignments/offsets invalid? I realizethe
> specs say nothing in this regard.
What does cgo -godefs give you? On my amd64 and arm64 I get this:
```
~/cznic $ cat main.go
package main
/*
struct s {
long long i;
} x;
*/
import "C"
type S struct {
i int64
}
type C_s C.struct_s
~/cznic $ go tool cgo -godefs main.go
// Code generated by cmd/cgo -godefs; DO NOT EDIT.
// cgo -godefs main.go
package main
type S struct {
i int64
}
type C_s struct {
I int64
}
```
--
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/bf4ba2bfde7a4a0c2d858e5ae1af8c118694b541.camel%40kortschak.io.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, Sep 9, 2020 at 12:41 PM Dan Kortschak wrote: > I get the following > > ``` > C alignof struct s: 8 > Go alignof struct s: 8 > Go alignofS: 8 > ~/cznic $ go version > go version go1.15.1 linux/arm64 > ~/cznic $ uname -a > Linux bildr 4.19.0-10-arm64 #1 SMP Debian 4.19.132-1 (2020-07-24) > aarch64 GNU/Linux > ``` > > I have an arm64 linux running on my pi, maybe the armv7l behaviour is > different. Seems to be the case as armv7l is AFAIK a 32 bit only CPU. And arm64 is next on the list of my targets so thank you for the information. But the question is still the same. Is it a bug or is my assumption about Go and C agreeing on alignments/offsets invalid? I realizethe specs say nothing in this regard. -- 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/CAA40n-XvvraqMF_5boDqFo%3DSVLdTo79bX-AJyAfQBJxVu1Tx4A%40mail.gmail.com.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, 2020-09-09 at 12:19 +0200, Jan Mercl wrote:
> Observation:
>
> pi@raspberrypi:~/src/tmp.tmp $ go version
> go version go1.15.1 linux/arm
> pi@raspberrypi:~/src/tmp.tmp $ cat main.go
> package main
>
> /*
>
> struct s {
> long long i;
> } x;
>
> size_t align() {
> return _Alignof(struct s);
> }
>
> */
> import "C"
>
> import (
> "fmt"
> "unsafe"
> )
>
> type S struct {
> i int64
> }
>
> func main() {
> fmt.Printf(" C alignof struct s: %v\n", C.align())
> fmt.Printf("Go alignof struct s: %v\n",
> unsafe.Alignof(C.struct_s{}))
> fmt.Printf("Go alignofS: %v\n", unsafe.Alignof(S{}))
> }
> pi@raspberrypi:~/src/tmp.tmp $ go run main.go
> C alignof struct s: 8
> Go alignof struct s: 4
> Go alignofS: 4
> pi@raspberrypi:~/src/tmp.tmp $ uname -a
> Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019
> armv7l GNU/Linux
> pi@raspberrypi:~/src/tmp.tmp $
>
> My code relies on all the numbers being the same, ie. that Go will
> report the same as C for both C.struct_s{} and S{}.
> AFAICT Go and C agree on struct layout on linux/{amd64,386} perfectly
> in all cases I've tested (thousands probably).
>
> Is this a bug or are my expectations ill founded?
>
> Thanks in advance for any insights.
>
I get the following
```
C alignof struct s: 8
Go alignof struct s: 8
Go alignofS: 8
~/cznic $ go version
go version go1.15.1 linux/arm64
~/cznic $ uname -a
Linux bildr 4.19.0-10-arm64 #1 SMP Debian 4.19.132-1 (2020-07-24)
aarch64 GNU/Linux
```
I have an arm64 linux running on my pi, maybe the armv7l behaviour is
different.
Dan
--
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/da8da3f14f311a23ab0191d7e8ba130a068c73b8.camel%40kortschak.io.
[go-nuts] linux/arm struct alignment seems wrong
Observation:
pi@raspberrypi:~/src/tmp.tmp $ go version
go version go1.15.1 linux/arm
pi@raspberrypi:~/src/tmp.tmp $ cat main.go
package main
/*
struct s {
long long i;
} x;
size_t align() {
return _Alignof(struct s);
}
*/
import "C"
import (
"fmt"
"unsafe"
)
type S struct {
i int64
}
func main() {
fmt.Printf(" C alignof struct s: %v\n", C.align())
fmt.Printf("Go alignof struct s: %v\n",
unsafe.Alignof(C.struct_s{}))
fmt.Printf("Go alignofS: %v\n", unsafe.Alignof(S{}))
}
pi@raspberrypi:~/src/tmp.tmp $ go run main.go
C alignof struct s: 8
Go alignof struct s: 4
Go alignofS: 4
pi@raspberrypi:~/src/tmp.tmp $ uname -a
Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l
GNU/Linux
pi@raspberrypi:~/src/tmp.tmp $
My code relies on all the numbers being the same, ie. that Go will report
the same as C for both C.struct_s{} and S{}.
AFAICT Go and C agree on struct layout on linux/{amd64,386} perfectly in
all cases I've tested (thousands probably).
Is this a bug or are my expectations ill founded?
Thanks in advance for any insights.
--
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/CAA40n-Vdqc6QLzsYWgmzCRMvChiLbP1geLTWLpqF8Pw-ygqrAA%40mail.gmail.com.
Re: [go-nuts] Re: why the binary generated by go test has no symbol table
it seems ldfags="-s=false" -gcflags="-l" can work 在2020年9月9日星期三 UTC+8 上午10:09:18 写道： > On Tue, Sep 8, 2020 at 7:04 PM buaa...@gmail.com > wrote: > > > > I wrote a tool to get binary file's symbol table during initialization, > and do some special tests, but it fails on Linux, so I get the log like: > > > > $ go test > > 2020/09/09 10:02:44 reading /tmp/go-build334351549/b001/xxx.test: no > symbol section > > 2020/09/09 10:02:44 reading /tmp/go-build334351549/b001/xxx.test: no > symbols > > One approach you can use is to have the test build a program using "go > build". > > Or you can run your tests using "go test -c". > > Ian > > > > 在2020年9月9日星期三 UTC+8 上午6:01:18 写道： > >> > >> On Mon, Sep 7, 2020 at 7:07 PM buaa...@gmail.com > wrote: > >> > > >> > There is no ldflags provided, so why the symbol table is stripped > >> > >> Because if you run "go test" without the -c option, the executable is > >> built, run, and then thrown away. There no reason to spend time > >> generating debugging information that nobody will ever use. > >> > >> Which leads to the question: how did you notice? What is the real > problem here? > >> > >> Ian > >> > >> > >> > 在2020年9月8日星期二 UTC+8 上午10:05:33 写道： > >> >> > >> >> And only on Linux, there is no symbol section in test binary unless > I generate it by go test -c > >> > > >> > -- > >> > 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...@googlegroups.com. > >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/d8840e17-63c6-4f32-af1d-5d73d12dfbd4n%40googlegroups.com > . > > > > -- > > 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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/93fd8c75-6e2d-4449-8912-a86fc70dee06n%40googlegroups.com > . > -- 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/98f81f44-d49e-45d7-af74-816330991a50n%40googlegroups.com.
[go-nuts] Re: Why does race detector only throw out warning rather than fatal error?
See "halt_on_error" https://golang.org/doc/articles/race_detector.html#Options Le mardi 8 septembre 2020 à 14:47:11 UTC+2, chole...@gmail.com a écrit : > Code with data races is invalid code, we shouldn't let it run once we find > a data race. Actually, since Go 1.5, when runtime finds concurrent read and > write to a map, it does throw a fatal error rather than just warning. Maybe > it's not consistent that race detector only print out warning message. -- 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/055c7885-db90-4729-84ac-8c6e6a2aabc1n%40googlegroups.com.
