Re: [go-nuts] How I can see My Go code + Compiler generated Go source code -- before a point of assembly?

On Tue, Jul 6, 2021 at 4:44 AM FallingFromBed wrote: > > "...and I'm not really sure what > you are looking for. C++ is a very complex language and does have > many constructs that can be rewritten in simpler ways. Go is a much > simpler language" > > Surely I say to Ian, if we have `var i i

Re: [External] Re: [go-nuts] build debug golang

On Fri, Jul 9, 2021 at 8:33 AM jake...@gmail.com wrote: > > On Thursday, July 8, 2021 at 11:45:19 PM UTC-4 Ian Lance Taylor wrote: >> >> On Thu, Jul 8, 2021 at 8:41 PM 董⼀峰 wrote: >> > >> > Thanks for replying. >> > So golang only supports debugging optimized golang runtime? >> >> Well, Go require

Re: [go-nuts] Understanding gollvm garbage collection

On Fri, Jul 9, 2021 at 7:05 AM Kavindu Gimhan Zoysa wrote: > > Thank you Than, Is go scheduler is responsible for running GC? Go uses a concurrent garbage collector. There are GC worker goroutines that work in parallel with the rest of the program. There are also cases where an ordinary program

[go-nuts] Re: Is it possible and how to connect to USB devices from Android in a Go program?

Hi, Were you able to solve this issue? I'm facing the same problem. Any help would be appreciated. Thanks On Sunday, August 21, 2016 at 1:32:48 AM UTC+2 con...@theninjabunny.com wrote: > > I'm developing an Android app using Golang that make use of a USB device > connected to the Android (on

[go-nuts] Re: Does go:embed embed.FS embeds directories or possible confusion with how it works

Ah okay, thanks seank. I was missing the fact that we can embed multiple files by specifying multiple patterns and assign it to a single `embed.FS`. Now it all makes sense. Thanks! On Monday, 5 July 2021 at 20:56:28 UTC+1 seank...@gmail.com wrote: > `embed` embeds the files with the path you sp

Re: [External] Re: [go-nuts] build debug golang

On Thursday, July 8, 2021 at 11:45:19 PM UTC-4 Ian Lance Taylor wrote: > On Thu, Jul 8, 2021 at 8:41 PM 董⼀峰 wrote: > > > > Thanks for replying. > > So golang only supports debugging optimized golang runtime? > > Well, Go requires that the runtime package be built with optimization > (when us

Re: [go-nuts] Understanding gollvm garbage collection

Also does gollvm create a new stack map? I think it does not use the stack map created by LLVM. Thank you, Kavindu On Friday, 9 July 2021 at 19:35:03 UTC+5:30 Kavindu Gimhan Zoysa wrote: > Thank you Than, Is go scheduler is

Re: [go-nuts] Understanding gollvm garbage collection

Thank you Than, Is go scheduler is responsible for running GC? On Friday, 9 July 2021 at 19:14:43 UTC+5:30 th...@google.com wrote: > >1. If we do not enable the gc (-enable-gc=1), GC assumes all the stack > memory blocks are pointed to the heap. > >2. If gc is enabled, it inserts statepoints and

Re: [go-nuts] Understanding gollvm garbage collection

>1. If we do not enable the gc (-enable-gc=1), GC assumes all the stack memory blocks are pointed to the heap. >2. If gc is enabled, it inserts statepoints and generates the stack map (by LLVM). Using that stack map, GC can find where the actual heap references are located. Yes, this is basically

[go-nuts] Understanding gollvm garbage collection

Hi all, By looking at the source code, and other mail theads in group, I was able to understand the sopport of GC by gollvm upto some extend. 1. If we do not enable the gc (-enable-gc=1), GC assumes all the stack memory blocks are pointed to the heap. 2. If gc is enabled, it inserts statepoint

Re: [go-nuts] Re: C Third Party Lib CGO

Okay, will store the pointer directly in a struct as a private field. Thanks for your time and input, I greatly appreciate it. Tamás Gulácsi schrieb am Freitag, 9. Juli 2021 um 14:17:48 UTC+2: > The runtime and checks does not know what's inside an uintptr, so > converting an uintptr to a(n u

Re: [go-nuts] Re: C Third Party Lib CGO

The runtime and checks does not know what's inside an uintptr, so converting an uintptr to a(n unsafe.)Pointer triggers the warnings. Only the special specified cases are legal. TL;DR; Do not use uintptr. (More elaborate: do not use an uintptr to store and retrieve a pointer - just store the poi

Re: [go-nuts] Re: C Third Party Lib CGO

Yes uintptr is the address the C pointer is pointing to , right? So C doesn't move any memory and therefore the address is still valid until deleted in C code. If I take the value of uintptr variable, convert it back with unsafe.Pointer(uintptr) and pass it to a C function, does C not interpret

Re: [go-nuts] Re: C Third Party Lib CGO

An uintptr *is not a pointer*, so 2. is false. NOTHING at Go's side holds anything regarding MyAppHwnd, and it doesn't seem to be a pointer at all (just a number), so converting that to an unsafe.Pointer is unsafe. The rules about uintptr are there for a reason! Only the allowed use cases are gua