[go-nuts] Need Help: gopls and VSCode Setup with the Go Project - Nested Module Error
Hey Golang-Nuts folks, So I cloned the Go project from GitHub (github.com/golang/go) and tried to open it in Visual Studio Code with the Go extension. But I'm running into some pesky errors from gopls, and it's messing with the module detection. When I open the root of the repo, I get this error message: "Error loading workspace: gopls was not able to find modules in your workspace. When outside of GOPATH, gopls needs to know which modules you are working on. You can fix this by opening your workspace to a folder inside a Go module, or by using a go.work file to specify multiple modules. See the documentation for more information on setting up your workspace: https://github.com/golang/tools/blob/master/gopls/doc/workspace.md.; However, when I open the 'src' directory in VSCode and make that the VSCode workspace root, I get a different gopls error: "Error loading workspace: You have opened a nested module. To work on multiple modules at once, please use a go.work file. See https://github.com/golang/tools/blob/master/gopls/doc/workspace.md for more information on using workspaces." Is there some other setup I need to do to make the Go project work with gopls? Any tips, tricks, or advice you can share would be super helpful. Thanks in advance for any help! -- 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/d1eb103c-5d1b-4b46-9c4f-5edfdf901d95n%40googlegroups.com.
Re: [go-nuts] build unoptimized std lib for debugging
On Monday, April 4, 2022 at 7:00:49 PM UTC-5 arthurwil...@gmail.com wrote:
> On Monday, April 4, 2022 at 6:14:30 PM UTC-5 Ian Lance Taylor wrote:
>
>> On Mon, Apr 4, 2022 at 3:49 PM arthurwil...@gmail.com
>> wrote:
>> >
>> >
>> >
>> > On Sunday, April 3, 2022 at 10:35:04 PM UTC-5 Ian Lance Taylor wrote:
>> >>
>> >> On Sun, Apr 3, 2022 at 6:21 PM arthurwil...@gmail.com
>> >> wrote:
>> >> >
>> >> > I'm trying to build an unoptimized version of the standard library
>> for debugging.
>> >>
>> >> You can just use
>> >>
>> >> go build -gcflags=all="-N -l"
>> >>
>> >
>> > That gives this error:
>> > /Volumes/git/goroot/src (master)$ go build -gcflags=all="-N -l"
>> > no Go files in /Volumes/git/goroot/src
>>
>> You have to run this wherever you are building your actual Go program.
>>
>> What I mean is, if you want to "go build x.go" and you want to build
>> that with a standard library built for maximal debugging, then rn "go
>> build -gcflags=all="-N -l" x.go". Any flags specified by
>> -gcflags=all="FLAGS" will be used to build the standard library as
>> well. You don't need to build the standard library separately.
>>
>> Ian
>>
>
> Thanks Ian. I cleaned the cache and mod cache and passed -x to see all the
> commands run and noticed go build is not propagating the -N -l flags to the
> compiler for a lot of the files.
>
> Also noticed some extra compiler flags (-std, -+) that are not listed in
> the compile command documentation <https://pkg.go.dev/cmd/compile>
>
> What do these -std and -+ compiler flags do?
>
> Why are some compilation commands missing -N -l?
>
>
>
I found some clues:
CompilingRuntime bool "flag:\"+\" help:\"compiling runtime\""
and:
if Flag.CompilingRuntime && Flag.N != 0 {
log.Fatal("cannot disable optimizations while compiling runtime")
}
>
>
>
--
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/8c82e44d-0ac1-433f-bd02-b0ae61cf7e20n%40googlegroups.com.
Re: [go-nuts] build unoptimized std lib for debugging
On Monday, April 4, 2022 at 6:14:30 PM UTC-5 Ian Lance Taylor wrote: > On Mon, Apr 4, 2022 at 3:49 PM arthurwil...@gmail.com > wrote: > > > > > > > > On Sunday, April 3, 2022 at 10:35:04 PM UTC-5 Ian Lance Taylor wrote: > >> > >> On Sun, Apr 3, 2022 at 6:21 PM arthurwil...@gmail.com > >> wrote: > >> > > >> > I'm trying to build an unoptimized version of the standard library > for debugging. > >> > >> You can just use > >> > >> go build -gcflags=all="-N -l" > >> > > > > That gives this error: > > /Volumes/git/goroot/src (master)$ go build -gcflags=all="-N -l" > > no Go files in /Volumes/git/goroot/src > > You have to run this wherever you are building your actual Go program. > > What I mean is, if you want to "go build x.go" and you want to build > that with a standard library built for maximal debugging, then rn "go > build -gcflags=all="-N -l" x.go". Any flags specified by > -gcflags=all="FLAGS" will be used to build the standard library as > well. You don't need to build the standard library separately. > > Ian > Thanks Ian. I cleaned the cache and mod cache and passed -x to see all the commands run and noticed go build is not propagating the -N -l flags to the compiler for a lot of the files. Also noticed some extra compiler flags (-std, -+) that are not listed in the compile command documentation <https://pkg.go.dev/cmd/compile> What do these -std and -+ compiler flags do? Why are some compilation commands missing -N -l? -- 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/dc258f39-89b7-482a-8d46-f7c50e227900n%40googlegroups.com.
Re: [go-nuts] build unoptimized std lib for debugging
On Sunday, April 3, 2022 at 10:35:04 PM UTC-5 Ian Lance Taylor wrote: > On Sun, Apr 3, 2022 at 6:21 PM arthurwil...@gmail.com > wrote: > > > > I'm trying to build an unoptimized version of the standard library for > debugging. > > You can just use > > go build -gcflags=all="-N -l" > > That gives this error: /Volumes/git/goroot/src (master)$ go build -gcflags=all="-N -l" no Go files in /Volumes/git/goroot/src -- 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/79825cc0-4f1b-4559-9c66-4eb5055e2306n%40googlegroups.com.
[go-nuts] build unoptimized std lib for debugging
I'm trying to build an unoptimized version of the standard library for
debugging.
I tried using GO_GCFLAGS='-N -l' but dlv is telling me the code is
optimized.
This is what I did (Notice the "Warning debugging optimized function"
coming from delve)
/Volumes/git/goroot/src (master)$ git log --oneline -1
ba6df85c7c (HEAD -> master, origin/master, origin/HEAD) cmd/compile: add
MOVBEWstore support for GOAMD64>=3
/Volumes/git/goroot/src (master)$ time GO_GCFLAGS='-N -l' ./make.bash
Building Go cmd/dist using /Users/billmorgan/sdk/go1.18. (go1.18
darwin/amd64)
Building Go toolchain1 using /Users/billmorgan/sdk/go1.18.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for darwin/amd64.
---
Installed Go for darwin/amd64 in /Volumes/git/goroot
Installed commands in /Volumes/git/goroot/bin
real2m9.101s
user5m40.243s
sys 0m36.602s
/Volumes/git/goroot/src (master)$ dlv exec ../bin/go -- help
Type 'help' for list of commands.
(dlv) b runtime.main
Breakpoint 1 set at 0x103c68a for runtime.main() ./runtime/proc.go:145
(dlv) c
> runtime.main() ./runtime/proc.go:145 (hits goroutine(1):1 total:1) (PC:
0x103c68a)
Warning: debugging optimized function
140:
141: // Value to use for signal mask for newly created M's.
142: var initSigmask sigset
143:
144: // The main goroutine.
=> 145: func main() {
146: g := getg()
147:
148: // Racectx of m0->g0 is used only as the parent of the main
goroutine.
149: // It must not be used for anything else.
150: g.m.g0.racectx = 0
(dlv) q
--
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/c69c6f31-c11a-43e8-85b8-cff5cac97e93n%40googlegroups.com.
[go-nuts] src/errors/errors_test.go if err != err ?
How is it possible for this test case to ever fail?
// Same allocation should be equal to itself (not crash).
err := errors.New("jkl")
if err != err {
t.Errorf(`err != err`)
}
https://cs.opensource.google/go/go/+/master:src/errors/errors_test.go;drc=519474451a44b861e54466998a893a173bd54c4b;l=24
--
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/307b4340-a9e4-4997-9a30-e508ddc65146n%40googlegroups.com.
[go-nuts] comment in test/ken/slicearray.go
this should probably be updated to width 8: // width 4 (float64) https://cs.opensource.google/go/go/+/master:test/ken/slicearray.go;l=92#:~:text=91-,92,-93 -- 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/0d8e034d-8631-406f-9ae2-eb931fee82e3n%40googlegroups.com.
[go-nuts] Re: compile time error vs runtime crash for same array
On Saturday, November 13, 2021 at 12:48:41 PM UTC-6 seank...@gmail.com
wrote:
> global variables are stored in there data section of the compiled binary,
> the linker imposes a 2GB size limit
> the array in main can be allocated at runtime, and given enough memory, it
> could succeed
>
>
Why does the linker impose a 2GB limit on .bss data but not heap memory? Is
there a limit on heap variables?
>
> On Saturday, November 13, 2021 at 5:46:29 PM UTC arthurwil...@gmail.com
> wrote:
>
>> On a 64bit Mac, this code:
>>
>> package main
>>
>> var X [^uint(0)>>14]byte
>> func main() {
>> }
>>
>> produces a compile time error:
>> main.X: symbol too large (1125899906842623 bytes > 20 bytes)
>>
>> But this compiles and crashes at runtime.
>>
>> package main
>>
>> func main() {
>> var X [^uint(0) >> 14]byte
>> _ = X
>> }
>>
>> runtime: out of memory: cannot allocate 1125899906842624-byte block
>> (3997696 in use)
>> fatal error: out of memory
>>
>> goroutine 1 [running]:
>> runtime.throw({0x1061335, 0x11})
>> /usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc42658
>> sp=0xc42628 pc=0x102b031
>> runtime.(*mcache).allocLarge(0x100a734, 0x3, 0x11, 0x1)
>> /usr/local/go/src/runtime/mcache.go:229 +0x22e fp=0xc426b8
>> sp=0xc42658 pc=0x101086e
>> runtime.mallocgc(0x3, 0x1059300, 0x1)
>> /usr/local/go/src/runtime/malloc.go:1082 +0x5c5 fp=0xc42738
>> sp=0xc426b8 pc=0x100a645
>> runtime.newobject(0x1058a00)
>> /usr/local/go/src/runtime/malloc.go:1228 +0x27 fp=0xc42760
>> sp=0xc42738 pc=0x100aa87
>> main.main()
>> /Users/billmorgan/git/tmp/main.go:5 +0x25 fp=0xc42780
>> sp=0xc42760 pc=0x1054c65
>> runtime.main()
>> /usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc427e0
>> sp=0xc42780 pc=0x102d6c7
>> runtime.goexit()
>> /usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc427e8
>> sp=0xc427e0 pc=0x1051fa1
>>
>>
>> Why does the 2nd program succeed compilation of the same array that
>> failed compilation in the 1st program?
>>
>> It was known ahead of time that the allocation would fail so I think the
>> 2nd program should have failed to compile too.
>>
>>
>>
>>
>>
--
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/5841fddd-8bf6-4e4e-b27c-7e74c8917516n%40googlegroups.com.
[go-nuts] compile time error vs runtime crash for same array
On a 64bit Mac, this code:
package main
var X [^uint(0)>>14]byte
func main() {
}
produces a compile time error:
main.X: symbol too large (1125899906842623 bytes > 20 bytes)
But this compiles and crashes at runtime.
package main
func main() {
var X [^uint(0) >> 14]byte
_ = X
}
runtime: out of memory: cannot allocate 1125899906842624-byte block
(3997696 in use)
fatal error: out of memory
goroutine 1 [running]:
runtime.throw({0x1061335, 0x11})
/usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc42658
sp=0xc42628 pc=0x102b031
runtime.(*mcache).allocLarge(0x100a734, 0x3, 0x11, 0x1)
/usr/local/go/src/runtime/mcache.go:229 +0x22e fp=0xc426b8
sp=0xc42658 pc=0x101086e
runtime.mallocgc(0x3, 0x1059300, 0x1)
/usr/local/go/src/runtime/malloc.go:1082 +0x5c5 fp=0xc42738
sp=0xc426b8 pc=0x100a645
runtime.newobject(0x1058a00)
/usr/local/go/src/runtime/malloc.go:1228 +0x27 fp=0xc42760
sp=0xc42738 pc=0x100aa87
main.main()
/Users/billmorgan/git/tmp/main.go:5 +0x25 fp=0xc42780
sp=0xc42760 pc=0x1054c65
runtime.main()
/usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc427e0
sp=0xc42780 pc=0x102d6c7
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc427e8
sp=0xc427e0 pc=0x1051fa1
Why does the 2nd program succeed compilation of the same array that failed
compilation in the 1st program?
It was known ahead of time that the allocation would fail so I think the
2nd program should have failed to compile too.
--
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/35f1d7f4-ca10-49f1-9f54-351f7d6034e0n%40googlegroups.com.
Re: [go-nuts] Re: go get v git clone
On Saturday, March 13, 2021 at 8:44:44 AM UTC-6 Jan Mercl wrote: > On Sat, Mar 13, 2021 at 3:35 PM arthurwil...@gmail.com > wrote: > > > I just want to remove one thing go getted, not the entire cache. > > For new features one can fill a proposal. If accepted, a follow-up > with the implementation CL is very nice proprosal created https://github.com/golang/go/issues/44989 -- 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/b2ead015-d8af-40e9-bfe7-d14ef4fc45f0n%40googlegroups.com.
Re: [go-nuts] Re: go get v git clone
On Saturday, March 13, 2021 at 10:02:50 AM UTC-6 Jan Mercl wrote: > On Sat, Mar 13, 2021 at 4:57 PM arthurwil...@gmail.com > wrote: > > > OK I'll try and figure out how to do that. What is a CL? > > Change List. A patch against the repository that implements a feature, > fixes a bug etc. Thanks Jan. I never heard CL jargon for patchset before. I was wondering what does Craigs List have to do with this. -- 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/b71c45ab-fb5c-4bf5-ac83-aef87b8ccd83n%40googlegroups.com.
Re: [go-nuts] Re: go get v git clone
On Saturday, March 13, 2021 at 8:44:44 AM UTC-6 Jan Mercl wrote: > On Sat, Mar 13, 2021 at 3:35 PM arthurwil...@gmail.com > wrote: > > > I just want to remove one thing go getted, not the entire cache. > > For new features one can fill a proposal. If accepted, a follow-up > with the implementation CL is very nice OK I'll try and figure out how to do that. What is a CL? -- 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/eedd8c55-73e2-44e4-8be0-9d67c4ed2f6an%40googlegroups.com.
[go-nuts] Re: go get v git clone
On Friday, March 12, 2021 at 11:13:44 PM UTC-6 Carla Pfaff wrote: > You use git clone. Go get is for adding a dependency to a project. > > Also how do I delete something I go getted? >> > > ~/go/pkg/mod is just a local cache, nothing you work in. You can clear the > whole module cache with go clean -modcache > I just want to remove one thing go getted, not the entire cache. -- 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/33d704a3-27e9-4000-8d30-0ee6bab7dbd4n%40googlegroups.com.
[go-nuts] go get v git clone
if I want to get a git repo of go module code and start hacking on it do I use go get or git clone? I tried go get, but it downloaded to ~/go/pkg/mod and when I tried to run one of the tests it didn't work. Also there's no .git dir with the history in the go get tree of the code. Is there a way to go get the git repo to a path? Also how do I delete something I go getted? (or go got?) Looking for the go unget command. -- 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/4296d8ae-7e4b-4fcc-a50e-916724a36aa2n%40googlegroups.com.
[go-nuts] where is the g writebuf flushed?
in runtime/print.go gwrite, if the data is put in the gp.writebuf where does that writebuf get flushed? -- 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/58a19ab0-c995-474b-9bf5-ae0f3561ad6fn%40googlegroups.com.
Re: [go-nuts] maptype questions
On Monday, June 29, 2020 at 10:41:15 PM UTC-5 Ian Lance Taylor wrote:
> On Mon, Jun 29, 2020 at 6:33 PM arthurwil...@gmail.com
> wrote:
> >
> > On Monday, June 29, 2020 at 8:16:14 PM UTC-5 Ian Lance Taylor wrote:
> >>
> >> On Mon, Jun 29, 2020 at 5:32 PM Bill Morgan
> >> wrote:
> >> >
> >> > for this code:
> >> >
> >> > m := make(map[int]int, 9)
> >> >
> >> > I think the compiler creates a maptype that is stored at
> type.*+60480(SB) that it uses for the call to runtime.makemap:
> >> >
> >> > m := make(map[int]int, 9)
> >> > 0x10d0b81 488d05f8ec LEAQ type.*+60480(SB), AX
> >> > 0x10d0b88 48890424 MOVQ AX, 0(SP)
> >> > 0x10d0b8c 48c74424080900 MOVQ $0x9, 0x8(SP)
> >> > 0x10d0b95 48c7442410 MOVQ $0x0, 0x10(SP)
> >> > 0x10d0b9e 6690 NOPW
> >> > 0x10d0ba0 e8fbdff3ff CALL runtime.makemap(SB)
> >> >
> >> > Where is the code in the compiler that creates the maptype? I'm
> wondering how the bucket size is computed and how the rest of the maptype
> structure is filled out.
> >>
> >> https://golang.org/src/cmd/compile/internal/gc/reflect.go#L189
> >>
> >> > Is there a way to print out the type info stored in the binary?
> >>
> >> I'm not sure if this is what you want, but you can use reflect.TypeOf:
> >> https://play.golang.org/p/FEUIoqc6SMU .
> >>
> >> Ian
> >
> > Thanks Ian, that is pretty cool. I think that is printing out the
> map[int]int type though instead of the *maptype that is generated by the
> compiler and passed to runtime.makemap.
> >
> > I think this is loading a pointer to a maptype into AX to pass as the
> first arg to runtime.makemap. The maptype seems to be stored at
> type.*+60480(SB).
> >
> > LEAQ type.*+60480(SB), AX
> >
> > here's the type I'm asking about: where is this guy created in the
> compiler?
> >
> > type maptype struct {
> > typ _type
> > key *_type
> > elem *_type
> > bucket *_type // internal type representing a hash bucket
> > // function for hashing keys (ptr to key, seed) -> hash
> > hasher func(unsafe.Pointer, uintptr) uintptr
> > keysize uint8 // size of key slot
> > elemsize uint8 // size of elem slot
> > bucketsize uint16 // size of bucket
> > flags uint32
> > }
>
> https://golang.org/src/cmd/compile/internal/gc/reflect.go#L1285
>
> Ian
>
Where is the maptype.bucket.size computed?
It is used here in makemap (t.bucket.size):
https://golang.org/src/runtime/map.go#L304
I'm assuming the bucket is created here in bmap but I couldn't figure out
how the bucket.size is computed and set:
https://golang.org/src/cmd/compile/internal/gc/reflect.go#L82
--
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/eec936f0-731b-4093-a75c-3e452380df54n%40googlegroups.com.
Re: [go-nuts] maptype questions
On Monday, June 29, 2020 at 8:16:14 PM UTC-5 Ian Lance Taylor wrote:
> On Mon, Jun 29, 2020 at 5:32 PM Bill Morgan
> wrote:
> >
> > for this code:
> >
> > m := make(map[int]int, 9)
> >
> > I think the compiler creates a maptype that is stored at
> type.*+60480(SB) that it uses for the call to runtime.makemap:
> >
> > m := make(map[int]int, 9)
> > 0x10d0b81 488d05f8ec LEAQ type.*+60480(SB), AX
> > 0x10d0b88 48890424 MOVQ AX, 0(SP)
> > 0x10d0b8c 48c74424080900 MOVQ $0x9, 0x8(SP)
> > 0x10d0b95 48c7442410 MOVQ $0x0, 0x10(SP)
> > 0x10d0b9e 6690 NOPW
> > 0x10d0ba0 e8fbdff3ff CALL runtime.makemap(SB)
> >
> > Where is the code in the compiler that creates the maptype? I'm
> wondering how the bucket size is computed and how the rest of the maptype
> structure is filled out.
>
> https://golang.org/src/cmd/compile/internal/gc/reflect.go#L189
>
> > Is there a way to print out the type info stored in the binary?
>
> I'm not sure if this is what you want, but you can use reflect.TypeOf:
> https://play.golang.org/p/FEUIoqc6SMU .
>
> Ian
>
Thanks Ian, that is pretty cool. I think that is printing out the
map[int]int type though instead of the *maptype that is generated by the
compiler and passed to runtime.makemap.
I think this is loading a pointer to a maptype into AX to pass as the first
arg to runtime.makemap. The maptype seems to be stored at type.*+60480(SB).
LEAQ type.*+60480(SB), AX
here's the type I'm asking about: where is this guy created in the
compiler?
type maptype struct {
typ _type
key *_type
elem *_type
bucket *_type // internal type representing a hash bucket
// function for hashing keys (ptr to key, seed) -> hash
hasher func(unsafe.Pointer, uintptr) uintptr
keysize uint8 // size of key slot
elemsize uint8 // size of elem slot
bucketsize uint16 // size of bucket
flags uint32
}
Here are the runtime.makemap comments and signature
// makemap implements Go map creation for make(map[k]v, hint).
// If the compiler has determined that the map or the first bucket
// can be created on the stack, h and/or bucket may be non-nil.
// If h != nil, the map can be created directly in h.
// If h.buckets != nil, bucket pointed to can be used as the first bucket.
func makemap(t *maptype, hint int, h *hmap) *hmap {
--
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/c99ffa05-5c22-416c-bef9-f871490eff2an%40googlegroups.com.
