When the kernel parameter ptrace_scope is set to 2 or 3,
certain test cases in runtime-gdb_test.go will fail.
We should skip these tests.
Fixes#69932
Change-Id: I685d1217f1521d7f8801680cf6b71d8e7a265188
GitHub-Last-Rev: 063759e04c
GitHub-Pull-Request: golang/go#69933
Reviewed-on: https://go-review.googlesource.com/c/go/+/620857
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-amd64-longtest-swissmap
Change-Id: I6695c0b143560d974b710e1d78e7a7d09278f7cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/620215
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Use the new SwissTable-based map in internal/runtime/maps as the basis
for the runtime map when GOEXPERIMENT=swissmap.
Integration is complete enough to pass all.bash. Notable missing
features:
* Race integration / concurrent write detection
* Stack-allocated maps
* Specialized "fast" map variants
* Indirect key / elem
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-amd64-longtest-swissmap
Change-Id: Ie97b656b6d8e05c0403311ae08fef9f51756a639
Reviewed-on: https://go-review.googlesource.com/c/go/+/594596
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On Arch Linux with gdb version 15.1, the test for TestGdbAutotmpTypes print
the following output,
----
~/src/go/src/runtime
$ go test -run=TestGdbAutotmpTypes -v
=== RUN TestGdbAutotmpTypes
=== PAUSE TestGdbAutotmpTypes
=== CONT TestGdbAutotmpTypes
runtime-gdb_test.go:78: gdb version 15.1
runtime-gdb_test.go:570: gdb output:
Loading Go Runtime support.
Target 'exec' cannot support this command.
Breakpoint 1 at 0x46e416: file /tmp/TestGdbAutotmpTypes750485513/001/main.go, line 8.
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[New LWP 355373]
[New LWP 355374]
[New LWP 355375]
[New LWP 355376]
Thread 1 "a.exe" hit Breakpoint 1, main.main () at /tmp/TestGdbAutotmpTypes750485513/001/main.go:8
8 func main() {
9 var iface interface{} = map[string]astruct{}
All types matching regular expression "astruct":
File runtime:
[]main.astruct
bucket<string,main.astruct>
hash<string,main.astruct>
main.astruct
typedef hash<string,main.astruct> * map[string]main.astruct;
typedef noalg.[8]main.astruct noalg.[8]main.astruct;
noalg.map.bucket[string]main.astruct
runtime-gdb_test.go:587: could not find []main.astruct; in 'info typrs astruct' output
!!! FAIL
exit status 1
FAIL runtime 0.273s
$
----
In the back trace for "File runtime", each output lines does not end with
";" anymore, while in test we check the string with it.
While at it, print the expected string with "%q" instead of "%s" for
better error message.
Fixes#67089
Change-Id: If6019ee68c0d8e495c920f98568741462c7d0fd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/598135
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The two map implementations are still identical, but now the compiler
targets the appropriate ABI depending on GOEXPERIMENT.
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-amd64-longtest-swissmap
Change-Id: I8438f64f044ba9de30ddbf2b8ceb9b4edd2d5614
Reviewed-on: https://go-review.googlesource.com/c/go/+/580779
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TestGdbPython fails on some Windows setups because the line endings in
the output of the gdb command can potentially be CRLF, but the test
expects LF.
This CL changes the test to normalize the line endings.
Change-Id: Iada9c37dc98249ac3c5f1edca4a657c51d4382a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/532816
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
One issue simply has a reworded message, probably from a new version of
GDB. Another is a new issue.
Fixes#60553.
Fixes#58698.
Updates #39204.
Change-Id: I8389aa981fab5421f57ee761bfb5e1dd237709ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/499975
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TestGdbPanic expects crash() to raise a SIGABRT signal interceptable
by gdb, but Windows doesn't have signals.
Windows builders haven't caught this failing test because they still
don't have gdb installed (tracked in #22021).
Change-Id: I7c7f2523a54d61aea0a9821c4db7c79e58a7217c
Reviewed-on: https://go-review.googlesource.com/c/go/+/473116
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
The runtime-gdb.py script needs procid to be set in order to
map a goroutine ID with an OS thread. The Go runtime is not currently
setting that variable on Windows, so TestGdbPython (and friends) can't
succeed.
This CL initializes procid and unskips gdb tests on Windows.
Fixes#22687
Updates #21380
Updates #22021
Change-Id: Icd1d9fc1764669ed1bf04f53d17fadfd24ac3f30
Reviewed-on: https://go-review.googlesource.com/c/go/+/470596
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Previously TryBot-tested with bucket bits = 4.
Also tested locally with bucket bits = 5.
This makes it much easier to change the size of map
buckets, and hopefully provides pointers to all the
code that in some way depends on details of map layout.
Change-Id: I9f6669d1eadd02f182d0bc3f959dc5f385fa1683
Reviewed-on: https://go-review.googlesource.com/c/go/+/462115
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
This may fix the TestEINTR failures that have been frequent on the
riscv64 builders since CL 445597.
Updates #37405.
Updates #39043.
Change-Id: Iaf1403ff5ce2ff0203d5d0059908097d32d0b217
Reviewed-on: https://go-review.googlesource.com/c/go/+/447495
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
For most tests, the test's deadline itself is more appropriate than an
arbitrary timeout layered atop of it (especially once #48157 is
implemented), and testenv.Command already adds cleaner timeout
behavior when a command would run too close to the test's deadline.
That makes RunWithTimeout something of an attractive nuisance. For
now, migrate the two existing uses of it to testenv.CommandContext,
with a shorter timeout implemented using context.WithTimeout.
As a followup, we may want to drop the extra timeouts from these
invocations entirely.
Updates #50436.
Updates #37405.
Change-Id: I16840fd36c0137b6da87ec54012b3e44661f0d08
Reviewed-on: https://go-review.googlesource.com/c/go/+/445597
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Disable the TestGdb* testpoints until we can figure out why they are
failing and reconfigure the machine properly.
Updates #54352.
Change-Id: Id9c76a0ba6e23b5deff24f521a1c8e0aafb6481a
Reviewed-on: https://go-review.googlesource.com/c/go/+/422294
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Very rarely, GDB will successfully run the whole test and the inferior
will exit successfully, and then GDB itself hangs and never exits.
Detect this and skip the test as flaky. We could just continue the
test since all of the output we need is there, but by skipping it
we're less likely to notice serious regressions in this test.
Fixes#37405.
Change-Id: I016cbb06f48673f064733da3e3f1ddcbefd58159
Reviewed-on: https://go-review.googlesource.com/c/go/+/411117
Reviewed-by: Cherry Mui <cherryyz@google.com>
If a GC related task preempts between hitting the main.main breakpoint
and stepping, the test program may halt forever waiting on a GC
operation. This happens if gdb is configured to halt other threads
while executing a step.
Configure gdb to continue running all threads during a step by
setting the scheduler-locking option to off.
Fixes#49852
Change-Id: Iacc9732cbd23526bde0a295e6fa8a0d90f733f59
Reviewed-on: https://go-review.googlesource.com/c/go/+/370775
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Cherry Mui <cherryyz@google.com>
This fixes many (but not all) of the tests that currently fail
(due to a bogus path reported by runtime.GOROOT) when run with
'go test -trimpath std cmd'.
Updates #51461
Change-Id: Ia2cc05705529c4859e7928f32eeceed647f2e986
Reviewed-on: https://go-review.googlesource.com/c/go/+/391806
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
TestGdbBacktrace occasionally fails due to a GDB internal error.
We have observed the error on various linux builders since at least
October 2020, and it has been reported upstream at least twice.¹²
Since the bug is external to the Go project and does not appear to be
fixed upstream, this failure mode can only add noise.
¹https://sourceware.org/bugzilla/show_bug.cgi?id=24628
²https://sourceware.org/bugzilla/show_bug.cgi?id=28551Fixes#43068
Change-Id: I6c92006a5d730f1c4df54b0307f080b3d643cc6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/384234
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The failure mode in #37794 does not match the failure mode described
in #18784. However, since the test is currently skipped on all other
MIPS variants, it may be that they suffer from the same underlying GDB
bug. Ideally one of the Go MIPS maintainers should file an upstream
bug and remove the skip once it is fixed; in the meantime, there is no
point in continuing to let the test fail on just one of the four MIPS
variants.
For #37794
Change-Id: I570f51cc04cbb7ef1ed7efd526e26886af53bfb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/376654
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This sometimes times out and we don't have any useful output for
debugging it. Hopefully this will help.
For #37405.
Change-Id: I79074e6fbb9bd16a864c651109a0acbfc8aa6cef
Reviewed-on: https://go-review.googlesource.com/c/go/+/370703
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Many uses of Index/IndexByte/IndexRune/Split/SplitN
can be written more clearly using the new Cut functions.
Do that. Also rewrite to other functions if that's clearer.
For #46336.
Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448
Reviewed-on: https://go-review.googlesource.com/c/go/+/351711
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #45402
Change-Id: I3aa82fc2486b4de49b45388bbab24f5ffe558f91
Reviewed-on: https://go-review.googlesource.com/c/go/+/307989
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
As part of #42026, these helpers from io/ioutil were moved to os.
(ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.)
Update the Go tree to use the preferred names.
As usual, code compiled with the Go 1.4 bootstrap toolchain
and code vendored from other sources is excluded.
ReadDir changes are in a separate CL, because they are not a
simple search and replace.
For #42026.
Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/266365
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Hand-verified for listed gdb versions. Gdb (apparently)
changed the way it names certain Go types, and this change
broke the pretty-printer-activating code in runtime-gdb.py
runtime-gdb_test.go now checks channel, map, string, and slice
printing unconditionally (i.e., no opt-out for old versions).
Updates #39368.
Change-Id: I98d72e1291c66bd40d970990e1a377ff2ed0c5d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/236164
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
"Something" changed the names of types in gdb, causing the
pretty-printer matchers to fail to match. This tracks that
change.
Updated runtime-gdb_test.go to include a slice and a channel printing test.
(The straightforward printing of a slicevar doesn't work because
of compiler DWARF problems describing the slicevar, not gdb problems).
Change-Id: I21607a955b9c894f11ecf3763aea2a6dd59a3f42
Reviewed-on: https://go-review.googlesource.com/c/go/+/235926
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When run with stdin == /dev/null and stdout/stderr == pipe (i.e., as
os/exec.Command.CombinedOutput), GDB suffers from a bug
(https://sourceware.org/bugzilla/show_bug.cgi?id=26056) that causes
SIGSEGV when sent a SIGWINCH signal.
Package runtime tests TestEINTR and TestSignalDuringExec both send
SIGWINCH signals to the entire process group, thus including GDB if one
of the GDB tests is running in parallel.
TestEINTR only intends its signals for the current process, so it is
changed to do so. TestSignalDuringExec, really does want its signals to
go to children. However, it does not call t.Parallel(), so it won't run
at the same time as GDB tests.
This is a simple fix, but GDB is vulnerable, so we must be careful not
to add new parallel tests that send SIGWINCH to the entire process
group.
Fixes#39021
Change-Id: I803606fb000f08c65c1b10ec554d4ef6819e5dd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/235557
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
All GDB tests currently ignore non-zero exit statuses. When tests
flakes, we don't even know if GDB exited successfully or not.
Add checks for non-zero exits, which are not expected.
Furthermore, always log the output from GDB. The tests are currently
inconsistent about whether they always log, or only on error.
Updates #39021
Change-Id: I7af1d795fc2fdf58093cb2731d616d4aa44e9996
Reviewed-on: https://go-review.googlesource.com/c/go/+/235282
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This part of the test has been flaky despite repeated attempts to fix it,
and it is unclear what exactly it is testing. Remove it.
Fixes#24616.
Change-Id: If7234f99dd3d3e92f15ccb94ee13e75c6da12537
Reviewed-on: https://go-review.googlesource.com/c/go/+/233942
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Tweak the runtime's GDB python test to try to reduce flake failures.
Background: the intent of the testpoint in question is to make sure
that python-supported commands like "info goroutines" or "goroutine 1
backtrace" work properly. The Go code being run under the debugger as
part of the test is single-threaded, but the test is written assuming
that in addition to the primary goroutine there will be other
background goroutines available (owned by the runtime). The flakiness
seems to crop up the most when requesting a backtrace for one of these
background goroutines; the speculation is that if we catch a
runtime-owned goroutine in an odd state, this could interfere with the
test.
The change in this patch is to explicitly start an additional
goroutine from the main thread, so that when the debugger stops the
main thread we can be sure that there is some other non-main goroutine
in a known state.
This change authored by Josh Bleecher Snyder <josharian@gmail.com>.
Updates #24616.
Change-Id: I45682323d5898e5187c0adada7c5d117e92f403b
Reviewed-on: https://go-review.googlesource.com/c/go/+/226558
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change adds CFA information to the assembly function 'crosscall1'
and reorgnizes its code to establish well-formed prologue and epilogue.
It will fix an infinite callstack issue when debugging cgo program with
GDB on arm64.
Brief root cause analysis:
GDB's aarch64 unwinder parses prologue to determine current frame's size
and previous PC&SP if CFA information is not available.
The unwinder parses the prologue of 'crosscall1' to determine a frame size
of 0x10, then turns to its next frame trying to compute its previous PC&SP
as they are not saved on current frame's stack as per its 'traditional frame
unwind' rules, which ends up getting an endless frame chain like:
[callee] : pc:<pc0>, sp:<sp0>
crosscall1: pc:<pc1>, sp:<sp0>+0x10
[caller] : pc:<pc1>, sp:<sp0>+0x10+0x10
[caller] : pc:<pc1>, sp:<sp0>+0x10+0x10+0x10
...
GDB fails to detect the 'caller' frame is same as 'crosscall1' and terminate
unwinding since SP increases everytime.
Fixes#37238
Change-Id: Ia6bd8555828541a3a61f7dc9b94dfa00775ec52a
Reviewed-on: https://go-review.googlesource.com/c/go/+/226999
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Since the new page allocator, AIX's GDB has trouble running Go programs.
It does work but it can be really slow. Therefore, they are disable when
tests are run with -short.
Updates: #35710
Change-Id: Ibfc4bd2cd9714268f1fe172aaf32a73612e262d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/207919
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For example, can use `goroutine all bt` to dump all goroutines'
information.
Change-Id: I51b547c2b837913e4bdabf0f45b28f09250a3e34
GitHub-Last-Rev: d04dcd4f58
GitHub-Pull-Request: golang/go#26283
Reviewed-on: https://go-review.googlesource.com/c/go/+/122589
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Testing whether cgo is enabled in go/build is not the same as testing
whether the go tool supports cgo. They differ, for example, when using
GOARCH=386 on an amd64 system, as for a cross-build cgo is disabled by default.
Change-Id: Ib59106c92a3131b73ac6a91c0f7658a1769acf73
Reviewed-on: https://go-review.googlesource.com/c/go/+/174098
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Pass "set print thread-events off" to gdb to suppress thread
event prints, like "[New Thread 0xe7b83b40 (LWP 18609)]". We
don't check them, and the extra output may confuse our other
checks, in particular, checkCleanBacktrace.
Hopefully fixes#31569.
Change-Id: I6549e1280da7afa1d2e38da2b2fa7cc18c2f0373
Reviewed-on: https://go-review.googlesource.com/c/go/+/172980
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL adds a new attribute, TOPFRAME, which can be used to mark
functions that should be treated as being at the top of the call
stack. The function `runtime.goexit` has been marked this way on
architectures that use a link register.
This will stop programs that use DWARF to unwind the call stack
from unwinding past `runtime.goexit` on architectures that use a
link register. For example, it eliminates "corrupt stack?"
warnings when generating a backtrace that hits `runtime.goexit`
in GDB on s390x.
Similar code should be added for non-link-register architectures
(i.e. amd64, 386). They mark the top of the call stack slightly
differently to link register architectures so I haven't added
that code (they need to mark "rip" as undefined).
Fixes#24385.
Change-Id: I15b4c69ac75b491daa0acf0d981cb80eb06488de
Reviewed-on: https://go-review.googlesource.com/c/go/+/169726
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TestGdbAutotmpTypes takes more than one minute due to gdb performances.
Therefore, it must be skipped in short mode.
Change-Id: I253ebce62264cc7367c9b0f6ce9c5088a9994641
Reviewed-on: https://go-review.googlesource.com/c/go/+/164339
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In module mode, building the current directory requires a go.mod file
(in order to determine the import path of the package).
Change the tests to pass explicit file arguments instead, since those
can be built in module mode without defining a module.
Updates #30228
Change-Id: I680c658d1f79645f73ad4d1e88189ea50a4852e9
Reviewed-on: https://go-review.googlesource.com/c/162837
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
The in-tree GDB is too old (6.1.1) on all the builders except the
FreeBSD 12.0 one, where it was removed from the base system.
Update #29508
Change-Id: Ib6091cd86440ea005f3f903549a0223a96621a6f
Reviewed-on: https://go-review.googlesource.com/c/156717
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is a simple tweak to allow a bit more mid-stack inlining.
In cases like this:
func f() {
g()
}
We'd really like to inline f into its callers. It can't hurt.
We implement this optimization by making calls a bit cheaper, enough
to afford a single call in the function body, but not 2.
The remaining budget allows for some argument modification, or perhaps
a wrapping conditional:
func f(x int) {
g(x, 0)
}
func f(x int) {
if x > 0 {
g()
}
}
Update #19348
Change-Id: Ifb1ea0dd1db216c3fd5c453c31c3355561fe406f
Reviewed-on: https://go-review.googlesource.com/c/147361
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
This commit skips tests which aren't yet supported on AIX.
nosplit.go is disabled because stackGuardMultiplier is increased for
syscalls.
Change-Id: Ib5ff9a4539c7646bcb6caee159f105ff8a160ad7
Reviewed-on: https://go-review.googlesource.com/c/146939
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
As discussed in golang.org/cl/28499:
Only test that all expected variables are listed in 'info locals' since
different versions of gdb print variables in different order and with
differing amount of information and formats.
Fixes#28499
Change-Id: I76627351170b5fdf2bf8cbf143e54f628b45dc4e
Reviewed-on: https://go-review.googlesource.com/c/146598
Reviewed-by: Heschi Kreinick <heschi@google.com>
Only return a pointer p to the new slices backing array from makeslice.
Makeslice callers then construct sliceheader{p, len, cap} explictly
instead of makeslice returning the slice.
Reduces go binary size by ~0.2%.
Removes 92 (~3.5%) panicindex calls from go binary.
Change-Id: I29b7c3b5fe8b9dcec96e2c43730575071cfe8a94
Reviewed-on: https://go-review.googlesource.com/c/141822
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Previously, some of output from gdb matched with literal string, while
gdb v8.2 print the address of variable (e.g. map key and value) in
output.
This commit fix the regex in testing the output.
Fixes#27608
Change-Id: Ic3fe8280b9f93fda2799116804822616caa66beb
Reviewed-on: https://go-review.googlesource.com/135055
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
