FAQ
So, I've been experimenting quite a bit... first being, I want to add a new
argument to makemap, so I can add a specific flag for whether or not I want
debugging. For example, if it is enabled, I want it to print the value of
each argument, the entrance and exit of certain functions, the callers up
to what is relevant (I.E, up to main()), etc. This is so I can add changes
to the map and be able to debug certain changes and not be overwhelmed with
debug information from the hundreds of uses of map from others.

Currently, I added a new parameter to make(map...) successfully, however if
I pass as a flag to the new argument to debug, I expect to see debug
information. Hence, I added to makemap a 5th argument...

func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer, debug
bool) *hmap

Unfortunately it seems that... it's not so simple. I HAVE made the
appropriate changes in reflect_makemap, and made the appropriate changes to
'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
root of the Go repository, and it continues to compile Go bootstrap tool,
Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
I attempt to build packages and commands for windows/amd64, it fails with a
fatal error stating 'fatal error: evacuation not done in time'.

The stack trace is as follows... note debug shows an integer, I converted
the bool to an uintptr to see if it happened to be an address and not
garbage value. Its not entire garbage, because the value is consistent each
time I run it, so its probably the value from something else. I'm assuming
the ABI pushes parameters on the stack.


##### Building packages and commands for windows/amd64.
t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
fatal error: evacuation not done in time

goroutine 1 [running, locked to thread]:
runtime.throw(0x6cc46f, 0x1b)
         C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
+0x9c fp=0xc042037cb8 sp=0xc042037c98
runtime.hashGrow(0x6830e0, 0x809ec0)
         C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857
+0x195 fp=0xc042037cf0 sp=0xc042037cb8
runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)
         C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553
+0x3a4 fp=0xc042037dc8 sp=0xc042037cf0
unicode.init()
         C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
+0xf8 fp=0xc042037e60 sp=0xc042037dc8
bytes.init()
         C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151 +0x55
fp=0xc042037e90 sp=0xc042037e60
bufio.init()
         C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410 +0x50
fp=0xc042037ec0 sp=0xc042037e90
main.init()
         C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5 +0x55
fp=0xc042037f38 sp=0xc042037ec0
runtime.main()
         C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
+0x1bb fp=0xc042037f90 sp=0xc042037f38
runtime.goexit()
         C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059
+0x1 fp=0xc042037f98 sp=0xc042037f90


Removing the extra parameter causes it to run just fine. Even if I could
(which I am thinking of doing) marking the Most Significant Bit of hint,
since it only uses the first 32-bits, for flags, I need to know how Go
handles passing it's parameters and why its so sensitive to minimal changes
like this.

Also, I'll assume that it did NOT go through make(...) because OMAKEMAP
explicitly sets debug to 0 for now, unconditionally, so it's being created
in some other manner. I was thinking, after doing some digging, that it
makes some specific assumptions in the assembly implementation of some go
functions, and only push 4 arguments instead of 5, hence the garbage
values. However, if it was pushed in reverse order, then that would not
explain the fact that some are nil and others are not. Are parameters
pushed through registers? That'd kind of make sense if that's the case,
because then the 5th one, R8 I think, would probably hold the previous
value.

Perhaps I'm wrong and am just doing it wrong, I dunno, any help would be
appreciated. I just need to know what changes I should make to add a new
argument (that way I can create my own later on).

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Matthew Dempsky at Jun 7, 2016 at 8:18 pm

    On Tue, Jun 7, 2016 at 1:05 PM, Kyle Stanly wrote:

    I just need to know what changes I should make to add a new argument (that
    way I can create my own later on).
    1. Add your new parameter to func makemap in runtime/hashmap.go.
    2. Update the function signature in
    cmd/compile/internal/gc/builtin/runtime.go.
    3. Run "go generate" in cmd/compile/internal/gc to refresh builtin.go.
    4. Update cmd/compile/internal/gc/walk.go to pass the new argument to the
    generated makemap call. See the OMAKEMAP case in walkexpr, specifically
    the call to mkcall1.

    Also, it's hard to follow your explanations of what you've done. It would
    be easier if you would upload CLs <https://golang.org/doc/contribute.html> to
    understand what you've done. (Please include "DO NOT REVIEW" in the
    description.)

    Cheers

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Stanly at Jun 7, 2016 at 8:34 pm
    Now here's a problem with that. I'm using Go 1.7-beta, so any commit log
    (?) would be very long (compared to branch 1.6). I also downloaded the
    source directly, as I wasn't sure where to locate the 1.7 branch, hence
    it'd most likely have parts outdated. Since the changes I made were simple,
    it'd be easy to just clone the actual branch and make the changes again, do
    you know where I can find that? Would it be dev-ssa? Alternatively I could
    post the relevant bits I changed.

    To be frank, I did all you suggested, and I can post the code of where I
    did.
    On Tuesday, June 7, 2016 at 4:18:12 PM UTC-4, Matthew Dempsky wrote:

    On Tue, Jun 7, 2016 at 1:05 PM, Kyle Stanly <thei...@gmail.com
    <javascript:>> wrote:
    I just need to know what changes I should make to add a new argument
    (that way I can create my own later on).
    1. Add your new parameter to func makemap in runtime/hashmap.go.
    2. Update the function signature in
    cmd/compile/internal/gc/builtin/runtime.go.
    3. Run "go generate" in cmd/compile/internal/gc to refresh builtin.go.
    4. Update cmd/compile/internal/gc/walk.go to pass the new argument to the
    generated makemap call. See the OMAKEMAP case in walkexpr, specifically
    the call to mkcall1.

    Also, it's hard to follow your explanations of what you've done. It would
    be easier if you would upload CLs <https://golang.org/doc/contribute.html> to
    understand what you've done. (Please include "DO NOT REVIEW" in the
    description.)

    Cheers
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Jun 7, 2016 at 8:44 pm

    On Tue, Jun 7, 2016 at 1:34 PM, Kyle Stanly wrote:

    I'm using Go 1.7-beta, so any commit log (?) would be very long (compared
    to branch 1.6).
    Gerrit is able to handle wherever you've based your work off of.

    Since the changes I made were simple, it'd be easy to just clone the actual
    branch and make the changes again, do you know where I can find that? Would
    it be dev-ssa?
    Go development is done on the "master" branch. You can clone the Go repo
    with "git clone https://go.googlesource.com/go".

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Keith Randall at Jun 7, 2016 at 8:27 pm

    On Tue, Jun 7, 2016 at 1:05 PM, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add a
    new argument to makemap, so I can add a specific flag for whether or not I
    want debugging. For example, if it is enabled, I want it to print the value
    of each argument, the entrance and exit of certain functions, the callers
    up to what is relevant (I.E, up to main()), etc. This is so I can add
    changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully, however
    if I pass as a flag to the new argument to debug, I expect to see debug
    information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.
    go generate is not required and will not do anything.
    Did you change the signature of makemap in
    cmd/compile/internal/gc/builtin/runtime.go and rerun
    cmd/compile/internal/gc/mkbuiltin.go?

    The stack trace is as follows... note debug shows an integer, I converted
    the bool to an uintptr to see if it happened to be an address and not
    garbage value. Its not entire garbage, because the value is consistent each
    time I run it, so its probably the value from something else. I'm assuming
    the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857
    +0x195 fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553
    +0x3a4 fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410 +0x50
    fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059
    +0x1 fp=0xc042037f98 sp=0xc042037f90

    I'm confused, there is no makemap in this stack trace. Where is the debug
    flag displayed?

    Removing the extra parameter causes it to run just fine. Even if I could
    (which I am thinking of doing) marking the Most Significant Bit of hint,
    since it only uses the first 32-bits, for flags, I need to know how Go
    handles passing it's parameters and why its so sensitive to minimal changes
    like this.

    Also, I'll assume that it did NOT go through make(...) because OMAKEMAP
    explicitly sets debug to 0 for now, unconditionally, so it's being created
    in some other manner. I was thinking, after doing some digging, that it
    makes some specific assumptions in the assembly implementation of some go
    functions, and only push 4 arguments instead of 5, hence the garbage
    values. However, if it was pushed in reverse order, then that would not
    explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.
    No, everything is passed on the stack. It's not PUSHed but MOVed to the
    argument slots. If you only reserved 4 slots and gave makemap 5 arguments,
    that would clobber some local variable which could lead to arbitrarily bad
    behavior. Make sure runtime.go/mkbuiltin.go are done correctly. Also
    check the generated assembly at a makemap call to see if it seems
    reasonable.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would be
    appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).

    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Stanly at Jun 7, 2016 at 8:46 pm
    The change I made in cmd/compile/internal/gc/builtin/runtime.go...

    func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any, debug
    uintptr) (hmap map[any]any)

    Once again note debug is a uintptr so I can correctly print out the value.

    runtime.go never mentioned needing to explicitly run mkbuiltin.go, I simply
    ran go generate, which explains why I messed up. Am I supposed to
    explicitly run `go run cmd/compile/internal/gc/mkbuiltin.go'? I figured
    it'd be invoked automatically when I ran all.bat

    The absence of makemap is what I'm confused about. I figured that it didn't
    invoke makemap because debug is passed another value than 0, the value I
    explicitly pass to mkcall1, seen below...

    n = mkcall1(fn, n.Type, init, typename(n.Type), conv(n.Left, Types[TINT64]),
    a, r, conv(Nodintconst(0), Types[TUINTPTR]))

    Lastly, makemap is defined as such...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer, debug
    uintptr) *hmap


    On Tuesday, June 7, 2016 at 4:27:22 PM UTC-4, Keith Randall wrote:



    On Tue, Jun 7, 2016 at 1:05 PM, Kyle Stanly <thei...@gmail.com
    <javascript:>> wrote:
    So, I've been experimenting quite a bit... first being, I want to add a
    new argument to makemap, so I can add a specific flag for whether or not I
    want debugging. For example, if it is enabled, I want it to print the value
    of each argument, the entrance and exit of certain functions, the callers
    up to what is relevant (I.E, up to main()), etc. This is so I can add
    changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully, however
    if I pass as a flag to the new argument to debug, I expect to see debug
    information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.
    go generate is not required and will not do anything.
    Did you change the signature of makemap in
    cmd/compile/internal/gc/builtin/runtime.go and rerun
    cmd/compile/internal/gc/mkbuiltin.go?

    The stack trace is as follows... note debug shows an integer, I converted
    the bool to an uintptr to see if it happened to be an address and not
    garbage value. Its not entire garbage, because the value is consistent each
    time I run it, so its probably the value from something else. I'm assuming
    the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857
    +0x195 fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553
    +0x3a4 fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410 +0x50
    fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()

    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059 +0x1
    fp=0xc042037f98 sp=0xc042037f90

    I'm confused, there is no makemap in this stack trace. Where is the debug
    flag displayed?

    Removing the extra parameter causes it to run just fine. Even if I could
    (which I am thinking of doing) marking the Most Significant Bit of hint,
    since it only uses the first 32-bits, for flags, I need to know how Go
    handles passing it's parameters and why its so sensitive to minimal changes
    like this.

    Also, I'll assume that it did NOT go through make(...) because OMAKEMAP
    explicitly sets debug to 0 for now, unconditionally, so it's being created
    in some other manner. I was thinking, after doing some digging, that it
    makes some specific assumptions in the assembly implementation of some go
    functions, and only push 4 arguments instead of 5, hence the garbage
    values. However, if it was pushed in reverse order, then that would not
    explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.
    No, everything is passed on the stack. It's not PUSHed but MOVed to the
    argument slots. If you only reserved 4 slots and gave makemap 5 arguments,
    that would clobber some local variable which could lead to arbitrarily bad
    behavior. Make sure runtime.go/mkbuiltin.go are done correctly. Also
    check the generated assembly at a makemap call to see if it seems
    reasonable.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would be
    appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).

    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Keith Randall at Jun 7, 2016 at 8:59 pm

    On Tue, Jun 7, 2016 at 1:46 PM, Kyle Stanly wrote:

    The change I made in cmd/compile/internal/gc/builtin/runtime.go...

    func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any,
    debug uintptr) (hmap map[any]any)

    Once again note debug is a uintptr so I can correctly print out the value.

    runtime.go never mentioned needing to explicitly run mkbuiltin.go, I
    simply ran go generate, which explains why I messed up. Am I supposed to
    explicitly run `go run cmd/compile/internal/gc/mkbuiltin.go'? I figured
    it'd be invoked automatically when I ran all.bat
    Yes, you must do that manually. It's sort of a historical accident that we
    do it this way, as mkbuiltin.go used to be a shell script and we didn't
    want to have the build dependent on shell programs. We could change it now
    that it is in Go and we depend on a bootstrap go implementation anyway.

    The absence of makemap is what I'm confused about. I figured that it
    didn't invoke makemap because debug is passed another value than 0, the
    value I explicitly pass to mkcall1, seen below...
    Absence of makemap from where? Be specific. It probably called makemap,
    returned successfully, then got some corruption that caused a later
    mapassign1 to fail.

    n = mkcall1(fn, n.Type, init, typename(n.Type), conv(n.Left, Types[TINT64
    ]), a, r, conv(Nodintconst(0), Types[TUINTPTR]))

    Lastly, makemap is defined as such...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug uintptr) *hmap


    On Tuesday, June 7, 2016 at 4:27:22 PM UTC-4, Keith Randall wrote:


    On Tue, Jun 7, 2016 at 1:05 PM, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add a
    new argument to makemap, so I can add a specific flag for whether or not I
    want debugging. For example, if it is enabled, I want it to print the value
    of each argument, the entrance and exit of certain functions, the callers
    up to what is relevant (I.E, up to main()), etc. This is so I can add
    changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully, however
    if I pass as a flag to the new argument to debug, I expect to see debug
    information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.
    go generate is not required and will not do anything.
    Did you change the signature of makemap in
    cmd/compile/internal/gc/builtin/runtime.go and rerun
    cmd/compile/internal/gc/mkbuiltin.go?

    The stack trace is as follows... note debug shows an integer, I
    converted the bool to an uintptr to see if it happened to be an address and
    not garbage value. Its not entire garbage, because the value is consistent
    each time I run it, so its probably the value from something else. I'm
    assuming the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857
    +0x195 fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553
    +0x3a4 fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410
    +0x50 fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()

    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059 +0x1
    fp=0xc042037f98 sp=0xc042037f90

    I'm confused, there is no makemap in this stack trace. Where is the
    debug flag displayed?

    Removing the extra parameter causes it to run just fine. Even if I could
    (which I am thinking of doing) marking the Most Significant Bit of hint,
    since it only uses the first 32-bits, for flags, I need to know how Go
    handles passing it's parameters and why its so sensitive to minimal changes
    like this.

    Also, I'll assume that it did NOT go through make(...) because OMAKEMAP
    explicitly sets debug to 0 for now, unconditionally, so it's being created
    in some other manner. I was thinking, after doing some digging, that it
    makes some specific assumptions in the assembly implementation of some go
    functions, and only push 4 arguments instead of 5, hence the garbage
    values. However, if it was pushed in reverse order, then that would not
    explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.
    No, everything is passed on the stack. It's not PUSHed but MOVed to the
    argument slots. If you only reserved 4 slots and gave makemap 5 arguments,
    that would clobber some local variable which could lead to arbitrarily bad
    behavior. Make sure runtime.go/mkbuiltin
    <https://goto.google.com/mkbuiltin>.go are done correctly. Also check
    the generated assembly at a makemap call to see if it seems reasonable.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would be
    appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).

    --
    You received this message because you are subscribed to the Google
    Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-dev+...@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Josh Bleecher Snyder at Jun 7, 2016 at 9:10 pm

    Yes, you must do that manually. It's sort of a historical accident that we
    do it this way, as mkbuiltin.go used to be a shell script and we didn't want
    to have the build dependent on shell programs. We could change it now that
    it is in Go and we depend on a bootstrap go implementation anyway.
    I believe this is https://github.com/golang/go/issues/15839.

    -josh

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Jun 7, 2016 at 9:13 pm

    On Tue, Jun 7, 2016 at 1:46 PM, Kyle Stanly wrote:

    runtime.go never mentioned needing to explicitly run mkbuiltin.go, I
    simply ran go generate, which explains why I messed up.
    Either works. Because of the

         //go:generate go run mkbuiltin.go

    comment in src/cmd/compile/internal/gc/main.go, running "go generate" there
    will in turn run "go run mkbuiltin.go".

    Am I supposed to explicitly run `go run
    cmd/compile/internal/gc/mkbuiltin.go'? I figured it'd be invoked
    automatically when I ran all.bat
    Yes, you need to explicitly regenerate gc/builtin.go (either via "go
    generate" or running "go run mkbuiltin.go").

    It's not done automatically by all.bat because it depends on having an
    up-to-date compiler.

    The absence of makemap is what I'm confused about. I figured that it didn't
    invoke makemap because debug is passed another value than 0, the value I
    explicitly pass to mkcall1, seen below...
    Sorry, I don't know what's going wrong for you. The steps I described
    earlier work for me: https://go-review.googlesource.com/#/c/23862/

    $ cat /tmp/kyle.go
    package main

    func main() {
    println("a")
    _ = make(map[int]int)
    println("b")
    _ = make(map[int]int)
    }

    $ go run /tmp/kyle.go
    a
    debug = 42
    b
    debug = 42

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Stanly at Jun 7, 2016 at 9:29 pm
    Alright guys, I'm setting up Gerrit now so I can upload a CL (Change
    Log???) through Cygwin, so I'll reply again with the commits I made. I'll
    also make sure to run mkbuiltin.go and report back for results.
    On Tuesday, June 7, 2016 at 4:05:13 PM UTC-4, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add a
    new argument to makemap, so I can add a specific flag for whether or not I
    want debugging. For example, if it is enabled, I want it to print the value
    of each argument, the entrance and exit of certain functions, the callers
    up to what is relevant (I.E, up to main()), etc. This is so I can add
    changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully, however
    if I pass as a flag to the new argument to debug, I expect to see debug
    information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.

    The stack trace is as follows... note debug shows an integer, I converted
    the bool to an uintptr to see if it happened to be an address and not
    garbage value. Its not entire garbage, because the value is consistent each
    time I run it, so its probably the value from something else. I'm assuming
    the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857
    +0x195 fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553
    +0x3a4 fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410 +0x50
    fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059
    +0x1 fp=0xc042037f98 sp=0xc042037f90


    Removing the extra parameter causes it to run just fine. Even if I could
    (which I am thinking of doing) marking the Most Significant Bit of hint,
    since it only uses the first 32-bits, for flags, I need to know how Go
    handles passing it's parameters and why its so sensitive to minimal changes
    like this.

    Also, I'll assume that it did NOT go through make(...) because OMAKEMAP
    explicitly sets debug to 0 for now, unconditionally, so it's being created
    in some other manner. I was thinking, after doing some digging, that it
    makes some specific assumptions in the assembly implementation of some go
    functions, and only push 4 arguments instead of 5, hence the garbage
    values. However, if it was pushed in reverse order, then that would not
    explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would be
    appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Jun 7, 2016 at 9:39 pm
    Technically CL is short for "change list". It's a terminology holdover
    from Google's internal use of Perforce.
    On Tue, Jun 7, 2016 at 2:29 PM, Kyle Stanly wrote:

    Alright guys, I'm setting up Gerrit now so I can upload a CL (Change
    Log???) through Cygwin, so I'll reply again with the commits I made. I'll
    also make sure to run mkbuiltin.go and report back for results.

    On Tuesday, June 7, 2016 at 4:05:13 PM UTC-4, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add a
    new argument to makemap, so I can add a specific flag for whether or not I
    want debugging. For example, if it is enabled, I want it to print the value
    of each argument, the entrance and exit of certain functions, the callers
    up to what is relevant (I.E, up to main()), etc. This is so I can add
    changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully, however
    if I pass as a flag to the new argument to debug, I expect to see debug
    information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.

    The stack trace is as follows... note debug shows an integer, I converted
    the bool to an uintptr to see if it happened to be an address and not
    garbage value. Its not entire garbage, because the value is consistent each
    time I run it, so its probably the value from something else. I'm assuming
    the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857
    +0x195 fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553
    +0x3a4 fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410 +0x50
    fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()

    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059 +0x1
    fp=0xc042037f98 sp=0xc042037f90


    Removing the extra parameter causes it to run just fine. Even if I could
    (which I am thinking of doing) marking the Most Significant Bit of hint,
    since it only uses the first 32-bits, for flags, I need to know how Go
    handles passing it's parameters and why its so sensitive to minimal changes
    like this.

    Also, I'll assume that it did NOT go through make(...) because OMAKEMAP
    explicitly sets debug to 0 for now, unconditionally, so it's being created
    in some other manner. I was thinking, after doing some digging, that it
    makes some specific assumptions in the assembly implementation of some go
    functions, and only push 4 arguments instead of 5, hence the garbage
    values. However, if it was pushed in reverse order, then that would not
    explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would be
    appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).
    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Stanly at Jun 7, 2016 at 9:48 pm
    Okay, so I tried installing git-codereview, but unfortunately there's an
    issue where it attempts to open commit-msg using the cygwin path, but it
    seems that it doesn't recognize it. I.E, it uses /cygdrive/c/* instead of
    C:, so I tried git-review instead (installed directly through cygwin
    package manager), but unfortunately that doesn't seem to work because there
    is no .gitreview file? Anyway I'll sort it out tonight, but for now, I have
    the git diff instead...

    diff --git a/src/cmd/compile/internal/gc/builtin/runtime.go
    b/src/cmd/compile/internal/gc/builtin/runtime.go
    index e9316cb..cc5cdd3 100644
    --- a/src/cmd/compile/internal/gc/builtin/runtime.go
    +++ b/src/cmd/compile/internal/gc/builtin/runtime.go
    @@ -84,7 +84,7 @@ func ifaceeq(i1 any, i2 any) (ret bool)
      func efaceeq(i1 any, i2 any) (ret bool)

      // *byte is really *runtime.Type
    -func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any) (hmap
    map[any]any)
    +func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any, debug
    uintptr) (hmap map[any]any)
      func mapaccess1(mapType *byte, hmap map[any]any, key *any) (val *any)
      func mapaccess1_fast32(mapType *byte, hmap map[any]any, key any) (val *any)
      func mapaccess1_fast64(mapType *byte, hmap map[any]any, key any) (val *any)
    diff --git a/src/cmd/compile/internal/gc/typecheck.go
    b/src/cmd/compile/internal/gc/typecheck.go
    index c8ee941..b19f1b2 100644
    --- a/src/cmd/compile/internal/gc/typecheck.go
    +++ b/src/cmd/compile/internal/gc/typecheck.go
    @@ -1790,6 +1790,25 @@ OpSwitch:
                             } else {
                                     n.Left = Nodintconst(0)
                             }
    +
    + // L.J: Code added for 3rd parameter, 'mode'
    + if i < len(args) {
    + right := args[i]
    + i++
    + right = typecheck(right, Erv)
    + right = defaultlit(right, Types[TINT])
    + if right.Type == nil {
    + n.Type = nil
    + return n
    + }
    + if !checkmake(t, "mode", right) {
    + n.Type = nil
    + return n
    + }
    + n.Right = right
    + } else {
    + n.Right = Nodintconst(0)
    + }
                             n.Op = OMAKEMAP

                     case TCHAN:
    diff --git a/src/cmd/compile/internal/gc/walk.go
    b/src/cmd/compile/internal/gc/walk.go
    index 66eb7e9..71a8a4a 100644
    --- a/src/cmd/compile/internal/gc/walk.go
    +++ b/src/cmd/compile/internal/gc/walk.go
    @@ -1414,9 +1414,16 @@ opswitch:
                             r = Nod(OADDR, var_, nil)
                     }

    + // debug := false
    +
    + // // L.J: Only change in code
    + // if n.Right != nil && n.Right.Int64() != 0 {
    + // debug = true
    + // }
    +
                     fn := syslook("makemap")
                     fn = substArgTypes(fn, hmap(t), mapbucket(t), t.Key(),
    t.Val())
    - n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r)
    + n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r, conv(Nodintconst(0), Types[TUINTPTR]))

             case OMAKESLICE:
                     l := n.Left

    diff --git a/src/runtime/hashmap.go b/src/runtime/hashmap.go
    index 509cab2..a55a91d 100644
    --- a/src/runtime/hashmap.go
    +++ b/src/runtime/hashmap.go


    @@ -96,6 +96,7 @@ const (
             iterator = 1 // there may be an iterator using buckets
             oldIterator = 2 // there may be an iterator using oldbuckets
             hashWriting = 4 // a goroutine is writing to the map
    + logEntrance = 8 // L.J: Inserted to log entrances in the function


    @@ -187,7 +188,8 @@ func (h *hmap) createOverflow() {
      // 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 bucket != nil, bucket can be used as the first bucket.
    -func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer) *hmap
    {
    +func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer, debug
    uintptr) *hmap {
    + println("t: ", t, ";hint: ", hint, ";h: ", h, ";bucket: ", bucket,
    ";debug: ", debug)
             if sz := unsafe.Sizeof(hmap{}); sz > 48 || sz != t.hmap.size {
                     println("runtime: sizeof(hmap) =", sz, ", t.hmap.size =",
    t.hmap.size)
                     throw("bad hmap size")

      @@ -261,6 +263,11 @@ func makemap(t *maptype, hint int64, h *hmap, bucket
    unsafe.Pointer) *hmap {
             h.oldbuckets = nil
             h.nevacuate = 0

    + // L.J: Our inserted code.
    + if debug != 0 {
    + h.flags = logEntrance
    + }
    +
             return h
      }



      //go:linkname reflect_makemap reflect.makemap
      func reflect_makemap(t *maptype) *hmap {
    - return makemap(t, 0, nil, nil)
    + return makemap(t, 0, nil, nil, 0)
      }


    Sorry if it's ugly looking, best I can do, I have to head home now so I
    gotta leave soon but tonight I'll try to get it working once I get home.
    On Tuesday, June 7, 2016 at 5:39:17 PM UTC-4, Matthew Dempsky wrote:

    Technically CL is short for "change list". It's a terminology holdover
    from Google's internal use of Perforce.

    On Tue, Jun 7, 2016 at 2:29 PM, Kyle Stanly <thei...@gmail.com
    <javascript:>> wrote:
    Alright guys, I'm setting up Gerrit now so I can upload a CL (Change
    Log???) through Cygwin, so I'll reply again with the commits I made. I'll
    also make sure to run mkbuiltin.go and report back for results.

    On Tuesday, June 7, 2016 at 4:05:13 PM UTC-4, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add a
    new argument to makemap, so I can add a specific flag for whether or not I
    want debugging. For example, if it is enabled, I want it to print the value
    of each argument, the entrance and exit of certain functions, the callers
    up to what is relevant (I.E, up to main()), etc. This is so I can add
    changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully, however
    if I pass as a flag to the new argument to debug, I expect to see debug
    information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.

    The stack trace is as follows... note debug shows an integer, I
    converted the bool to an uintptr to see if it happened to be an address and
    not garbage value. Its not entire garbage, because the value is consistent
    each time I run it, so its probably the value from something else. I'm
    assuming the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857
    +0x195 fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553
    +0x3a4 fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410
    +0x50 fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()

    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059 +0x1
    fp=0xc042037f98 sp=0xc042037f90


    Removing the extra parameter causes it to run just fine. Even if I could
    (which I am thinking of doing) marking the Most Significant Bit of hint,
    since it only uses the first 32-bits, for flags, I need to know how Go
    handles passing it's parameters and why its so sensitive to minimal changes
    like this.

    Also, I'll assume that it did NOT go through make(...) because OMAKEMAP
    explicitly sets debug to 0 for now, unconditionally, so it's being created
    in some other manner. I was thinking, after doing some digging, that it
    makes some specific assumptions in the assembly implementation of some go
    functions, and only push 4 arguments instead of 5, hence the garbage
    values. However, if it was pushed in reverse order, then that would not
    explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would be
    appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).
    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Jun 7, 2016 at 9:50 pm
    You haven't regenerated src/cmd/compile/internal/gc/builtin.go.
    On Tue, Jun 7, 2016 at 2:48 PM, Kyle Stanly wrote:

    Okay, so I tried installing git-codereview, but unfortunately there's an
    issue where it attempts to open commit-msg using the cygwin path, but it
    seems that it doesn't recognize it. I.E, it uses /cygdrive/c/* instead of
    C:, so I tried git-review instead (installed directly through cygwin
    package manager), but unfortunately that doesn't seem to work because there
    is no .gitreview file? Anyway I'll sort it out tonight, but for now, I have
    the git diff instead...

    diff --git a/src/cmd/compile/internal/gc/builtin/runtime.go
    b/src/cmd/compile/internal/gc/builtin/runtime.go
    index e9316cb..cc5cdd3 100644
    --- a/src/cmd/compile/internal/gc/builtin/runtime.go
    +++ b/src/cmd/compile/internal/gc/builtin/runtime.go
    @@ -84,7 +84,7 @@ func ifaceeq(i1 any, i2 any) (ret bool)
    func efaceeq(i1 any, i2 any) (ret bool)

    // *byte is really *runtime.Type
    -func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any)
    (hmap map[any]any)
    +func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any,
    debug uintptr) (hmap map[any]any)
    func mapaccess1(mapType *byte, hmap map[any]any, key *any) (val *any)
    func mapaccess1_fast32(mapType *byte, hmap map[any]any, key any) (val
    *any)
    func mapaccess1_fast64(mapType *byte, hmap map[any]any, key any) (val
    *any)
    diff --git a/src/cmd/compile/internal/gc/typecheck.go
    b/src/cmd/compile/internal/gc/typecheck.go
    index c8ee941..b19f1b2 100644
    --- a/src/cmd/compile/internal/gc/typecheck.go
    +++ b/src/cmd/compile/internal/gc/typecheck.go
    @@ -1790,6 +1790,25 @@ OpSwitch:
    } else {
    n.Left = Nodintconst(0)
    }
    +
    + // L.J: Code added for 3rd parameter, 'mode'
    + if i < len(args) {
    + right := args[i]
    + i++
    + right = typecheck(right, Erv)
    + right = defaultlit(right, Types[TINT])
    + if right.Type == nil {
    + n.Type = nil
    + return n
    + }
    + if !checkmake(t, "mode", right) {
    + n.Type = nil
    + return n
    + }
    + n.Right = right
    + } else {
    + n.Right = Nodintconst(0)
    + }
    n.Op = OMAKEMAP

    case TCHAN:
    diff --git a/src/cmd/compile/internal/gc/walk.go
    b/src/cmd/compile/internal/gc/walk.go
    index 66eb7e9..71a8a4a 100644
    --- a/src/cmd/compile/internal/gc/walk.go
    +++ b/src/cmd/compile/internal/gc/walk.go
    @@ -1414,9 +1414,16 @@ opswitch:
    r = Nod(OADDR, var_, nil)
    }

    + // debug := false
    +
    + // // L.J: Only change in code
    + // if n.Right != nil && n.Right.Int64() != 0 {
    + // debug = true
    + // }
    +
    fn := syslook("makemap")
    fn = substArgTypes(fn, hmap(t), mapbucket(t), t.Key(),
    t.Val())
    - n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r)
    + n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r, conv(Nodintconst(0), Types[TUINTPTR]))

    case OMAKESLICE:
    l := n.Left

    diff --git a/src/runtime/hashmap.go b/src/runtime/hashmap.go
    index 509cab2..a55a91d 100644
    --- a/src/runtime/hashmap.go
    +++ b/src/runtime/hashmap.go


    @@ -96,6 +96,7 @@ const (
    iterator = 1 // there may be an iterator using buckets
    oldIterator = 2 // there may be an iterator using oldbuckets
    hashWriting = 4 // a goroutine is writing to the map
    + logEntrance = 8 // L.J: Inserted to log entrances in the function


    @@ -187,7 +188,8 @@ func (h *hmap) createOverflow() {
    // 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 bucket != nil, bucket can be used as the first bucket.
    -func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer)
    *hmap {
    +func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug uintptr) *hmap {
    + println("t: ", t, ";hint: ", hint, ";h: ", h, ";bucket: ", bucket,
    ";debug: ", debug)
    if sz := unsafe.Sizeof(hmap{}); sz > 48 || sz != t.hmap.size {
    println("runtime: sizeof(hmap) =", sz, ", t.hmap.size =",
    t.hmap.size)
    throw("bad hmap size")

    @@ -261,6 +263,11 @@ func makemap(t *maptype, hint int64, h *hmap, bucket
    unsafe.Pointer) *hmap {
    h.oldbuckets = nil
    h.nevacuate = 0

    + // L.J: Our inserted code.
    + if debug != 0 {
    + h.flags = logEntrance
    + }
    +
    return h
    }



    //go:linkname reflect_makemap reflect.makemap
    func reflect_makemap(t *maptype) *hmap {
    - return makemap(t, 0, nil, nil)
    + return makemap(t, 0, nil, nil, 0)
    }


    Sorry if it's ugly looking, best I can do, I have to head home now so I
    gotta leave soon but tonight I'll try to get it working once I get home.
    On Tuesday, June 7, 2016 at 5:39:17 PM UTC-4, Matthew Dempsky wrote:

    Technically CL is short for "change list". It's a terminology holdover
    from Google's internal use of Perforce.
    On Tue, Jun 7, 2016 at 2:29 PM, Kyle Stanly wrote:

    Alright guys, I'm setting up Gerrit now so I can upload a CL (Change
    Log???) through Cygwin, so I'll reply again with the commits I made. I'll
    also make sure to run mkbuiltin.go and report back for results.

    On Tuesday, June 7, 2016 at 4:05:13 PM UTC-4, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add a
    new argument to makemap, so I can add a specific flag for whether or not I
    want debugging. For example, if it is enabled, I want it to print the value
    of each argument, the entrance and exit of certain functions, the callers
    up to what is relevant (I.E, up to main()), etc. This is so I can add
    changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully,
    however if I pass as a flag to the new argument to debug, I expect to see
    debug information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.

    The stack trace is as follows... note debug shows an integer, I
    converted the bool to an uintptr to see if it happened to be an address and
    not garbage value. Its not entire garbage, because the value is consistent
    each time I run it, so its probably the value from something else. I'm
    assuming the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857 +0x195
    fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553 +0x3a4
    fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410
    +0x50 fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()

    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059 +0x1
    fp=0xc042037f98 sp=0xc042037f90


    Removing the extra parameter causes it to run just fine. Even if I
    could (which I am thinking of doing) marking the Most Significant Bit of
    hint, since it only uses the first 32-bits, for flags, I need to know how
    Go handles passing it's parameters and why its so sensitive to minimal
    changes like this.

    Also, I'll assume that it did NOT go through make(...) because OMAKEMAP
    explicitly sets debug to 0 for now, unconditionally, so it's being created
    in some other manner. I was thinking, after doing some digging, that it
    makes some specific assumptions in the assembly implementation of some go
    functions, and only push 4 arguments instead of 5, hence the garbage
    values. However, if it was pushed in reverse order, then that would not
    explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would
    be appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).
    --
    You received this message because you are subscribed to the Google
    Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-dev+...@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Stanly at Jun 8, 2016 at 12:07 am
    There doesn't seem to be any error message for this crash, but I get an
    exit status of 1 when I run mkbuiltin.go. No actual error message, just an
    exit status of non-1.

    Thing is, I managed to get it to work before, but I wanted to change the
    argument type for debug from uintptr to bool, but then I got a problem
    where it attempted to use the modified hashmap.go which used 'false'
    instead of '0', which triggered compiler errors, and switching it back to
    '0' gave errors about how I can't go from 'bool' to 'uintptr', etc. So I
    ended up doing a hard reset, ran 'all.bat', ran some test files, worked
    fine. Then I attempted to make the same changes, verbatim, that I did
    before and now I get an exit status issue. Once again, no error, just an
    exit status

    Now, attempts to run 'all.bat' give me the same error as before,
    'evacuation not done in time' because I can't run mkbuiltin.go since it
    fails (also it complains about lacking a 'zversion.go'. Sorry if this is
    all over the place, I'm exhausted. I've repeatedly done a 'git reset
    --hard', and then tried my changes again, same errors. For one, how do I
    get 'zversion.go'? For Go 1.6.2, it seems to be a generated file which
    shows it's default Go root, and the version of Go. I doubt I can copy and
    paste this over, so I'm stuck.
    On Tuesday, June 7, 2016 at 5:50:56 PM UTC-4, Matthew Dempsky wrote:

    You haven't regenerated src/cmd/compile/internal/gc/builtin.go.

    On Tue, Jun 7, 2016 at 2:48 PM, Kyle Stanly <thei...@gmail.com
    <javascript:>> wrote:
    Okay, so I tried installing git-codereview, but unfortunately there's an
    issue where it attempts to open commit-msg using the cygwin path, but it
    seems that it doesn't recognize it. I.E, it uses /cygdrive/c/* instead of
    C:, so I tried git-review instead (installed directly through cygwin
    package manager), but unfortunately that doesn't seem to work because there
    is no .gitreview file? Anyway I'll sort it out tonight, but for now, I have
    the git diff instead...

    diff --git a/src/cmd/compile/internal/gc/builtin/runtime.go
    b/src/cmd/compile/internal/gc/builtin/runtime.go
    index e9316cb..cc5cdd3 100644
    --- a/src/cmd/compile/internal/gc/builtin/runtime.go
    +++ b/src/cmd/compile/internal/gc/builtin/runtime.go
    @@ -84,7 +84,7 @@ func ifaceeq(i1 any, i2 any) (ret bool)
    func efaceeq(i1 any, i2 any) (ret bool)

    // *byte is really *runtime.Type
    -func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any)
    (hmap map[any]any)
    +func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any,
    debug uintptr) (hmap map[any]any)
    func mapaccess1(mapType *byte, hmap map[any]any, key *any) (val *any)
    func mapaccess1_fast32(mapType *byte, hmap map[any]any, key any) (val
    *any)
    func mapaccess1_fast64(mapType *byte, hmap map[any]any, key any) (val
    *any)
    diff --git a/src/cmd/compile/internal/gc/typecheck.go
    b/src/cmd/compile/internal/gc/typecheck.go
    index c8ee941..b19f1b2 100644
    --- a/src/cmd/compile/internal/gc/typecheck.go
    +++ b/src/cmd/compile/internal/gc/typecheck.go
    @@ -1790,6 +1790,25 @@ OpSwitch:
    } else {
    n.Left = Nodintconst(0)
    }
    +
    + // L.J: Code added for 3rd parameter, 'mode'
    + if i < len(args) {
    + right := args[i]
    + i++
    + right = typecheck(right, Erv)
    + right = defaultlit(right, Types[TINT])
    + if right.Type == nil {
    + n.Type = nil
    + return n
    + }
    + if !checkmake(t, "mode", right) {
    + n.Type = nil
    + return n
    + }
    + n.Right = right
    + } else {
    + n.Right = Nodintconst(0)
    + }
    n.Op = OMAKEMAP

    case TCHAN:
    diff --git a/src/cmd/compile/internal/gc/walk.go
    b/src/cmd/compile/internal/gc/walk.go
    index 66eb7e9..71a8a4a 100644
    --- a/src/cmd/compile/internal/gc/walk.go
    +++ b/src/cmd/compile/internal/gc/walk.go
    @@ -1414,9 +1414,16 @@ opswitch:
    r = Nod(OADDR, var_, nil)
    }

    + // debug := false
    +
    + // // L.J: Only change in code
    + // if n.Right != nil && n.Right.Int64() != 0 {
    + // debug = true
    + // }
    +
    fn := syslook("makemap")
    fn = substArgTypes(fn, hmap(t), mapbucket(t), t.Key(),
    t.Val())
    - n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r)
    + n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r, conv(Nodintconst(0), Types[TUINTPTR]))

    case OMAKESLICE:
    l := n.Left

    diff --git a/src/runtime/hashmap.go b/src/runtime/hashmap.go
    index 509cab2..a55a91d 100644
    --- a/src/runtime/hashmap.go
    +++ b/src/runtime/hashmap.go


    @@ -96,6 +96,7 @@ const (
    iterator = 1 // there may be an iterator using buckets
    oldIterator = 2 // there may be an iterator using oldbuckets
    hashWriting = 4 // a goroutine is writing to the map
    + logEntrance = 8 // L.J: Inserted to log entrances in the function


    @@ -187,7 +188,8 @@ func (h *hmap) createOverflow() {
    // 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 bucket != nil, bucket can be used as the first bucket.
    -func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer)
    *hmap {
    +func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug uintptr) *hmap {
    + println("t: ", t, ";hint: ", hint, ";h: ", h, ";bucket: ",
    bucket, ";debug: ", debug)
    if sz := unsafe.Sizeof(hmap{}); sz > 48 || sz != t.hmap.size {
    println("runtime: sizeof(hmap) =", sz, ", t.hmap.size =",
    t.hmap.size)
    throw("bad hmap size")

    @@ -261,6 +263,11 @@ func makemap(t *maptype, hint int64, h *hmap,
    bucket unsafe.Pointer) *hmap {
    h.oldbuckets = nil
    h.nevacuate = 0

    + // L.J: Our inserted code.
    + if debug != 0 {
    + h.flags = logEntrance
    + }
    +
    return h
    }



    //go:linkname reflect_makemap reflect.makemap
    func reflect_makemap(t *maptype) *hmap {
    - return makemap(t, 0, nil, nil)
    + return makemap(t, 0, nil, nil, 0)
    }


    Sorry if it's ugly looking, best I can do, I have to head home now so I
    gotta leave soon but tonight I'll try to get it working once I get home.
    On Tuesday, June 7, 2016 at 5:39:17 PM UTC-4, Matthew Dempsky wrote:

    Technically CL is short for "change list". It's a terminology holdover
    from Google's internal use of Perforce.
    On Tue, Jun 7, 2016 at 2:29 PM, Kyle Stanly wrote:

    Alright guys, I'm setting up Gerrit now so I can upload a CL (Change
    Log???) through Cygwin, so I'll reply again with the commits I made. I'll
    also make sure to run mkbuiltin.go and report back for results.

    On Tuesday, June 7, 2016 at 4:05:13 PM UTC-4, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add
    a new argument to makemap, so I can add a specific flag for whether or not
    I want debugging. For example, if it is enabled, I want it to print the
    value of each argument, the entrance and exit of certain functions, the
    callers up to what is relevant (I.E, up to main()), etc. This is so I can
    add changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully,
    however if I pass as a flag to the new argument to debug, I expect to see
    debug information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.

    The stack trace is as follows... note debug shows an integer, I
    converted the bool to an uintptr to see if it happened to be an address and
    not garbage value. Its not entire garbage, because the value is consistent
    each time I run it, so its probably the value from something else. I'm
    assuming the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857 +0x195
    fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553 +0x3a4
    fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410
    +0x50 fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()

    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059 +0x1
    fp=0xc042037f98 sp=0xc042037f90


    Removing the extra parameter causes it to run just fine. Even if I
    could (which I am thinking of doing) marking the Most Significant Bit of
    hint, since it only uses the first 32-bits, for flags, I need to know how
    Go handles passing it's parameters and why its so sensitive to minimal
    changes like this.

    Also, I'll assume that it did NOT go through make(...) because
    OMAKEMAP explicitly sets debug to 0 for now, unconditionally, so it's being
    created in some other manner. I was thinking, after doing some digging,
    that it makes some specific assumptions in the assembly implementation of
    some go functions, and only push 4 arguments instead of 5, hence the
    garbage values. However, if it was pushed in reverse order, then that would
    not explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would
    be appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).
    --
    You received this message because you are subscribed to the Google
    Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-dev+...@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Josh Bleecher Snyder at Jun 8, 2016 at 12:10 am

    There doesn't seem to be any error message for this crash, but I get an exit
    status of 1 when I run mkbuiltin.go. No actual error message, just an exit
    status of non-1.
    Yes, I bumped into this myself recently. CLs improving the failure
    mode would be welcome (although they won't go in until the freeze
    ends). It's a pretty simple tool, so the work involved in making it
    friendlier should be too onerous, and given that it is giving you
    trouble, time spent understanding and improving it is probably
    well-spent.

    -josh

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Jun 8, 2016 at 12:45 am

    On Tue, Jun 7, 2016 at 5:06 PM, Kyle Stanly wrote:
    There doesn't seem to be any error message for this crash, but I get an
    exit status of 1 when I run mkbuiltin.go. No actual error message, just an
    exit status of non-1.
    Try running "go tool compile -A builtin/runtime.go" to see why the compile
    is failing.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Stanly at Jun 8, 2016 at 4:15 am
    While there is no issue compiling
    'cmd/compile/internal/gc/builtin/runtime.go', it does show the issues which
    appear during 'cmd/compile/internal/gc/mkbuiltin.go', which are strange
    ones...

    cmd/compile/internal/gc/mkbuiltin.go:30: internal compiler error: syslook:
    can't find runtime.newobject


    goroutine 1 [running]:
    runtime/debug.Stack(0x0, 0x0, 0x0)
             C:/Users/theif519/Documents/GitHub/go/src/runtime/debug/stack.go:24
    +0x87
    bootstrap/compile/internal/gc.Fatalf(0xa43080, 0x1e, 0xc08206f460, 0x1, 0x1)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/subr.go:165
    +0x27d
    bootstrap/compile/internal/gc.syslook(0x9fc3d0, 0x9, 0x0)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/subr.go:1123
    +0x144
    bootstrap/compile/internal/gc.callnew(0xc082384870, 0xc082040630)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/walk.go:2038
    +0x4b
    bootstrap/compile/internal/gc.walkstmt(0xc0827f4360, 0xc0827f4240)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/walk.go:232
    +0x8a6
    bootstrap/compile/internal/gc.walkstmtlist(0xc082806700, 0x1c, 0x20)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/walk.go:80
    +0x5d
    bootstrap/compile/internal/gc.walk(0xc0827f4000)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/walk.go:65
    +0x377
    bootstrap/compile/internal/gc.compile(0xc0827f4000)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/pgen.go:391
    +0x85b
    bootstrap/compile/internal/gc.funccompile(0xc0827f4000)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/dcl.go:1287
    +0x1c1
    bootstrap/compile/internal/gc.Main()

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/main.go:467
    +0x20e3
    bootstrap/compile/internal/amd64.Main()

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/amd64/galign.go:93
    +0x510
    main.main()
             C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/main.go:33
    +0x39c

    I've skimmed through everything, as just as it says, it fails on
    syslook("newobject"), probably because it failed to generate the runtime
    package (mind you I did explicitly call 'go tool compile -A
    cmd/compile/internal/gc/builtin/runtime.go') and panics. Also, once , this
    is to a call to... make the built-in types and runtime. So, kind of in a
    loop here.

    Also, since I needed to make this experimental Go version as my GOROOT and
    GOPATH, it broke golinter, godocs, etc. So it is REALLY difficult to debug
    this.
    On Tuesday, June 7, 2016 at 8:45:29 PM UTC-4, Matthew Dempsky wrote:

    On Tue, Jun 7, 2016 at 5:06 PM, Kyle Stanly <thei...@gmail.com
    <javascript:>> wrote:
    There doesn't seem to be any error message for this crash, but I get an
    exit status of 1 when I run mkbuiltin.go. No actual error message, just an
    exit status of non-1.
    Try running "go tool compile -A builtin/runtime.go" to see why the compile
    is failing.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Stanly at Jun 8, 2016 at 4:28 am
    Does anyone know if I can make a basic makefile instead of all of this
    silliness using the '.bat' files? I seriously would benefit from having it
    automatically save the old GOPATH and GOROOT, export new ones, attempt to
    build, and regardless if it fails or succeeds, switch back to the old
    GOPATH and GOROOT. Also, it will save me the time of having to re-compile
    everything all over again. I'm assuming theres a reason there isn't just a
    centric makefile to begin with.
    On Wednesday, June 8, 2016 at 12:15:45 AM UTC-4, Kyle Stanly wrote:

    While there is no issue compiling
    'cmd/compile/internal/gc/builtin/runtime.go', it does show the issues which
    appear during 'cmd/compile/internal/gc/mkbuiltin.go', which are strange
    ones...

    cmd/compile/internal/gc/mkbuiltin.go:30: internal compiler error: syslook:
    can't find runtime.newobject


    goroutine 1 [running]:
    runtime/debug.Stack(0x0, 0x0, 0x0)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/debug/stack.go:24 +0x87
    bootstrap/compile/internal/gc.Fatalf(0xa43080, 0x1e, 0xc08206f460, 0x1,
    0x1)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/subr.go:165
    +0x27d
    bootstrap/compile/internal/gc.syslook(0x9fc3d0, 0x9, 0x0)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/subr.go:1123
    +0x144
    bootstrap/compile/internal/gc.callnew(0xc082384870, 0xc082040630)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/walk.go:2038
    +0x4b
    bootstrap/compile/internal/gc.walkstmt(0xc0827f4360, 0xc0827f4240)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/walk.go:232
    +0x8a6
    bootstrap/compile/internal/gc.walkstmtlist(0xc082806700, 0x1c, 0x20)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/walk.go:80
    +0x5d
    bootstrap/compile/internal/gc.walk(0xc0827f4000)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/walk.go:65
    +0x377
    bootstrap/compile/internal/gc.compile(0xc0827f4000)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/pgen.go:391
    +0x85b
    bootstrap/compile/internal/gc.funccompile(0xc0827f4000)

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/dcl.go:1287
    +0x1c1
    bootstrap/compile/internal/gc.Main()

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/gc/main.go:467
    +0x20e3
    bootstrap/compile/internal/amd64.Main()

    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/internal/amd64/galign.go:93
    +0x510
    main.main()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/compile/main.go:33
    +0x39c

    I've skimmed through everything, as just as it says, it fails on
    syslook("newobject"), probably because it failed to generate the runtime
    package (mind you I did explicitly call 'go tool compile -A
    cmd/compile/internal/gc/builtin/runtime.go') and panics. Also, once , this
    is to a call to... make the built-in types and runtime. So, kind of in a
    loop here.

    Also, since I needed to make this experimental Go version as my GOROOT and
    GOPATH, it broke golinter, godocs, etc. So it is REALLY difficult to debug
    this.
    On Tuesday, June 7, 2016 at 8:45:29 PM UTC-4, Matthew Dempsky wrote:
    On Tue, Jun 7, 2016 at 5:06 PM, Kyle Stanly wrote:

    There doesn't seem to be any error message for this crash, but I get an
    exit status of 1 when I run mkbuiltin.go. No actual error message, just an
    exit status of non-1.
    Try running "go tool compile -A builtin/runtime.go" to see why the
    compile is failing.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brainman at Jun 8, 2016 at 7:08 am
    I'm assuming theres a reason there isn't just a centric makefile to begin
    with

    The reason we don't use makefile is because Windows does not have tools to
    handle it.

    Alex

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Stanly at Jun 8, 2016 at 1:45 pm
    Alright... I don't know if I should be relieved or generally peeved...
    apparently was the fact that I ran `go generate` and `go run` from the root
    of the src directory. Apparently you actually HAVE to be in the
    cmd/compile/internal/gc folder, and it gave no inclination as to why it
    failed to begin with. Definitely think it should let you know in advance
    though. At least now I finally got it to work.
    On Tuesday, June 7, 2016 at 5:50:56 PM UTC-4, Matthew Dempsky wrote:

    You haven't regenerated src/cmd/compile/internal/gc/builtin.go.

    On Tue, Jun 7, 2016 at 2:48 PM, Kyle Stanly <thei...@gmail.com
    <javascript:>> wrote:
    Okay, so I tried installing git-codereview, but unfortunately there's an
    issue where it attempts to open commit-msg using the cygwin path, but it
    seems that it doesn't recognize it. I.E, it uses /cygdrive/c/* instead of
    C:, so I tried git-review instead (installed directly through cygwin
    package manager), but unfortunately that doesn't seem to work because there
    is no .gitreview file? Anyway I'll sort it out tonight, but for now, I have
    the git diff instead...

    diff --git a/src/cmd/compile/internal/gc/builtin/runtime.go
    b/src/cmd/compile/internal/gc/builtin/runtime.go
    index e9316cb..cc5cdd3 100644
    --- a/src/cmd/compile/internal/gc/builtin/runtime.go
    +++ b/src/cmd/compile/internal/gc/builtin/runtime.go
    @@ -84,7 +84,7 @@ func ifaceeq(i1 any, i2 any) (ret bool)
    func efaceeq(i1 any, i2 any) (ret bool)

    // *byte is really *runtime.Type
    -func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any)
    (hmap map[any]any)
    +func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any,
    debug uintptr) (hmap map[any]any)
    func mapaccess1(mapType *byte, hmap map[any]any, key *any) (val *any)
    func mapaccess1_fast32(mapType *byte, hmap map[any]any, key any) (val
    *any)
    func mapaccess1_fast64(mapType *byte, hmap map[any]any, key any) (val
    *any)
    diff --git a/src/cmd/compile/internal/gc/typecheck.go
    b/src/cmd/compile/internal/gc/typecheck.go
    index c8ee941..b19f1b2 100644
    --- a/src/cmd/compile/internal/gc/typecheck.go
    +++ b/src/cmd/compile/internal/gc/typecheck.go
    @@ -1790,6 +1790,25 @@ OpSwitch:
    } else {
    n.Left = Nodintconst(0)
    }
    +
    + // L.J: Code added for 3rd parameter, 'mode'
    + if i < len(args) {
    + right := args[i]
    + i++
    + right = typecheck(right, Erv)
    + right = defaultlit(right, Types[TINT])
    + if right.Type == nil {
    + n.Type = nil
    + return n
    + }
    + if !checkmake(t, "mode", right) {
    + n.Type = nil
    + return n
    + }
    + n.Right = right
    + } else {
    + n.Right = Nodintconst(0)
    + }
    n.Op = OMAKEMAP

    case TCHAN:
    diff --git a/src/cmd/compile/internal/gc/walk.go
    b/src/cmd/compile/internal/gc/walk.go
    index 66eb7e9..71a8a4a 100644
    --- a/src/cmd/compile/internal/gc/walk.go
    +++ b/src/cmd/compile/internal/gc/walk.go
    @@ -1414,9 +1414,16 @@ opswitch:
    r = Nod(OADDR, var_, nil)
    }

    + // debug := false
    +
    + // // L.J: Only change in code
    + // if n.Right != nil && n.Right.Int64() != 0 {
    + // debug = true
    + // }
    +
    fn := syslook("makemap")
    fn = substArgTypes(fn, hmap(t), mapbucket(t), t.Key(),
    t.Val())
    - n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r)
    + n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r, conv(Nodintconst(0), Types[TUINTPTR]))

    case OMAKESLICE:
    l := n.Left

    diff --git a/src/runtime/hashmap.go b/src/runtime/hashmap.go
    index 509cab2..a55a91d 100644
    --- a/src/runtime/hashmap.go
    +++ b/src/runtime/hashmap.go


    @@ -96,6 +96,7 @@ const (
    iterator = 1 // there may be an iterator using buckets
    oldIterator = 2 // there may be an iterator using oldbuckets
    hashWriting = 4 // a goroutine is writing to the map
    + logEntrance = 8 // L.J: Inserted to log entrances in the function


    @@ -187,7 +188,8 @@ func (h *hmap) createOverflow() {
    // 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 bucket != nil, bucket can be used as the first bucket.
    -func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer)
    *hmap {
    +func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug uintptr) *hmap {
    + println("t: ", t, ";hint: ", hint, ";h: ", h, ";bucket: ",
    bucket, ";debug: ", debug)
    if sz := unsafe.Sizeof(hmap{}); sz > 48 || sz != t.hmap.size {
    println("runtime: sizeof(hmap) =", sz, ", t.hmap.size =",
    t.hmap.size)
    throw("bad hmap size")

    @@ -261,6 +263,11 @@ func makemap(t *maptype, hint int64, h *hmap,
    bucket unsafe.Pointer) *hmap {
    h.oldbuckets = nil
    h.nevacuate = 0

    + // L.J: Our inserted code.
    + if debug != 0 {
    + h.flags = logEntrance
    + }
    +
    return h
    }



    //go:linkname reflect_makemap reflect.makemap
    func reflect_makemap(t *maptype) *hmap {
    - return makemap(t, 0, nil, nil)
    + return makemap(t, 0, nil, nil, 0)
    }


    Sorry if it's ugly looking, best I can do, I have to head home now so I
    gotta leave soon but tonight I'll try to get it working once I get home.
    On Tuesday, June 7, 2016 at 5:39:17 PM UTC-4, Matthew Dempsky wrote:

    Technically CL is short for "change list". It's a terminology holdover
    from Google's internal use of Perforce.
    On Tue, Jun 7, 2016 at 2:29 PM, Kyle Stanly wrote:

    Alright guys, I'm setting up Gerrit now so I can upload a CL (Change
    Log???) through Cygwin, so I'll reply again with the commits I made. I'll
    also make sure to run mkbuiltin.go and report back for results.

    On Tuesday, June 7, 2016 at 4:05:13 PM UTC-4, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add
    a new argument to makemap, so I can add a specific flag for whether or not
    I want debugging. For example, if it is enabled, I want it to print the
    value of each argument, the entrance and exit of certain functions, the
    callers up to what is relevant (I.E, up to main()), etc. This is so I can
    add changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully,
    however if I pass as a flag to the new argument to debug, I expect to see
    debug information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.

    The stack trace is as follows... note debug shows an integer, I
    converted the bool to an uintptr to see if it happened to be an address and
    not garbage value. Its not entire garbage, because the value is consistent
    each time I run it, so its probably the value from something else. I'm
    assuming the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857 +0x195
    fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553 +0x3a4
    fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410
    +0x50 fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()

    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059 +0x1
    fp=0xc042037f98 sp=0xc042037f90


    Removing the extra parameter causes it to run just fine. Even if I
    could (which I am thinking of doing) marking the Most Significant Bit of
    hint, since it only uses the first 32-bits, for flags, I need to know how
    Go handles passing it's parameters and why its so sensitive to minimal
    changes like this.

    Also, I'll assume that it did NOT go through make(...) because
    OMAKEMAP explicitly sets debug to 0 for now, unconditionally, so it's being
    created in some other manner. I was thinking, after doing some digging,
    that it makes some specific assumptions in the assembly implementation of
    some go functions, and only push 4 arguments instead of 5, hence the
    garbage values. However, if it was pushed in reverse order, then that would
    not explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would
    be appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).
    --
    You received this message because you are subscribed to the Google
    Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-dev+...@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Jun 8, 2016 at 9:21 pm
    Sorry, I assumed you were already familiar with the "go generate" command
    and how to use it. It's a general mechanism for (re)generating source
    files. It's not specific to cmd/compile/internal/gc, which is why it needs
    to be run in that directory or as "go generate cmd/compile/internal/gc".
    See https://golang.org/cmd/go/#hdr-Generate_Go_files_by_processing_source.
    On Wed, Jun 8, 2016 at 6:45 AM, Kyle Stanly wrote:

    Alright... I don't know if I should be relieved or generally peeved...
    apparently was the fact that I ran `go generate` and `go run` from the root
    of the src directory. Apparently you actually HAVE to be in the
    cmd/compile/internal/gc folder, and it gave no inclination as to why it
    failed to begin with. Definitely think it should let you know in advance
    though. At least now I finally got it to work.
    On Tuesday, June 7, 2016 at 5:50:56 PM UTC-4, Matthew Dempsky wrote:

    You haven't regenerated src/cmd/compile/internal/gc/builtin.go.
    On Tue, Jun 7, 2016 at 2:48 PM, Kyle Stanly wrote:

    Okay, so I tried installing git-codereview, but unfortunately there's an
    issue where it attempts to open commit-msg using the cygwin path, but it
    seems that it doesn't recognize it. I.E, it uses /cygdrive/c/* instead of
    C:, so I tried git-review instead (installed directly through cygwin
    package manager), but unfortunately that doesn't seem to work because there
    is no .gitreview file? Anyway I'll sort it out tonight, but for now, I have
    the git diff instead...

    diff --git a/src/cmd/compile/internal/gc/builtin/runtime.go
    b/src/cmd/compile/internal/gc/builtin/runtime.go
    index e9316cb..cc5cdd3 100644
    --- a/src/cmd/compile/internal/gc/builtin/runtime.go
    +++ b/src/cmd/compile/internal/gc/builtin/runtime.go
    @@ -84,7 +84,7 @@ func ifaceeq(i1 any, i2 any) (ret bool)
    func efaceeq(i1 any, i2 any) (ret bool)

    // *byte is really *runtime.Type
    -func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any)
    (hmap map[any]any)
    +func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any,
    debug uintptr) (hmap map[any]any)
    func mapaccess1(mapType *byte, hmap map[any]any, key *any) (val *any)
    func mapaccess1_fast32(mapType *byte, hmap map[any]any, key any) (val
    *any)
    func mapaccess1_fast64(mapType *byte, hmap map[any]any, key any) (val
    *any)
    diff --git a/src/cmd/compile/internal/gc/typecheck.go
    b/src/cmd/compile/internal/gc/typecheck.go
    index c8ee941..b19f1b2 100644
    --- a/src/cmd/compile/internal/gc/typecheck.go
    +++ b/src/cmd/compile/internal/gc/typecheck.go
    @@ -1790,6 +1790,25 @@ OpSwitch:
    } else {
    n.Left = Nodintconst(0)
    }
    +
    + // L.J: Code added for 3rd parameter, 'mode'
    + if i < len(args) {
    + right := args[i]
    + i++
    + right = typecheck(right, Erv)
    + right = defaultlit(right, Types[TINT])
    + if right.Type == nil {
    + n.Type = nil
    + return n
    + }
    + if !checkmake(t, "mode", right) {
    + n.Type = nil
    + return n
    + }
    + n.Right = right
    + } else {
    + n.Right = Nodintconst(0)
    + }
    n.Op = OMAKEMAP

    case TCHAN:
    diff --git a/src/cmd/compile/internal/gc/walk.go
    b/src/cmd/compile/internal/gc/walk.go
    index 66eb7e9..71a8a4a 100644
    --- a/src/cmd/compile/internal/gc/walk.go
    +++ b/src/cmd/compile/internal/gc/walk.go
    @@ -1414,9 +1414,16 @@ opswitch:
    r = Nod(OADDR, var_, nil)
    }

    + // debug := false
    +
    + // // L.J: Only change in code
    + // if n.Right != nil && n.Right.Int64() != 0 {
    + // debug = true
    + // }
    +
    fn := syslook("makemap")
    fn = substArgTypes(fn, hmap(t), mapbucket(t), t.Key(),
    t.Val())
    - n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r)
    + n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r, conv(Nodintconst(0), Types[TUINTPTR]))

    case OMAKESLICE:
    l := n.Left

    diff --git a/src/runtime/hashmap.go b/src/runtime/hashmap.go
    index 509cab2..a55a91d 100644
    --- a/src/runtime/hashmap.go
    +++ b/src/runtime/hashmap.go


    @@ -96,6 +96,7 @@ const (
    iterator = 1 // there may be an iterator using buckets
    oldIterator = 2 // there may be an iterator using oldbuckets
    hashWriting = 4 // a goroutine is writing to the map
    + logEntrance = 8 // L.J: Inserted to log entrances in the function


    @@ -187,7 +188,8 @@ func (h *hmap) createOverflow() {
    // 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 bucket != nil, bucket can be used as the first bucket.
    -func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer)
    *hmap {
    +func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug uintptr) *hmap {
    + println("t: ", t, ";hint: ", hint, ";h: ", h, ";bucket: ",
    bucket, ";debug: ", debug)
    if sz := unsafe.Sizeof(hmap{}); sz > 48 || sz != t.hmap.size {
    println("runtime: sizeof(hmap) =", sz, ", t.hmap.size
    =", t.hmap.size)
    throw("bad hmap size")

    @@ -261,6 +263,11 @@ func makemap(t *maptype, hint int64, h *hmap,
    bucket unsafe.Pointer) *hmap {
    h.oldbuckets = nil
    h.nevacuate = 0

    + // L.J: Our inserted code.
    + if debug != 0 {
    + h.flags = logEntrance
    + }
    +
    return h
    }



    //go:linkname reflect_makemap reflect.makemap
    func reflect_makemap(t *maptype) *hmap {
    - return makemap(t, 0, nil, nil)
    + return makemap(t, 0, nil, nil, 0)
    }


    Sorry if it's ugly looking, best I can do, I have to head home now so I
    gotta leave soon but tonight I'll try to get it working once I get home.
    On Tuesday, June 7, 2016 at 5:39:17 PM UTC-4, Matthew Dempsky wrote:

    Technically CL is short for "change list". It's a terminology holdover
    from Google's internal use of Perforce.
    On Tue, Jun 7, 2016 at 2:29 PM, Kyle Stanly wrote:

    Alright guys, I'm setting up Gerrit now so I can upload a CL (Change
    Log???) through Cygwin, so I'll reply again with the commits I made. I'll
    also make sure to run mkbuiltin.go and report back for results.

    On Tuesday, June 7, 2016 at 4:05:13 PM UTC-4, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add
    a new argument to makemap, so I can add a specific flag for whether or not
    I want debugging. For example, if it is enabled, I want it to print the
    value of each argument, the entrance and exit of certain functions, the
    callers up to what is relevant (I.E, up to main()), etc. This is so I can
    add changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully,
    however if I pass as a flag to the new argument to debug, I expect to see
    debug information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.

    The stack trace is as follows... note debug shows an integer, I
    converted the bool to an uintptr to see if it happened to be an address and
    not garbage value. Its not entire garbage, because the value is consistent
    each time I run it, so its probably the value from something else. I'm
    assuming the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566 +0x9c
    fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857 +0x195
    fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553 +0x3a4
    fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()

    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16 +0xf8
    fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410
    +0x50 fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()

    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059 +0x1
    fp=0xc042037f98 sp=0xc042037f90


    Removing the extra parameter causes it to run just fine. Even if I
    could (which I am thinking of doing) marking the Most Significant Bit of
    hint, since it only uses the first 32-bits, for flags, I need to know how
    Go handles passing it's parameters and why its so sensitive to minimal
    changes like this.

    Also, I'll assume that it did NOT go through make(...) because
    OMAKEMAP explicitly sets debug to 0 for now, unconditionally, so it's being
    created in some other manner. I was thinking, after doing some digging,
    that it makes some specific assumptions in the assembly implementation of
    some go functions, and only push 4 arguments instead of 5, hence the
    garbage values. However, if it was pushed in reverse order, then that would
    not explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would
    be appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).
    --
    You received this message because you are subscribed to the Google
    Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-dev+...@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-dev+...@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Stanly at Jun 10, 2016 at 12:14 pm
    Quick question, and I'd hate to be a bother... but are adding
    functions/methods to the runtime done in the same way that adding
    parameters are? I.E, add the function to runtime.go, run go generate in
    that directory, etc.? Because for some reason, it's saying it's having
    trouble finding runtime.[MYFUNCTION]. Are any other files needed to be
    generated to get this to work? Better yet, is there a documented process
    for modifying the runtime?
    On Tuesday, June 7, 2016 at 5:50:56 PM UTC-4, Matthew Dempsky wrote:

    You haven't regenerated src/cmd/compile/internal/gc/builtin.go.

    On Tue, Jun 7, 2016 at 2:48 PM, Kyle Stanly <thei...@gmail.com
    <javascript:>> wrote:
    Okay, so I tried installing git-codereview, but unfortunately there's an
    issue where it attempts to open commit-msg using the cygwin path, but it
    seems that it doesn't recognize it. I.E, it uses /cygdrive/c/* instead of
    C:, so I tried git-review instead (installed directly through cygwin
    package manager), but unfortunately that doesn't seem to work because there
    is no .gitreview file? Anyway I'll sort it out tonight, but for now, I have
    the git diff instead...

    diff --git a/src/cmd/compile/internal/gc/builtin/runtime.go
    b/src/cmd/compile/internal/gc/builtin/runtime.go
    index e9316cb..cc5cdd3 100644
    --- a/src/cmd/compile/internal/gc/builtin/runtime.go
    +++ b/src/cmd/compile/internal/gc/builtin/runtime.go
    @@ -84,7 +84,7 @@ func ifaceeq(i1 any, i2 any) (ret bool)
    func efaceeq(i1 any, i2 any) (ret bool)

    // *byte is really *runtime.Type
    -func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any)
    (hmap map[any]any)
    +func makemap(mapType *byte, hint int64, mapbuf *any, bucketbuf *any,
    debug uintptr) (hmap map[any]any)
    func mapaccess1(mapType *byte, hmap map[any]any, key *any) (val *any)
    func mapaccess1_fast32(mapType *byte, hmap map[any]any, key any) (val
    *any)
    func mapaccess1_fast64(mapType *byte, hmap map[any]any, key any) (val
    *any)
    diff --git a/src/cmd/compile/internal/gc/typecheck.go
    b/src/cmd/compile/internal/gc/typecheck.go
    index c8ee941..b19f1b2 100644
    --- a/src/cmd/compile/internal/gc/typecheck.go
    +++ b/src/cmd/compile/internal/gc/typecheck.go
    @@ -1790,6 +1790,25 @@ OpSwitch:
    } else {
    n.Left = Nodintconst(0)
    }
    +
    + // L.J: Code added for 3rd parameter, 'mode'
    + if i < len(args) {
    + right := args[i]
    + i++
    + right = typecheck(right, Erv)
    + right = defaultlit(right, Types[TINT])
    + if right.Type == nil {
    + n.Type = nil
    + return n
    + }
    + if !checkmake(t, "mode", right) {
    + n.Type = nil
    + return n
    + }
    + n.Right = right
    + } else {
    + n.Right = Nodintconst(0)
    + }
    n.Op = OMAKEMAP

    case TCHAN:
    diff --git a/src/cmd/compile/internal/gc/walk.go
    b/src/cmd/compile/internal/gc/walk.go
    index 66eb7e9..71a8a4a 100644
    --- a/src/cmd/compile/internal/gc/walk.go
    +++ b/src/cmd/compile/internal/gc/walk.go
    @@ -1414,9 +1414,16 @@ opswitch:
    r = Nod(OADDR, var_, nil)
    }

    + // debug := false
    +
    + // // L.J: Only change in code
    + // if n.Right != nil && n.Right.Int64() != 0 {
    + // debug = true
    + // }
    +
    fn := syslook("makemap")
    fn = substArgTypes(fn, hmap(t), mapbucket(t), t.Key(),
    t.Val())
    - n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r)
    + n = mkcall1(fn, n.Type, init, typename(n.Type),
    conv(n.Left, Types[TINT64]), a, r, conv(Nodintconst(0), Types[TUINTPTR]))

    case OMAKESLICE:
    l := n.Left

    diff --git a/src/runtime/hashmap.go b/src/runtime/hashmap.go
    index 509cab2..a55a91d 100644
    --- a/src/runtime/hashmap.go
    +++ b/src/runtime/hashmap.go


    @@ -96,6 +96,7 @@ const (
    iterator = 1 // there may be an iterator using buckets
    oldIterator = 2 // there may be an iterator using oldbuckets
    hashWriting = 4 // a goroutine is writing to the map
    + logEntrance = 8 // L.J: Inserted to log entrances in the function


    @@ -187,7 +188,8 @@ func (h *hmap) createOverflow() {
    // 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 bucket != nil, bucket can be used as the first bucket.
    -func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer)
    *hmap {
    +func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug uintptr) *hmap {
    + println("t: ", t, ";hint: ", hint, ";h: ", h, ";bucket: ",
    bucket, ";debug: ", debug)
    if sz := unsafe.Sizeof(hmap{}); sz > 48 || sz != t.hmap.size {
    println("runtime: sizeof(hmap) =", sz, ", t.hmap.size =",
    t.hmap.size)
    throw("bad hmap size")

    @@ -261,6 +263,11 @@ func makemap(t *maptype, hint int64, h *hmap,
    bucket unsafe.Pointer) *hmap {
    h.oldbuckets = nil
    h.nevacuate = 0

    + // L.J: Our inserted code.
    + if debug != 0 {
    + h.flags = logEntrance
    + }
    +
    return h
    }



    //go:linkname reflect_makemap reflect.makemap
    func reflect_makemap(t *maptype) *hmap {
    - return makemap(t, 0, nil, nil)
    + return makemap(t, 0, nil, nil, 0)
    }


    Sorry if it's ugly looking, best I can do, I have to head home now so I
    gotta leave soon but tonight I'll try to get it working once I get home.
    On Tuesday, June 7, 2016 at 5:39:17 PM UTC-4, Matthew Dempsky wrote:

    Technically CL is short for "change list". It's a terminology holdover
    from Google's internal use of Perforce.
    On Tue, Jun 7, 2016 at 2:29 PM, Kyle Stanly wrote:

    Alright guys, I'm setting up Gerrit now so I can upload a CL (Change
    Log???) through Cygwin, so I'll reply again with the commits I made. I'll
    also make sure to run mkbuiltin.go and report back for results.

    On Tuesday, June 7, 2016 at 4:05:13 PM UTC-4, Kyle Stanly wrote:

    So, I've been experimenting quite a bit... first being, I want to add
    a new argument to makemap, so I can add a specific flag for whether or not
    I want debugging. For example, if it is enabled, I want it to print the
    value of each argument, the entrance and exit of certain functions, the
    callers up to what is relevant (I.E, up to main()), etc. This is so I can
    add changes to the map and be able to debug certain changes and not be
    overwhelmed with debug information from the hundreds of uses of map from
    others.

    Currently, I added a new parameter to make(map...) successfully,
    however if I pass as a flag to the new argument to debug, I expect to see
    debug information. Hence, I added to makemap a 5th argument...

    func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer,
    debug bool) *hmap

    Unfortunately it seems that... it's not so simple. I HAVE made the
    appropriate changes in reflect_makemap, and made the appropriate changes to
    'cmd/compile/internal/gc/builtin/runtime.go', I've run 'go generate' in the
    root of the Go repository, and it continues to compile Go bootstrap tool,
    Go toolchain, and go_bootstrap for host (windows/amd64), however fails when
    I attempt to build packages and commands for windows/amd64, it fails with a
    fatal error stating 'fatal error: evacuation not done in time'.

    The stack trace is as follows... note debug shows an integer, I
    converted the bool to an uintptr to see if it happened to be an address and
    not garbage value. Its not entire garbage, because the value is consistent
    each time I run it, so its probably the value from something else. I'm
    assuming the ABI pushes parameters on the stack.


    ##### Building packages and commands for windows/amd64.
    t: 0x6830e0 ;hint: 0 ;h: 0x0 ;bucket: 0x0 ;debug: 8429248
    fatal error: evacuation not done in time

    goroutine 1 [running, locked to thread]:
    runtime.throw(0x6cc46f, 0x1b)
    C:/Users/theif519/Documents/GitHub/go/src/runtime/panic.go:566
    +0x9c fp=0xc042037cb8 sp=0xc042037c98
    runtime.hashGrow(0x6830e0, 0x809ec0)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:857 +0x195
    fp=0xc042037cf0 sp=0xc042037cb8
    runtime.mapassign1(0x6830e0, 0x809ec0, 0xc042037e40, 0xc042037e08)

    C:/Users/theif519/Documents/GitHub/go/src/runtime/hashmap.go:553 +0x3a4
    fp=0xc042037dc8 sp=0xc042037cf0
    unicode.init()
    C:/Users/theif519/Documents/GitHub/go/src/unicode/tables.go:16
    +0xf8 fp=0xc042037e60 sp=0xc042037dc8
    bytes.init()
    C:/Users/theif519/Documents/GitHub/go/src/bytes/reader.go:151
    +0x55 fp=0xc042037e90 sp=0xc042037e60
    bufio.init()
    C:/Users/theif519/Documents/GitHub/go/src/bufio/scan.go:410
    +0x50 fp=0xc042037ec0 sp=0xc042037e90
    main.init()
    C:/Users/theif519/Documents/GitHub/go/src/cmd/go/zosarch.go:5
    +0x55 fp=0xc042037f38 sp=0xc042037ec0
    runtime.main()
    C:/Users/theif519/Documents/GitHub/go/src/runtime/proc.go:172
    +0x1bb fp=0xc042037f90 sp=0xc042037f38
    runtime.goexit()

    C:/Users/theif519/Documents/GitHub/go/src/runtime/asm_amd64.s:2059 +0x1
    fp=0xc042037f98 sp=0xc042037f90


    Removing the extra parameter causes it to run just fine. Even if I
    could (which I am thinking of doing) marking the Most Significant Bit of
    hint, since it only uses the first 32-bits, for flags, I need to know how
    Go handles passing it's parameters and why its so sensitive to minimal
    changes like this.

    Also, I'll assume that it did NOT go through make(...) because
    OMAKEMAP explicitly sets debug to 0 for now, unconditionally, so it's being
    created in some other manner. I was thinking, after doing some digging,
    that it makes some specific assumptions in the assembly implementation of
    some go functions, and only push 4 arguments instead of 5, hence the
    garbage values. However, if it was pushed in reverse order, then that would
    not explain the fact that some are nil and others are not. Are parameters
    pushed through registers? That'd kind of make sense if that's the case,
    because then the 5th one, R8 I think, would probably hold the previous
    value.

    Perhaps I'm wrong and am just doing it wrong, I dunno, any help would
    be appreciated. I just need to know what changes I should make to add a new
    argument (that way I can create my own later on).
    --
    You received this message because you are subscribed to the Google
    Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-dev+...@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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Jun 10, 2016 at 4:24 pm

    On Fri, Jun 10, 2016 at 5:14 AM, Kyle Stanly wrote:

    Quick question, and I'd hate to be a bother... but are adding
    functions/methods to the runtime done in the same way that adding
    parameters are?
    Yes.

    Because for some reason, it's saying it's having trouble finding
    runtime.[MYFUNCTION].
    It would help if you included the error message here. I don't know whether
    "it" here refers to the compiler vs linker, which would indicate different
    problems and thus solutions.

    Better yet, is there a documented process for modifying the runtime?
    >

    Not really.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJun 7, '16 at 8:05p
activeJun 10, '16 at 4:24p
posts23
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase