delta/go-git.git/src/cmd/link, branch dev.cmdgo

cmd/link: guarantee "section .debug_gdb_scripts" is always "$GOROOT/src/runtime/runtime-gdb.py".

2021-08-24T16:55:17+00:00

to guarantee the "section .debug_gdb_scripts" is  always "$GOROOT/src/runtime/runtime-gdb.py" , a check for package name is needed when search "runtime/proc.go".

Fixes #47881

Change-Id: Ib471314ca1a6777f625b488e5ae3790457540ef9
Reviewed-on: https://go-review.googlesource.com/c/go/+/344229
Run-TryBot: Than McIntosh 
TryBot-Result: Go Bot 
Reviewed-by: Than McIntosh 
Trust: Michael Knyszek

cmd/link: do not use GO_LDSO when cross compile

2021-08-17T23:59:53+00:00

GO_LDSO is a setting that is set when the toolchain is build. It
only makes sense to use it on the host platform. Do not use it
when targetting a different platform.

In the past it was not a problem as GO_LDSO was almost always
unset. Now, with CL 301989 it is almost always set (maybe we want
to revisit it).

Fixes #47760.

Change-Id: I2704b9968781f46e2d2f8624090db19689b1a32f
Reviewed-on: https://go-review.googlesource.com/c/go/+/343010
Trust: Cherry Mui 
Run-TryBot: Cherry Mui 
TryBot-Result: Go Bot 
Reviewed-by: Ian Lance Taylor

cmd/link: remove elfwritedynentsym

2021-08-17T15:00:04+00:00

elfwritedynentsym and elfWriteDynEntSym are identical.

Change-Id: I893a9a65fdc496f98ba6e66c2bf1ed8dd52f52fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/342709
Trust: Cherry Mui 
Run-TryBot: Cherry Mui 
TryBot-Result: Go Bot 
Reviewed-by: Than McIntosh

cmd: support space and quotes in CC and CXX

2021-08-16T20:23:11+00:00

