[go-nuts] When net package is imported building binary with CGO generate error

2023-11-02 Thread sbezverk
 

 

Hello,

 

I came across a situation when “net” package is imported regardless directly or 
indirectly via another package, go build generates these errors:

 

/sw/packages/go/1.19.4/src/net/cgo_linux.go:20:59: could not determine kind of 
name for C.AI_ALL

/sw/packages/go/1.19.4/src/net/cgo_linux.go:20:43: could not determine kind of 
name for C.AI_V4MAPPED

 

I could not find any clues on the internet, curious if somebody saw similar 
issue and somehow has fixed it.

 

Thank you

Serguei

-- 
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/D1CE6CE9-41FC-4933-AF26-DA7F1D34EAEE%40gmail.com.


[go-nuts] Re: cgo.go: multiple definition of `c_test_func'

2023-10-05 Thread sbezverk
After looking in cgo generated files, I found that in fact function 
“c_test_func” is defined in 2 places.

 

1: ./cgo.cgo2.c:29: int c_test_func(int c1, int c2)

 

#line 3 "/nobackup/sbezverk/projects/go/worspace/cgo_test/cgo.go"

 #include 

 

 extern int go_test_func(int c1, int c2);

 

 int c_test_func(int c1, int c2)

 {

   return go_test_func(c1,c2);

 }

 

2: ./_cgo_export.h:27: int c_test_func(int c1, int c2)

 

#line 3 "cgo.go"

 #include 

 

 extern int go_test_func(int c1, int c2);

 

 int c_test_func(int c1, int c2)

 {

   return go_test_func(c1,c2);

 }

 

_cgo_export.h is included in  ./_cgo_export.c:4:#include "_cgo_export.h". 
Making it a second definition of the same function.

 

 

Is it a bug or what cgo.go does Go calling C func which in turn calls Go is not 
supported? 

 

Thank you

Serguei

 

From: sbezverk 
Date: Friday, 6 October 2023 at 00:13
To: 
Subject: cgo.go: multiple definition of `c_test_func'

 

Hello,

 

I struggle to understand why this simple cgo program does not get linked, I 
would provide example in playground, but it does not seem to support cgo.

 

 

```
package main

 

// #include 

//

// extern int go_test_func(int c1, int c2);

//

// int c_test_func(int c1, int c2)

// {

//   return go_test_func(c1,c2);

// }

import "C"

 

import (

  "fmt"

)

 

//export go_test_func

func go_test_func(c1, c2 C.int) C.int {

  return c1 + c2

}

 

func main() {

  fmt.Printf("Result: %d\n", C.c_test_func(2, 2))

}
```

 

I am getting:

 

# command-line-arguments

/sw/packages/xr/go/1.19.4/pkg/tool/linux_amd64/link: running gcc failed: exit 
status 1

/tmp/go-link-349950461/01.o: In function `c_test_func':

/nobackup/sbezverk/projects/go/worspace/cgo_test/cgo.go:9: multiple definition 
of `c_test_func'

/tmp/go-link-349950461/00.o:/tmp/go-build/cgo.go:9: first defined here

collect2: error: ld returned 1 exit status

 

 

Thank you

Serguei

-- 
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/46785834-2DF9-44BD-9508-043704C39DA7%40gmail.com.


[go-nuts] cgo.go: multiple definition of `c_test_func'

2023-10-05 Thread sbezverk
Hello,

 

I struggle to understand why this simple cgo program does not get linked, I 
would provide example in playground, but it does not seem to support cgo.

 

 

```
package main

 

// #include 

//

// extern int go_test_func(int c1, int c2);

//

// int c_test_func(int c1, int c2)

// {

//   return go_test_func(c1,c2);

// }

import "C"

 

import (

  "fmt"

)

 

//export go_test_func

func go_test_func(c1, c2 C.int) C.int {

  return c1 + c2

}

 

func main() {

  fmt.Printf("Result: %d\n", C.c_test_func(2, 2))

}
```

 

I am getting:

 

# command-line-arguments

/sw/packages/xr/go/1.19.4/pkg/tool/linux_amd64/link: running gcc failed: exit 
status 1

/tmp/go-link-349950461/01.o: In function `c_test_func':

