t 2:52 AM aihui zhu >
> wrote:
> >
> > the syscall.Syscall function accept/return only uintptr, how should i
> deal with structure?
> >
> > i'm asking this question is because that i want to avoid CGo and use
> pure Go in my module.
>
> What
the syscall.Syscall function accept/return only uintptr, how should i deal
with structure?
i'm asking this question is because that i want to avoid CGo and use pure
Go in my module.
thank you.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
thank you and yes, i'm trying to debug a SIGSEGV occurred in C code.
i'm going changed my C code to some other way, since it's a bit difficult
to retrieve the stack trace for debugging..
On Saturday, October 3, 2020 at 1:12:36 PM UTC+8 Kurtis Rader wrote:
> On Fri, Oct 2, 202
t;
> On Fri, Oct 2, 2020 at 9:23 PM aihui zhu wrote:
>
>> I mean that is there any way to expose SIGSEGV to macOS system just like
>> a pure C program, so that the system could generate .crash file
>> automatically.
>> currently, seems that go itself catch the SIG
GSEGV.
please correct me if i'm wrong at something, thank you.
On Saturday, October 3, 2020 at 10:53:51 AM UTC+8 Kurtis Rader wrote:
> On Fri, Oct 2, 2020 at 12:26 PM Ian Lance Taylor wrote:
>
>> On Thu, Oct 1, 2020 at 10:44 PM aihui zhu wrote:
>> >
>> > C pro
zah _analyticsusers 21K Oct 2 13:37
Library/Logs/DiagnosticReports/a.out_2020-10-02-133751_hac.crash
```
could go generates .crash file?
On Saturday, October 3, 2020 at 3:26:13 AM UTC+8 Ian Lance Taylor wrote:
> On Thu, Oct 1, 2020 at 10:44 PM aihui zhu wrote:
> >
> > C program c
-lh
total 2.9G
-r 1 zah wheel 2.9G Oct 2 13:37 core.37596
On Friday, October 2, 2020 at 12:55:05 PM UTC+8 Ian Lance Taylor wrote:
> On Thu, Oct 1, 2020 at 9:05 PM Kurtis Rader wrote:
> >
> > On Thu, Oct 1, 2020 at 8:36 PM aihui zhu wrote:
> >>
> >> on a
on a linux virtual machine GOTRACEBACK=crash works fine and would generates
core files in working directory for me.
On Friday, October 2, 2020 at 11:33:37 AM UTC+8 aihui zhu wrote:
> yes, there are only go stack trace, and no core file was generated. with a
> pure C program, it could ge
yes, there are only go stack trace, and no core file was generated. with a
pure C program, it could generate core file in /cores directory.
On Friday, October 2, 2020 at 10:16:51 AM UTC+8 Ian Lance Taylor wrote:
> On Thu, Oct 1, 2020 at 5:39 PM aihui zhu wrote:
> >
> > I have e
I have enabled coredump with `ulimit -c unlimited`, and run the binary with
GOTRACEBACK=crash, but it only outputs the go stack trace when crash.
thanks.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop r
for example A deps B and B deps C
adds replace B => local/path/to/B in A/go.mod and replace C =>
local/path/to/C in B/go.mod
changes C doesn't rebuilds A.
it's it a bug or work as intend?
how could i make rebuild works, otherwise i may need to create git commits,
update A and B package again a
my program and plugin shares some common package, i'm temporarily copy the
plugin's main package to main_$timestamp,
so i can avoid same pluginpath and load it many times.
but it doesn't works for some problems:
if i changes only structure method, because of type equal, the runtime
still refers
Problem solved, thanks.
I created a harfbuzz.cc inside the go package directory, it contains only
one line
#include "harfbuzz/src/harfbuzz.cc"
and then change the cgo header to:
/*
#cgo CFLAGS: -Iharfbuzz/src
#cgo CXXFLAGS: -std=c++11
#cgo LDFLAGS: -lstdc++
#include
#include "hb.h"
#includ
I'm trying to embed the harfbuzz(http://github.com/harfbuzz/harfbuzz)
library source code into go package,
just like what the glfw(http://github.com/go-gl/glfw) library does.
The difference is that glfw contains only C, but harfbuzz is actually a C++
library and provide C API.
My cgo header cod
14 matches
Mail list logo
