• Russ Cox's avatar
    [dev.cc] runtime: delete scalararg, ptrarg; rename onM to systemstack · 656be317
    Russ Cox authored
    Scalararg and ptrarg are not "signal safe".
    Go code filling them out can be interrupted by a signal,
    and then the signal handler runs, and if it also ends up
    in Go code that uses scalararg or ptrarg, now the old
    values have been smashed.
    For the pieces of code that do need to run in a signal handler,
    we introduced onM_signalok, which is really just onM
    except that the _signalok is meant to convey that the caller
    asserts that scalarg and ptrarg will be restored to their old
    values after the call (instead of the usual behavior, zeroing them).
    
    Scalararg and ptrarg are also untyped and therefore error-prone.
    
    Go code can always pass a closure instead of using scalararg
    and ptrarg; they were only really necessary for C code.
    And there's no more C code.
    
    For all these reasons, delete scalararg and ptrarg, converting
    the few remaining references to use closures.
    
    Once those are gone, there is no need for a distinction between
    onM and onM_signalok, so replace both with a single function
    equivalent to the current onM_signalok (that is, it can be called
    on any of the curg, g0, and gsignal stacks).
    
    The name onM and the phrase 'm stack' are misnomers,
    because on most system an M has two system stacks:
    the main thread stack and the signal handling stack.
    
    Correct the misnomer by naming the replacement function systemstack.
    
    Fix a few references to "M stack" in code.
    
    The main motivation for this change is to eliminate scalararg/ptrarg.
    Rick and I have already seen them cause problems because
    the calling sequence m.ptrarg[0] = p is a heap pointer assignment,
    so it gets a write barrier. The write barrier also uses onM, so it has
    all the same problems as if it were being invoked by a signal handler.
    We worked around this by saving and restoring the old values
    and by calling onM_signalok, but there's no point in keeping this nice
    home for bugs around any longer.
    
    This CL also changes funcline to return the file name as a result
    instead of filling in a passed-in *string. (The *string signature is
    left over from when the code was written in and called from C.)
    That's arguably an unrelated change, except that once I had done
    the ptrarg/scalararg/onM cleanup I started getting false positives
    about the *string argument escaping (not allowed in package runtime).
    The compiler is wrong, but the easiest fix is to write the code like
    Go code instead of like C code. I am a bit worried that the compiler
    is wrong because of some use of uninitialized memory in the escape
    analysis. If that's the reason, it will go away when we convert the
    compiler to Go. (And if not, we'll debug it the next time.)
    
    LGTM=khr
    R=r, khr
    CC=austin, golang-codereviews, iant, rlh
    https://golang.org/cl/174950043
    656be317
mem.go 3.44 KB