/nobackup/sbezverk/projects/go/worspace/cgo_test/cgo.go:9: multiple definition 
of `c_test_func'

/tmp/go-link-349950461/00.o:/tmp/go-build/cgo.go:9: first defined here

collect2: error: ld returned 1 exit status

 

 

Thank you

Serguei

-- 
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/15C0C308-7287-4165-A328-8396B6E90F63%40gmail.com.


[go-nuts] Build test tag real life example

2023-10-04 Thread sbezverk
Hello,

 

I saw there was some debates about having “test build tag” here: 
https://github.com/golang/go/issues/21360  and people were asking about real 
life scenario. Here is one with CGO code, initially I was planning to add stubs 
for C land calls into blah_test.go file. (I do not need to test C land calls, I 
just need them to return 0) It turned  out, CGO is not supported in go unit 
tests. I had no other choice but to add these stubs into a normal go file, so 
unit test now is happy. It links locally defined stubs into a test binary. The 
problem now is with a production build where these stubs must be ignored and 
real C land calls from shared library should be invoked.  Having build test tag 
would be really useful, as I could exclude from the production build locally 
defined stubs and life is good.

 

The unit tests are for the library code, I do not know how to tell “go build -a 
./…” when building  the client of the library binary to exclude locally defined 
stubs file.

 

Greatly appreciate some ideas on how to solve it.

 

Thank you

Serguei

 

 

-- 
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/B8980E65-1B2F-47B6-8C6F-3F9113AEFF28%40gmail.com.


Re: [go-nuts] cgo and dynamic linking of shared labraries

2023-09-26 Thread sbezverk
Related question: is it possible to replace golang's "link" tool with "ld"? It 
looks like "ld" has greater flexibility to address my requirements.

Thank you in advance for your guidance.
Serguei

On 26/09/23, 12:32, "sbezverk" mailto:sbezv...@gmail.com>> wrote:


Thank you for your reply, I was under impression that prototype definitions 
come from C header files, and since the compilation phase completes with 
success, cgo finds all necessary function definitions. My problem is at the 
linking phase when the linker by some reason tries to resolve ALL functions 
from the shared library, even those which are not directly used/called in CGO 
code.
This causes CGO_LDFLAGS variable to be enormously long as I have to add around 
3k of libraries. Using LDFLAGS environment variable is no better, as after 
adding all libraries to make LD happy, it exceeds the size limit and pretty 
much kills bash.


I am starting to get this:


```
dev-1:/user/sbezverk/go_connect > ls
-bash: /bin/ls: Argument list too long
```


For every internal bash command I try to execute.


I was wondering if there is a keyword forcing the linker not to try to resolve 
everything when building a binary, but to let the dynamic linker to deal with 
it at the execution time.


Thank you
Serguei


On 26/09/23, 06:20, "Ian Lance Taylor" mailto:i...@golang.org> <mailto:i...@golang.org <mailto:i...@golang.org>>> 
wrote:




On Sat, Sep 23, 2023 at 6:38 AM sbezverk mailto:sbezv...@gmail.com> <mailto:sbezv...@gmail.com 
<mailto:sbezv...@gmail.com>>> wrote:
>
> Since I could not find the answer in the cgo documentation, I would really 
> appreciate if somebody could help me to understand why when I build cgo code 
> with calls to the shared library, the linker tries to find the shared library 
> even though it is instructed to build dynamic binary and not static.
>
>
>
> I have C built shared library, I have no control how it gets built, I only 
> have lib_blahblah_x64_86.so . There are 2 external functions 
> bind_wrapper/unbind_wrapper in that library which I call from cgo.
>
>
>
> Here is the command line I use to compile:
>
>
>
> CC=/bin/tools/llvm11/llvm-11.0-p25/bin/clang-11 go build -o go_connect 
> -linkshared -ldflags "-linkmode external -extldflags -dynamic" go_connect.go
>
>
>
> The compilation succeeds, but the linker is complaining:
>
>
>
> /tmp/go-link-2323626149/01.o: In function 
> `_cgo_df3b8c92b86e_Cfunc_bind_wrapper':
>
> /tmp/go-build/cgo-gcc-prolog:68: undefined reference to `bind_wrapper'
>
> /tmp/go-link-2323626149/01.o: In function 
> `_cgo_df3b8c92b86e_Cfunc_unbind_wrapper':
>
> /tmp/go-build/cgo-gcc-prolog:87: undefined reference to `unbind_wrapper'
>
> clang-11: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
>
>
>
>
> My expectation was that the linker will not check external references to 
> these functions while building the binary, and only when the binary is 
> executed, the dynamic linker will attempt to resolve them. I am suspecting I 
> got something wrong, appreciate if somebody could provide some suggestions.




Usually people use #cgo LDFLAGS lines to tell cgo where to find the
shared library you need to link against. You can also use the LDFLAGS
environment variable to do this.




The basic issue is that cgo needs to see the definition of the C
function so that it knows what its arguments are, including their
types. It needs the information in order to generate a call to the
function.




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/070CFB89-250A-4F57-A6EC-272E9D915570%40gmail.com.


Re: [go-nuts] cgo and dynamic linking of shared labraries

2023-09-26 Thread sbezverk
Thank you for your reply, I was under impression that prototype definitions 
come from C header files,  and since the compilation phase completes with 
success, cgo finds all necessary function definitions. My problem is at the 
linking phase when the linker by some reason tries to resolve ALL functions 
from the shared library, even those which are not directly used/called in CGO 
code.
This causes CGO_LDFLAGS variable to be enormously long as I have to add around 
3k of libraries. Using LDFLAGS environment variable is no better, as after 
adding all libraries to make LD happy, it exceeds the size limit and pretty 
much kills bash.

I am starting to get this:

```
dev-1:/user/sbezverk/go_connect > ls
-bash: /bin/ls: Argument list too long
```

For every internal bash command I try to execute.

I was wondering if there is a keyword forcing the linker not to try to resolve 
everything when building a binary, but to let the dynamic linker to deal with 
it at the execution time.

Thank you
Serguei

On 26/09/23, 06:20, "Ian Lance Taylor" mailto:i...@golang.org>> wrote:


On Sat, Sep 23, 2023 at 6:38 AM sbezverk mailto:sbezv...@gmail.com>> wrote:
>
> Since I could not find the answer in the cgo documentation, I would really 
> appreciate if somebody could help me to understand why when I build cgo code 
> with calls to the shared library, the linker tries to find the shared library 
> even though it is instructed to build dynamic binary and not static.
>
>
>
> I have C built shared library, I have no control how it gets built, I only 
> have lib_blahblah_x64_86.so . There are 2 external functions 
> bind_wrapper/unbind_wrapper in that library which I call from cgo.
>
>
>
> Here is the command line I use to compile:
>
>
>
> CC=/bin/tools/llvm11/llvm-11.0-p25/bin/clang-11 go build -o go_connect 
> -linkshared -ldflags "-linkmode external -extldflags -dynamic" go_connect.go
>
>
>
> The compilation succeeds, but the linker is complaining:
>
>
>
> /tmp/go-link-2323626149/01.o: In function 
> `_cgo_df3b8c92b86e_Cfunc_bind_wrapper':
>
> /tmp/go-build/cgo-gcc-prolog:68: undefined reference to `bind_wrapper'
>
> /tmp/go-link-2323626149/01.o: In function 
> `_cgo_df3b8c92b86e_Cfunc_unbind_wrapper':
>
> /tmp/go-build/cgo-gcc-prolog:87: undefined reference to `unbind_wrapper'
>
> clang-11: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
>
>
>
>
> My expectation was that the linker will not check external references to 
> these functions while building the binary, and only when the binary is 
> executed, the dynamic linker will attempt to resolve them. I am suspecting I 
> got something wrong, appreciate if somebody could provide some suggestions.


Usually people use #cgo LDFLAGS lines to tell cgo where to find the
shared library you need to link against. You can also use the LDFLAGS
environment variable to do this.


The basic issue is that cgo needs to see the definition of the C
function so that it knows what its arguments are, including their
types. It needs the information in order to generate a call to the
function.


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/333CDA20-E50A-4896-B8F1-D1EE02450028%40gmail.com.


[go-nuts] cgo and dynamic linking of shared labraries

2023-09-23 Thread sbezverk
Hello,

 

Since I could not find the answer in the cgo documentation, I would really 
appreciate if somebody could help me to understand why when I build cgo code 
with calls to the shared library, the linker tries to find the shared library 
even though it is instructed to build dynamic binary and not static.

 

I have C built shared library, I have no control how it gets built, I only have 
lib_blahblah_x64_86.so . There are 2 external functions 
bind_wrapper/unbind_wrapper in that library which I call from cgo. 

 

Here is the command line I use to compile:

 

CC=/bin/tools/llvm11/llvm-11.0-p25/bin/clang-11 go build -o go_connect 
-linkshared -ldflags "-linkmode external -extldflags -dynamic" go_connect.go

 

The compilation succeeds, but the linker is complaining:

 

/tmp/go-link-2323626149/01.o: In function 
`_cgo_df3b8c92b86e_Cfunc_bind_wrapper':

/tmp/go-build/cgo-gcc-prolog:68: undefined reference to `bind_wrapper'

/tmp/go-link-2323626149/01.o: In function 
`_cgo_df3b8c92b86e_Cfunc_unbind_wrapper':

/tmp/go-build/cgo-gcc-prolog:87: undefined reference to `unbind_wrapper'

clang-11: error: linker command failed with exit code 1 (use -v to see 
invocation)

 

 

My expectation was that the linker will not check external references to these 
functions while building the binary, and only when the binary is executed, the 
dynamic linker will attempt to resolve them.  I am suspecting I got something 
wrong, appreciate if somebody could provide some suggestions.

 

Thank you

Serguei

-- 
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/D81654F3-8CF7-4FE9-9477-261A305C19D5%40gmail.com.


[go-nuts] Issue with regular expression processing

2022-12-05 Thread sbezverk
Hello,

 

I came across a strange behavior in regular expression processing, please see 
the following simple code which is supposed to match the second line of data 
variable.

 

https://go.dev/play/p/QPrNRuhCv8r

 

The matching data starts at the beginning of the 3rd line so I expect the 
pattern `^` + l + `\s+([0-9]+)\s+` would result in a match, but it does not. If 
I remove `^` from the regular expression, then the match is found. Running 
`grep -E` with regular expression which includes `^` also finds the expected 
match.

 

Appreciate some feedback. Is it a bug or I do something incorrectly?

 

Thank you

Serguei 

-- 
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/1DF73419-C0C8-48CD-ACE5-8745927C70F9%40gmail.com.


[go-nuts] Refactor to use generics to have a single Make

2022-05-03 Thread sbezverk
Hello,

 

I am starting to learn generics and I was wondering if the following code could 
be refactored to use genercis, in order to avoid using per type Make() method.

 

https://go.dev/play/p/gE4Z6Zj19Is

 

I have 3 identical structs, they are defined with different types and used in 
other types by their unique types. The function to create all 3 types can be 
consolidated as the actual structure of is the same.

 

I am curious it would be possible to leverage generics for this. I have made an 
attempt but I still need to use per type Make method.

 

Thank you and appreciate a lot your help.

 

Serguei

-- 
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/D41C14EF-35D1-434F-A719-1E8C88D90C0F%40gmail.com.


[go-nuts] efficiently reconstruct and use data structures encoded with gpb-kv

2021-07-02 Thread sbezverk
Hello,

 

I am looking for some ideas about how efficiently use gpb-kv encoded data 
structure.  If each field of a data structure gets reconstructed with type 
assertion, I suspect that might cause some performance issues for a high rate 
data streams. Another concern is unknown structure of the data object, I mean 
an object of any structure can be built from gpb-kv stream, but how would other 
modules be aware of its fields, fields’ data types, etc to be able to access 
them? I guess it can be done with reflection to check if a field exists in the 
structure and then check its type, but this sounds like a very complicated way.

 

I would appreciate some feedback. Is the performance of reconstructing an 
object from gpb-kv a real concern? And how people are using gpb-kv encoded data 
structures.

 

Thank you

Serguei

-- 
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/C772F9F3-B347-4464-A47F-C9AB3E0CD61B%40gmail.com.


Re: [go-nuts] Custom Unmarshal multi level map

2020-07-29 Thread sbezverk
Thank you, I was suspecting that it was something simple I was missing.

On 2020-07-29, 3:47 PM, "burak serdar"  wrote:

On Wed, Jul 29, 2020 at 1:42 PM sbezverk  wrote:
>
> Hello,
>
>
>
> A bit of help would be much appreciated, here is the sample code: 
https://play.golang.org/p/FYEC7MwU1qQ
>
>
>
> I need to Unmarshal 3 levels map. The information is stored this was as a 
json doc and there is no way to flatten it.  This sample code works but since 
UnmarshalJSON method of Level1 type is not pointer receiver, I do not get back 
into the main newly built map. If I change Level1’s UnmarshalJSON to a pointer 
receiver then line 63 generates a syntax error “invalid operation: cannot index 
l1 (variable of type *Level1)”

I can't say I understand what's really going on here, but if your
problem is with UnmarshalJSON receiver, then:

https://play.golang.org/p/Fl5XRO1ngXE


>
>
>
> I would greatly appreciate some suggestions how to solve this problem.
>
>
>
> Thank you
>
> Serguei
>
>
>
>
>
> --
> 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/214131C2-468E-4036-8F0D-B09037A57C55%40gmail.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/C7CBE68B-063C-405B-AD0C-750A6708F2F5%40gmail.com.


[go-nuts] Custom Unmarshal multi level map

2020-07-29 Thread sbezverk
Hello,

 

A bit of help would be much appreciated, here is the sample code: 
https://play.golang.org/p/FYEC7MwU1qQ

 

I need to Unmarshal 3 levels map. The information is stored this was as a json 
doc and there is no way to flatten it.  This sample code works but since 
UnmarshalJSON method of Level1 type is not pointer receiver, I do not get back 
into the main newly built map. If I change Level1’s UnmarshalJSON to a pointer 
receiver then line 63 generates a syntax error “invalid operation: cannot index 
l1 (variable of type *Level1)”

 

I would greatly appreciate some suggestions how to solve this problem.

 

Thank you

Serguei

 

 

-- 
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/214131C2-468E-4036-8F0D-B09037A57C55%40gmail.com.


[go-nuts] Imp.ListenPacket fail for IPv6 address

2019-10-09 Thread 'Serguei Bezverkhi (sbezverk)' via golang-nuts
Hello,

Here is the part of code where I attempt to listen for icmp packet in a 
namespace. The same code is used for IPv4 and IPv6, only proto and scr are 
differ depending on ipv4 or ipv6 mode.
For IPv4 address code work as expected but for IPv6 ListenPacket fails.

org, err := netns.Get()
if err != nil {
return err
}
defer netns.Set(org)
if err := netns.Set(sourceNS); err != nil {
return err
}

c, err := icmp.ListenPacket(proto, src)
if err != nil {
return fmt.Errorf("call ListenPacket failed 
with error: %+v", err)
}
defer c.Close()

ListenPacket fails with: “call ListenPacket failed with error: listen 
ip6:ipv6-icmp 2001:1::1: bind: cannot assign requested address”

Here is how proto and src looks like for IPv6:

Proto: ip6:ipv6-icmp Address: 2001:1::1

I confirmed that namespace has veth interface with right ipv6 address.

Links found in the namespace, as you can see ipv6 address I am trying to bind 
ListenPacket is present.

Link: lo
Link: veth-1-612de81e
- 2001:1::1

Appreciate some ideas what I do wrong for ipv6 case.
Thank you
Serguei

-- 
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/1DA7A4FE-65FA-46B4-BC58-5AB5BDB080A2%40cisco.com.


[go-nuts] syscall.SendMsg/RecvMsg

2019-03-15 Thread sbezverk
Hello,

 

I am trying to pass a descriptor using syscall.SendMsg/RecvMsg and I noticed 
that inod for the second process is not the same as original, but according to 
Unix Networking API, inod should stay the same and only number of reference to 
inod should be incremented.  Anybody successfully managed to send descriptors 
using syscall.SendMsg?

 

Here is Stat of the file on sending side:

 

File descriptor: 3

File Stat returnd: &{name:test-420291847 size:55 mode:420 
modTime:{wall:782108249 ext:63688268119 loc:0xd50460} sys:{Dev:64768  
>Ino:67217215< Nlink:1 Mode:33188 Uid:0 Gid:0 X__pad0:0 Rdev:0 Size:55 
Blksize:4096 Blocks:8 Atim:{Sec:1552671319 Nsec:781108231} Mtim:{Sec:1552671319 
Nsec:782108249} Ctim:{Sec:1552671319 Nsec:782108249} X__unused:[0 0 0]}}

Encoded Socket Control Messages: [20 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 3 0 0 0 0 0 
0 0]

 

Here is Stat of the file on receiving side:

 

Received buffer: [20 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 7 0 0 0 0 0 0 0]

Received messages: [{Header:{Len:20 Level:1 Type:1} Data:[7 0 0 0]}]

Parsed right: [7]

Created file object with name: /tmp/service-2 

File Stat returnd: &{name:service-2 size:0 mode:1627 modTime:{wall:0 
ext:62135596800 loc:0xd50460} sys:{Dev:7 >Ino:35926817 < Nlink:1 
Mode:49663 Uid:0 Gid:0 X__pad0:0 Rdev:0 Size:0 Blksize:4096 Blocks:0 
Atim:{Sec:0 Nsec:0} Mtim:{Sec:0 Nsec:0} Ctim:{Sec:0 Nsec:0} X__unused:[0 0 0]}}

 

Any suggestions are really welcome!

Thank you

Serguei

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Ioctl Syscall with go and c

2018-08-26 Thread 'Serguei Bezverkhi (sbezverk)' via golang-nuts
Hi Jake,

Ioctl implementation in unix package seems a bit limited, how do you pass for 
example a required struct if “func IoctlSetInt(fd int, req uint, value int)” 
allows only to accept int?? If this package had a func accepting uintptr as a 
parameter, then I guess that could work.

Thank you
Serguei


From:  on behalf of "jake6...@gmail.com" 

Date: Friday, August 24, 2018 at 12:09 PM
To: golang-nuts 
Subject: [go-nuts] Re: Ioctl Syscall with go and c

Probably unrelated to your problem, but IIUC, the syscall package is 
"deprecated", or "frozen". According to the syscall 
documentation:
This package is locked down. Code outside the standard Go repository should be 
migrated to use the corresponding package in the golang.org/x/sys repository. 
That is also where updates required by new systems or versions should be 
applied.

So, while unlikely, it is possible that is the problem. In any case, unless I 
misunderstand, the preferred package for you to use is golang.org/x/sys/unix.

On Thursday, August 23, 2018 at 7:02:13 AM UTC-4, sbez...@cisco.com wrote:
Hello,

I am converting some C code to Go and hit an issue with one particular Syscall:

In C:

device = ioctl(group, 0x3b6a, path);
where path is char[N]

In Go:
ioctlId := 0x3b6a
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
uintptr(unsafe.Pointer(pciDevice)),
)
Where pciDevice is *string with exactly the same value as path in C.

When I run Go bits on the same h/w, same OS, same everything, it fails with 
"errno 22 (invalid argument)". It seems that the issue is how string gets 
passed to Syscall, but I could not find any examples how to do it correctly.
Appreciate some advice here.

Thank you
Serguei
--
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.
For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Ioctl Syscall with go and c

2018-08-23 Thread 'Serguei Bezverkhi (sbezverk)' via golang-nuts
I copied the whole thing to https://github.com/sbezverk/vfio

Running it without actual vfio/iommu might be problematic though.

Before this specific ioctl can be run 2 open calls must succeed. See func main.

Thank you for looking into this problem
Serguei

Sent from my iPhone

> On Aug 23, 2018, at 12:49 PM, Tamás Gulácsi  wrote:
> 
> Cany you give a complete example?
> 
>  https://play.golang.org/p/ZQSf-PwMtd9
> 
> says
> 
>  "device=18446744073709551615 errno=inappropriate ioctl for device"
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Ioctl Syscall with go and c

2018-08-23 Thread 'Serguei Bezverkhi (sbezverk)' via golang-nuts
Hello Jake,

Apologies about formatting, here is correctly formatted code:

// GetGroupFD gets File descriptor for a specified by PCI address device
func GetGroupFD(group int, pciDevice string) (int, error) {
buffer := make([]byte, len(pciDevice)+1)
for i, c := range pciDevice {
buffer[i] = uint8(c)
}
ioctlID := VFIO_GROUP_GET_DEVICE_FD()
fmt.Printf("VFIO_GROUP_GET_DEVICE_FD() returned: %04x\n", 
ioctlID)
buffer[len(pciDevice)] = 0x0
fmt.Printf("pciDevice: %s\n", string(buffer))
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
uintptr(unsafe.Pointer([0])),
)
if errno != 0 {
return 0, fmt.Errorf("fail to get file 
descriptor for %d with errno: %+v", group, errno)
}
return int(device), nil
}

I have also addressed your suggestions without any success. It is latest Centos 
7.5.

Thank you
Serguei

From:  on behalf of "jake6...@gmail.com" 

Date: Thursday, August 23, 2018 at 12:27 PM
To: golang-nuts 
Subject: Re: [go-nuts] Re: Ioctl Syscall with go and c

First off, I don't know how you are posting your code samples, but they are 
unreadable in my Firefox and Chrome on windows.

Second, I would point out that the system you use for converting a "string" to 
the buffer will fail if there are any non-ascii characters.

Third, OT, but I wonder why pciDevice is a string pointer, instead of a string?

Personally, I don't see anything decisively incorrect, but there is a lot of 
context that is missing. If you wanted to indicate your OS, and provide a 
complete working sample, I'm sure I, or someone else could help more.

One thing that jumps out at me is the use of  
uintptr(unsafe.Pointer()), in your initial example. It is hidden by the 
function  VFIO_GROUP_GET_DEVICE_FD(), which is not provided, in your larger 
example. Are you sure you want the pointer to that value, and not the actual 
value? Maybe uintptr(ioctlId)) instead. Seems more standard for IOCTL to me.

And, of course the changes you made to create an appropriate string buffer are 
necessary.


On Thursday, August 23, 2018 at 11:47:18 AM UTC-4, sbez...@cisco.com wrote:
Hi Max,

Thanks for the suggestion, unfortunately it did not help, see below:

func GetGroupFD(group int, pciDevice *string) (int, error) {
fmt.Printf("VFIO_GROUP_GET_DEVICE_FD() returned: %04x\n", 
VFIO_GROUP_GET_DEVICE_FD())
buffer := make([]byte, len(*pciDevice)+1)
for i, c := range *pciDevice {
buffer[i] = uint8(c)
}
buffer[len(*pciDevice)] = 0x0
fmt.Printf("pciDevice: %s\n", string(buffer))
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(VFIO_GROUP_GET_DEVICE_FD()),
uintptr(unsafe.Pointer([0])),
)
if errno != 0 {
return 0, fmt.Errorf("fail to get file descriptor for %d with errno: 
%+v", group, errno)
}
return int(device), nil
}

Any other suggestions?
Thank you
Serguei

From: > on behalf of Max 
>
Date: Thursday, August 23, 2018 at 10:46 AM
To: golang-nuts >
Subject: Re: [go-nuts] Re: Ioctl Syscall with go and c

Hi Serguei,

a Go string or *string do not correspond to a C char *
You must pass the address of the first byte of a sufficiently large buffer:

func GetGroupFD(group int, pciDevice *string) (int, error) {
  const N = 256
  var buffer [N]byte
  device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
[0],
)
   /* if ioctl() is successful, find '\0' in buffer[] and copy the relevant 
portion in *pciDevice */
}

On Thursday, August 23, 2018 at 2:55:29 PM UTC+2, sbez...@cisco.com wrote:
I changed code a little bit to be able to examine variables:

 func GetGroupFD(group int, pciDevice *string) (int, error) {
ioctlId := 0x3b6a
var buffer uintptr
buffer = uintptr(unsafe.Pointer(pciDevice))

--
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.
For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving 

Re: [go-nuts] Re: Ioctl Syscall with go and c

2018-08-23 Thread 'Serguei Bezverkhi (sbezverk)' via golang-nuts
I changed code a little bit to be able to examine variables:

 func GetGroupFD(group int, pciDevice *string) (int, error) {
ioctlId := 0x3b6a
var buffer uintptr
buffer = uintptr(unsafe.Pointer(pciDevice))
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
buffer,
)

(gdb) p 
$8 = (uintptr *) 0xc4200c7b88
(gdb) x/g 0xc4200c7b88
0xc4200c7b88:   0x00c4200c7d08
(gdb) x/g 0x00c4200c7d08
0xc4200c7d08:   0x00c4200122d0
(gdb) x/g 0x00c4200122d0
0xc4200122d0:   0x3a31383a30303030

0x30303030 is start of expected string “:81:11.1”,  first 4 bytes are not 
part of it. Anybody knows where those 4 bytes could have come from? And how to 
get rid of them?
Thank you
Serguei

From:  on behalf of Tamás Gulácsi 

Date: Thursday, August 23, 2018 at 8:13 AM
To: golang-nuts 
Subject: [go-nuts] Re: Ioctl Syscall with go and c

Is it \0-terminated?

2018. augusztus 23., csütörtök 13:02:13 UTC+2 időpontban sbez...@cisco.com a 
következőt írta:
Hello,

I am converting some C code to Go and hit an issue with one particular Syscall:

In C:

device = ioctl(group, 0x3b6a, path);
where path is char[N]

In Go:
ioctlId := 0x3b6a
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
uintptr(unsafe.Pointer(pciDevice)),
)
Where pciDevice is *string with exactly the same value as path in C.

When I run Go bits on the same h/w, same OS, same everything, it fails with 
"errno 22 (invalid argument)". It seems that the issue is how string gets 
passed to Syscall, but I could not find any examples how to do it correctly.
Appreciate some advice here.

Thank you
Serguei
--
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.
For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Ioctl Syscall with go and c

2018-08-23 Thread 'Serguei Bezverkhi (sbezverk)' via golang-nuts
Hello,

I am converting some C code to Go and hit an issue with one particular Syscall:

In C:

device = ioctl(group, 0x3b6a, path);
where path is char[N]

In Go:
ioctlId := 0x3b6a
device, _, errno := syscall.Syscall(
syscall.SYS_IOCTL,
uintptr(group),
uintptr(unsafe.Pointer()),
uintptr(unsafe.Pointer(pciDevice)),
)
Where pciDevice is *string with exactly the same value as path in C.

When I run Go bits on the same h/w, same OS, same everything, it fails with 
"errno 22 (invalid argument)". It seems that the issue is how string gets 
passed to Syscall, but I could not find any examples how to do it correctly.
Appreciate some advice here.

Thank you
Serguei

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Reliable dns client library

2018-05-16 Thread Serguei Bezverkhi (sbezverk)
Hello,

Appreciate if somebody could recommend reliable dns client library supporting 
AXFR type of requests.
I was using miekg/dns and I see some strange results.

Thank you
Serguei

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Running golang compiled binary on QNX

2018-01-30 Thread Serguei Bezverkhi (sbezverk)
Hello,

I was wondering if anybody managed to get golang compiled binary to run on 
32-bit QNX?

I compiled it with  GOARCH=386 GOOS=linux go build -o blah

But when I start it in QNX I get core dump. I double check and the time of 
executable matches type of native qnx binaries.  Appreciate any suggestions.

Thank you
Serguei

 

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Getting Uid/Gid for a folder

2017-07-31 Thread Serguei Bezverkhi (sbezverk)
Hello,

I am having trouble getting GID for a folder. I checked os.Stat api but it 
returns only permissions, there is no Uid or Gid.

stat  /mnt/disks/vol2
  File: ‘/mnt/disks/vol2’
  Size: 6   Blocks: 0  IO Block: 4096   directory
Device: fc12h/64530dInode: 64  Links: 2


Access: (2775/drwxrwsr-x)  Uid: (0/root)   Gid: ( 2323/ UNKNOWN) < 
--  I need to get this..

Greatly appreciate some pointers.
Thanks a lot 
Serguei


-- 
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.
For more options, visit https://groups.google.com/d/optout.