The CC and CXX environment variables now support spaces and quotes
(both double and single). This fixes two issues: first, if CC is a
single path that contains spaces (like 'c:\Program
Files\gcc\bin\gcc.exe'), that should now work if the space is quoted
or escaped (#41400). Second, if CC or CXX has multiple arguments (like
'gcc -O2'), they are now split correctly, and the arguments are passed
before other arguments when invoking the C compiler. Previously,
strings.Fields was used to split arguments, and the arguments were
placed later in the command line. (#43078).

Fixes golang/go#41400
Fixes golang/go#43078

NOTE: This change also includes a fix (CL 341929) for a test that was
broken by the original CL. Commit message for the fix is below.

[dev.cmdgo] cmd/link: fix TestBuildForTvOS

This test was broken in CL 334732 on darwin.

The test invokes 'go build' with a CC containing the arguments
-framework CoreFoundation. Previously, the go command split CC on
whitespace, and inserted the arguments after the command line when
running CC directly. Those arguments weren't passed to cgo though,
so cgo ran CC without -framework CoreFoundation (or any of the other
flags).

In CL 334732, we pass CC through to cgo, and cgo splits arguments
using str.SplitQuotedFields. So -framework CoreFoundation actually
gets passed to the C compiler. It appears that -framework flags are
only meant to be used in linking operations, so when cgo invokes clang
with -E (run preprocessor only), clang emits an error that -framework
is unused.

This change fixes the test by moving -framework CoreFoundation out of
CC and into CGO_LDFLAGS.

Change-Id: I2d5d89ddb19c94adef65982a8137b01f037d5c11
Reviewed-on: https://go-review.googlesource.com/c/go/+/334732
Trust: Jay Conrod 
Trust: Michael Matloob 
Run-TryBot: Jay Conrod 
TryBot-Result: Go Bot 
Reviewed-by: Michael Matloob 
Reviewed-on: https://go-review.googlesource.com/c/go/+/341936
Reviewed-by: Bryan C. Mills

cmd/link: start at address 0 when external linking

2021-08-16T16:20:06+00:00

When external linking, we are creating an object file, instead of
a executable. The absolute address is irrelevant. The external
linker will set it up. Start at address 0.

Change-Id: I3a2e0b8087b328d5c3144f29ca8ba6311aa39cba
Reviewed-on: https://go-review.googlesource.com/c/go/+/319830
Trust: Cherry Mui 
Run-TryBot: Cherry Mui 
TryBot-Result: Go Bot 
Reviewed-by: Than McIntosh

cmd/link: fix dead reference link

2021-08-13T21:47:42+00:00

Change-Id: I0f53cc2b845f8a52fece2aaba1445a0ecb9cdc53
Reviewed-on: https://go-review.googlesource.com/c/go/+/341129
Reviewed-by: Ian Lance Taylor 
Trust: Dmitri Shuralyov

[dev.typeparams] cmd/compile: use types2.Constraint() rather than types2.Bound()

2021-08-09T20:08:06+00:00

types2.Constraint() returns the top-level constraint type, including any
unions or other interface elements. Because of that, we needed to
add/fix some code in the type substituter and generic type instantiater
in the importer to deal with unions and non-method members of an
interface. Also, NewUnion was not correctly setting the HasTParam flag.

I also added a better error message when a symbol is not found in
(*deadcodePass).decodeIfaceMethod().

Change-Id: Id3668dc596dce63690fa05a9e5e42295b5e2bbb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/340670
Trust: Dan Scales 
Run-TryBot: Dan Scales 
Reviewed-by: Keith Randall

[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loop

2021-08-03T21:05:55+00:00

Currently, deferreturn runs deferred functions by backing up its
return PC to the deferreturn call, and then effectively tail-calling
the deferred function (via jmpdefer). The effect of this is that the
deferred function appears to be called directly from the deferee, and
when it returns, the deferee calls deferreturn again so it can run the
next deferred function if necessary.

This unusual flow control leads to a large number of special cases and
complications all over the tool chain.

This used to be necessary because deferreturn copied the deferred
function's argument frame directly into its caller's frame and then
had to invoke that call as if it had been called from its caller's
frame so it could access it arguments. But now that we've simplified
defer processing so the runtime only deals with argument-less
closures, this approach is no longer necessary.

This CL simplifies all of this by making deferreturn simply call
deferred functions in a loop.

This eliminates the need for jmpdefer, so we can delete a bunch of
per-architecture assembly code.

This eliminates several special cases on Wasm, since it couldn't
support these calling shenanigans directly and thus had to simulate
the loop a different way. Now Wasm can largely work the way the other
platforms do.

This eliminates the per-architecture Ginsnopdefer operation. On PPC64,
this was necessary to reload the TOC pointer after the tail call
(since TOC pointers in general make tail calls impossible). The tail
call is gone, and in the case where we do force a jump to the
deferreturn call when recovering from an open-coded defer, we go
through gogo (via runtime.recovery), which handles the TOC. On other
platforms, we needed a NOP so traceback didn't get confused by seeing
the return to the CALL instruction, rather than the usual return to
the instruction following the CALL instruction. Now we don't inject a
return to the CALL instruction at all, so this NOP is also
unnecessary.

The one potential effect of this is that deferreturn could now appear
in stack traces from deferred functions. However, this could already
happen from open-coded defers, so we've long since marked deferreturn
as a "wrapper" so it gets elided not only from printed stack traces,
but from runtime.Callers*.

This is a retry of CL 337652 because we had to back out its parent.
There are no changes in this version.

Change-Id: I3f54b7fec1d7ccac71cc6cf6835c6a46b7e5fb6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/339397
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui

[dev.typeparams] Revert "[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loop"

2021-07-30T21:51:49+00:00

This reverts CL 227652.

I'm reverting CL 337651 and this builds on top of it.

Change-Id: I03ce363be44c2a3defff2e43e7b1aad83386820d
Reviewed-on: https://go-review.googlesource.com/c/go/+/338709
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui

[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loop

2021-07-30T18:49:44+00:00

Currently, deferreturn runs deferred functions by backing up its
return PC to the deferreturn call, and then effectively tail-calling
the deferred function (via jmpdefer). The effect of this is that the
deferred function appears to be called directly from the deferee, and
when it returns, the deferee calls deferreturn again so it can run the
next deferred function if necessary.

This unusual flow control leads to a large number of special cases and
complications all over the tool chain.

This used to be necessary because deferreturn copied the deferred
function's argument frame directly into its caller's frame and then
had to invoke that call as if it had been called from its caller's
frame so it could access it arguments. But now that we've simplified
defer processing so the runtime only deals with argument-less
closures, this approach is no longer necessary.

This CL simplifies all of this by making deferreturn simply call
deferred functions in a loop.

This eliminates the need for jmpdefer, so we can delete a bunch of
per-architecture assembly code.

This eliminates several special cases on Wasm, since it couldn't
support these calling shenanigans directly and thus had to simulate
the loop a different way. Now Wasm can largely work the way the other
platforms do.

This eliminates the per-architecture Ginsnopdefer operation. On PPC64,
this was necessary to reload the TOC pointer after the tail call
(since TOC pointers in general make tail calls impossible). The tail
call is gone, and in the case where we do force a jump to the
deferreturn call when recovering from an open-coded defer, we go
through gogo (via runtime.recovery), which handles the TOC. On other
platforms, we needed a NOP so traceback didn't get confused by seeing
the return to the CALL instruction, rather than the usual return to
the instruction following the CALL instruction. Now we don't inject a
return to the CALL instruction at all, so this NOP is also
unnecessary.

The one potential effect of this is that deferreturn could now appear
in stack traces from deferred functions. However, this could already
happen from open-coded defers, so we've long since marked deferreturn
as a "wrapper" so it gets elided not only from printed stack traces,
but from runtime.Callers*.

Change-Id: Ie9f700cd3fb774f498c9edce363772a868407bf7
Reviewed-on: https://go-review.googlesource.com/c/go/+/337652
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui