Skip to content

Commit d6f4d9a

Browse files
committed
[release-branch.go1.17] all: merge master into release-branch.go1.17
a985897 crypto/tls: test key type when casting cfbd73b doc/go1.17: editing pass over the "Compiler" section ab4085c runtime/pprof: call runtime.GC twice in memory profile test Change-Id: I5b19d559629353886752e2a73ce8f37f983772df
2 parents 296ddf2 + a985897 commit d6f4d9a

File tree

3 files changed

+52
-27
lines changed

3 files changed

+52
-27
lines changed

doc/go1.17.html

Lines changed: 36 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -401,30 +401,37 @@ <h2 id="compiler">Compiler</h2>
401401

402402
<p><!-- golang.org/issue/40724 -->
403403
Go 1.17 implements a new way of passing function arguments and results using
404-
registers instead of the stack. This work is enabled for Linux, macOS, and
405-
Windows on the 64-bit x86 architecture (the <code>linux/amd64</code>,
406-
<code>darwin/amd64</code>, <code>windows/amd64</code> ports). For a
407-
representative set of Go packages and programs, benchmarking has shown
408-
performance improvements of about 5%, and a typical reduction in binary size
409-
of about 2%.
404+
registers instead of the stack.
405+
Benchmarks for a representative set of Go packages and programs show
406+
performance improvements of about 5%, and a typical reduction in
407+
binary size of about 2%.
408+
This is currently enabled for Linux, macOS, and Windows on the
409+
64-bit x86 architecture (the <code>linux/amd64</code>,
410+
<code>darwin/amd64</code>, and <code>windows/amd64</code> ports).
410411
</p>
411412

412413
<p>
413-
This change does not affect the functionality of any safe Go code. It can affect
414-
code outside the <a href="/doc/go1compat">compatibility guidelines</a> with
415-
minimal impact. To maintain compatibility with existing assembly functions,
416-
adapter functions converting between the new register-based calling convention
417-
and the previous stack-based calling convention (also known as ABI wrappers)
418-
are sometimes used. This is mostly invisible to users, except for assembly
419-
functions that have their addresses taken in Go. Using <code>reflect.ValueOf(fn).Pointer()</code>
420-
(or similar approaches such as via <code>unsafe.Pointer</code>) to get the address
421-
of an assembly function will now return the address of the ABI wrapper. This is
422-
mostly harmless, except for special-purpose assembly code (such as accessing
423-
thread-local storage or requiring a special stack alignment). Assembly functions
424-
called indirectly from Go via <code>func</code> values will now be made through
425-
ABI wrappers, which may cause a very small performance overhead. Also, calling
426-
Go functions from assembly may now go through ABI wrappers, with a very small
427-
performance overhead.
414+
This change does not affect the functionality of any safe Go code
415+
and is designed to have no impact on most assembly code.
416+
It may affect code that violates
417+
the <a href="/pkg/unsafe#Pointer"><code>unsafe.Pointer</code></a>
418+
rules when accessing function arguments, or that depends on
419+
undocumented behavior involving comparing function code pointers.
420+
To maintain compatibility with existing assembly functions, the
421+
compiler generates adapter functions that convert between the new
422+
register-based calling convention and the previous stack-based
423+
calling convention.
424+
These adapters are typically invisible to users, except that taking
425+
the address of a Go function in assembly code or taking the address
426+
of an assembly function in Go code
427+
using <code>reflect.ValueOf(fn).Pointer()</code>
428+
or <code>unsafe.Pointer</code> will now return the address of the
429+
adapter.
430+
Code that depends on the value of these code pointers may no longer
431+
behave as expected.
432+
Adapters also may cause a very small performance overhead in two
433+
cases: calling an assembly function indirectly from Go via
434+
a <code>func</code> value, and calling Go functions from assembly.
428435
</p>
429436

430437
<p><!-- CL 304470 -->
@@ -440,11 +447,14 @@ <h2 id="compiler">Compiler</h2>
440447
</p>
441448

442449
<p><!-- CL 283112, golang.org/issue/28727 -->
443-
Functions containing closures can now be inlined. One effect of this change is
444-
that a function with a closure may actually produce a distinct closure function
445-
for each place that the function is inlined. Hence, this change could reveal
446-
bugs where Go functions are compared (incorrectly) by pointer value. Go
447-
functions are by definition not comparable.
450+
Functions containing closures can now be inlined.
451+
One effect of this change is that a function with a closure may
452+
produce a distinct closure code pointer for each place that the
453+
function is inlined.
454+
Go function values are not directly comparable, but this change
455+
could reveal bugs in code that uses <code>reflect</code>
456+
or <code>unsafe.Pointer</code> to bypass this language restriction
457+
and compare functions by code pointer.
448458
</p>
449459

450460
<h2 id="library">Core library</h2>

src/crypto/tls/key_agreement.go

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -86,7 +86,11 @@ func (ka rsaKeyAgreement) generateClientKeyExchange(config *Config, clientHello
8686
return nil, nil, err
8787
}
8888

89-
encrypted, err := rsa.EncryptPKCS1v15(config.rand(), cert.PublicKey.(*rsa.PublicKey), preMasterSecret)
89+
rsaKey, ok := cert.PublicKey.(*rsa.PublicKey)
90+
if !ok {
91+
return nil, nil, errors.New("tls: server certificate contains incorrect key type for selected ciphersuite")
92+
}
93+
encrypted, err := rsa.EncryptPKCS1v15(config.rand(), rsaKey, preMasterSecret)
9094
if err != nil {
9195
return nil, nil, err
9296
}

src/runtime/pprof/mprof_test.go

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -86,6 +86,17 @@ func TestMemoryProfiler(t *testing.T) {
8686

8787
runtime.GC() // materialize stats
8888

89+
// TODO(mknyszek): Fix #45315 and remove this extra call.
90+
//
91+
// Unfortunately, it's possible for the sweep termination condition
92+
// to flap, so with just one runtime.GC call, a freed object could be
93+
// missed, leading this test to fail. A second call reduces the chance
94+
// of this happening to zero, because sweeping actually has to finish
95+
// to move on to the next GC, during which nothing will happen.
96+
//
97+
// See #46500 for more details.
98+
runtime.GC()
99+
89100
memoryProfilerRun++
90101

91102
tests := []struct {

0 commit comments

Comments
 (0)