Hello Gophers
I met some trouble in learning go fuzz.
Fuzz has been included in go 1.18, and I want to know some details in fuzz
instrumenting, such as bitmap, block/edge.
However I didn't find that neither src/internal/fuzz nor src/testing.
Some other blogs about how the fuzz works are alse wel
Fuzz has been included in go 1.18, and I want to know some details in fuzz
instrumenting, such as bitmap, block/edge.
However I didn't find that neither src/internal/fuzz nor src/testing.
Some blogs about how the fuzz works are alse welcomed!
Thank you~
--
You received this message because you
I hold the same view, but..
The most helpless thing is that my boss forced me to do something which is
difficult and meaningless...
在2021年4月10日星期六 UTC+8 上午3:55:36 写道:
> On Fri, Apr 9, 2021 at 6:00 AM JX Zhang wrote:
> >
> > Asm in go is in style of plan9. Now I need to compil
Asm in go is in style of plan9. Now I need to compile the asm files into a
.o file which is an ELF object
In original go tool chains, go use go/pkg/tool/linux_amd64/asm to compile
asm to a `go object` file instead of ELF object
--
You received this message because you are subscribed to the Goo
Go does can define functions in a plan9 style assembly file.
I have a question about how to compile a plan9 style asm file to an ELF .o
object?
在2020年10月20日星期二 UTC+8 上午1:12:45 写道:
> Have a look at https://golang.org/doc/asm
> and examples are always a good source of inspiration. For example
> h
Has anyone ever encountered this problem?
在2021年4月6日星期二 UTC+8 下午9:20:48 写道:
> ✘~/workspace/gowork/src/pthread $ go build .
> # pthread
> ccode.c:12:15: warning: incompatible integer to pointer conversion passing
> 'pthread_t' (aka 'unsigned long') to parameter of type 'pthread_once_t *'
> (aka
✘~/workspace/gowork/src/pthread $ go build .
# pthread
ccode.c:12:15: warning: incompatible integer to pointer conversion passing
'pthread_t' (aka 'unsigned long') to parameter of type 'pthread_once_t *'
(aka 'int *') [-Wint-conversion]
/usr/include/pthread.h:495:42: note: passing argument to p
I met some problem about pthread.
I wrote a cgo demo which use some pthread_* function, but it compile failed
ccode.c
```
# include
# include "ccode.h"
# include
int try_pthread(){
pthread_t id;
int ret, i = 0;
ret = pthread_create(&id,NULL,(void *)thread,NULL);
for(i=0;i<=5;i++)
printf("This
> this case, calling an unexported function) is not supported.
>
> Folks who write such code should understand that it can break at any time
> from release to release or across Go implementations.
>
> Than
>
>
>
>
> On Mon, Mar 29, 2021 at 3:35 AM JX Zhang
> The Go runtime and standard library has a public, exported API; this sort
of use of go:linkname to reach into the internals of a standard package (in
this case, calling an unexported function) is not supported.
The limitation to access private functions in std package sounds reasonable.
> You
> go:linkname to refer directly to functions that are defined but not
exported by the standard library.
> This is not supported and is likely to break with any new release. It
evidently breaks with GoLLVM.
Thanks for your attention, but I tried to write a demo with go:linkname.
In fact, it wor
11 matches
Mail list logo