aboutsummaryrefslogtreecommitdiff
path: root/src/pkg/runtime/traceback_arm.c
AgeCommit message (Collapse)Author
2014-09-02runtime: convert traceback*.c to GoRuss Cox
The two converted files were nearly identical. Instead of continuing that duplication, I merged them into a single traceback.go. Tested on arm, amd64, amd64p32, and 386. LGTM=r R=golang-codereviews, remyoudompheng, dave, r CC=dvyukov, golang-codereviews, iant, khr https://golang.org/cl/134200044
2014-09-01runtime: change PC, SP values in Stkframe, Panic, Defer from byte* to uintptrRuss Cox
uintptr is better when translating to Go, and in a few places it's better in C too. LGTM=r R=golang-codereviews, r CC=golang-codereviews, iant, khr https://golang.org/cl/138980043
2014-08-28runtime: convert print.c to GoRuss Cox
LGTM=iant R=golang-codereviews, iant CC=dvyukov, golang-codereviews, khr, r https://golang.org/cl/135930043
2014-08-27runtime: changes to g->atomicstatus (nee status) to support concurrent GCRick Hudson
Every change to g->atomicstatus is now done atomically so that we can ensure that all gs pass through a gc safepoint on demand. This allows the GC to move from one phase to the next safely. In some phases the stack will be scanned. This CL only deals with the infrastructure that allows g->atomicstatus to go from one state to another. Future CLs will deal with scanning and monitoring what phase the GC is in. The major change was to moving to using a Gscan bit to indicate that the status is in a scan state. The only bug fix was in oldstack where I wasn't moving to a Gcopystack state in order to block scanning until the new stack was in place. The proc.go file is waiting for an atomic load instruction. LGTM=rsc R=golang-codereviews, dvyukov, josharian, rsc CC=golang-codereviews, khr https://golang.org/cl/132960044
2014-08-06runtime: turn off 'unexpected return pc' print on arm tracebackRuss Cox
It can happen legitimately if a profiling signal arrives at just the wrong moment. It's harmless. Fixes #8153. LGTM=minux R=golang-codereviews, minux CC=golang-codereviews, iant, r https://golang.org/cl/118670043
2014-07-31runtime: move built-in print routines to go.Keith Randall
Fixes #8297 LGTM=bradfitz R=golang-codereviews, bradfitz, khr, dave, dvyukov CC=golang-codereviews https://golang.org/cl/119240043
2014-07-30runtime: rewrite malloc in Go.Keith Randall
This change introduces gomallocgc, a Go clone of mallocgc. Only a few uses have been moved over, so there are still lots of uses from C. Many of these C uses will be moved over to Go (e.g. in slice.goc), but probably not all. What should remain of C's mallocgc is an open question. LGTM=rsc, dvyukov R=rsc, khr, dave, bradfitz, dvyukov CC=golang-codereviews https://golang.org/cl/108840046
2014-06-26all: remove 'extern register M *m' from runtimeRuss Cox
The runtime has historically held two dedicated values g (current goroutine) and m (current thread) in 'extern register' slots (TLS on x86, real registers backed by TLS on ARM). This CL removes the extern register m; code now uses g->m. On ARM, this frees up the register that formerly held m (R9). This is important for NaCl, because NaCl ARM code cannot use R9 at all. The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected: BenchmarkBinaryTree17 5491374955 5471024381 -0.37% BenchmarkFannkuch11 4357101311 4275174828 -1.88% BenchmarkGobDecode 11029957 11364184 +3.03% BenchmarkGobEncode 6852205 6784822 -0.98% BenchmarkGzip 650795967 650152275 -0.10% BenchmarkGunzip 140962363 141041670 +0.06% BenchmarkHTTPClientServer 71581 73081 +2.10% BenchmarkJSONEncode 31928079 31913356 -0.05% BenchmarkJSONDecode 117470065 113689916 -3.22% BenchmarkMandelbrot200 6008923 5998712 -0.17% BenchmarkGoParse 6310917 6327487 +0.26% BenchmarkRegexpMatchMedium_1K 114568 114763 +0.17% BenchmarkRegexpMatchHard_1K 168977 169244 +0.16% BenchmarkRevcomp 935294971 914060918 -2.27% BenchmarkTemplate 145917123 148186096 +1.55% Minux previous reported larger variations, but these were caused by run-to-run noise, not repeatable slowdowns. Actual code changes by Minux. I only did the docs and the benchmarking. LGTM=dvyukov, iant, minux R=minux, josharian, iant, dave, bradfitz, dvyukov CC=golang-codereviews https://golang.org/cl/109050043
2014-06-12runtime: do not trace past jmpdefer during pprof traceback on armRuss Cox
jmpdefer modifies PC, SP, and LR, and not atomically, so walking past jmpdefer will often end up in a state where the three are not a consistent execution snapshot. This was causing warning messages a few frames later when the traceback realized it was confused, but given the right memory it could easily crash instead. Update #8153 LGTM=minux, iant R=golang-codereviews, minux, iant CC=golang-codereviews, r https://golang.org/cl/107970043
2014-06-01runtime: fix correctness test at end of tracebackRuss Cox
We were requiring that the defer stack and the panic stack be completely processed, thinking that if any were left over the stack scan and the defer stack/panic stack must be out of sync. It turns out that the panic stack may well have leftover entries in some situations, and that's okay. Fixes #8132. LGTM=minux, r R=golang-codereviews, minux, r CC=golang-codereviews, iant, khr https://golang.org/cl/100900044
2014-05-31runtime: make continuation pc available to stack walkRuss Cox
The 'continuation pc' is where the frame will continue execution, if anywhere. For a frame that stopped execution due to a CALL instruction, the continuation pc is immediately after the CALL. But for a frame that stopped execution due to a fault, the continuation pc is the pc after the most recent CALL to deferproc in that frame, or else 0. That is where execution will continue, if anywhere. The liveness information is only recorded for CALL instructions. This change makes sure that we never look for liveness information except for CALL instructions. Using a valid PC fixes crashes when a garbage collection or stack copying tries to process a stack frame that has faulted. Record continuation pc in heapdump (format change). Fixes #8048. LGTM=iant, khr R=khr, iant, dvyukov CC=golang-codereviews, r https://golang.org/cl/100870044
2014-04-02runtime: print up to 10 words of argumentsRuss Cox
The old limit of 5 was chosen because we didn't actually know how many bytes of arguments there were; 5 was a halfway point between printing some useful information and looking ridiculous. Now we know how many bytes of arguments there are, and we stop the printing when we reach that point, so the "looking ridiculous" case doesn't happen anymore: we only print actual argument words. The cutoff now serves only to truncate very long (but real) argument lists. In multiple debugging sessions recently (completely unrelated bugs) I have been frustrated by not seeing more of the long argument lists: 5 words is only 2.5 interface values or strings, and not even 2 slices. Double the max amount we'll show. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews, iant, r https://golang.org/cl/83850043
2014-03-27runtime: enable 'bad pointer' check during garbage collection of Go stack framesRuss Cox
This is the same check we use during stack copying. The check cannot be applied to C stack frames, even though we do emit pointer bitmaps for the arguments, because (1) the pointer bitmaps assume all arguments are always live, not true of outputs during the prologue, and (2) the pointer bitmaps encode interface values as pointer pairs, not true of interfaces holding integers. For the rest of the frames, however, we should hold ourselves to the rule that a pointer marked live really is initialized. The interface scanning already implicitly checks this because it interprets the type word as a valid type pointer. This may slow things down a little because of the extra loads. Or it may speed things up because we don't bother enqueuing nil pointers anymore. Enough of the rest of the system is slow right now that we can't measure it meaningfully. Enable for now, even if it is slow, to shake out bugs in the liveness bitmaps, and then decide whether to turn it off for the Go 1.3 release (issue 7650 reminds us to do this). The new m->traceback field lets us force printing of fp= values on all goroutine stack traces when we detect a bad pointer. This makes it easier to understand exactly where in the frame the bad pointer is, so that we can trace it back to a specific variable and determine what is wrong. Update #7650 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/80860044
2014-02-26runtime: grow stack by copyingKeith Randall
On stack overflow, if all frames on the stack are copyable, we copy the frames to a new stack twice as large as the old one. During GC, if a G is using less than 1/4 of its stack, copy the stack to a stack half its size. TODO - Do something about C frames. When a C frame is in the stack segment, it isn't copyable. We allocate a new segment in this case. - For idempotent C code, we can abort it, copy the stack, then retry. I'm working on a separate CL for this. - For other C code, we can raise the stackguard to the lowest Go frame so the next call that Go frame makes triggers a copy, which will then succeed. - Pick a starting stack size? The plan is that eventually we reach a point where the stack contains only copyable frames. LGTM=rsc R=dvyukov, rsc CC=golang-codereviews https://golang.org/cl/54650044
2014-01-23runtime: Print elision message if we skipped frames on traceback.Keith Randall
Fixes bug 7180 R=golang-codereviews, dvyukov CC=golang-codereviews, gri https://golang.org/cl/55810044
2013-12-13runtime: fix crash in runtime.GoroutineProfileRuss Cox
This is a possible Go 1.2.1 candidate. Fixes #6946. R=iant, r CC=golang-dev https://golang.org/cl/41640043
2013-10-31cmd/5l, runtime: fix divide for profiling tracebacks on ARMRuss Cox
Two bugs: 1. The first iteration of the traceback always uses LR when provided, which it is (only) during a profiling signal, but in fact LR is correct only if the stack frame has not been allocated yet. Otherwise an intervening call may have changed LR, and the saved copy in the stack frame should be used. Fix in traceback_arm.c. 2. The division runtime call adds 8 bytes to the stack. In order to keep the traceback routines happy, it must copy the saved LR into the new 0(SP). Change SUB $8, SP into MOVW 0(SP), R11 // r11 is temporary, for use by linker MOVW.W R11, -8(SP) to update SP and 0(SP) atomically, so that the traceback always sees a saved LR at 0(SP). Fixes #6681. R=golang-dev, r CC=golang-dev https://golang.org/cl/19910044
2013-10-31undo CL 19810043 / 352f3b7c9664Russ Cox
The CL causes misc/cgo/test to fail randomly. I suspect that the problem is the use of a division instruction in usleep, which can be called while trying to acquire an m and therefore cannot store the denominator in m. The solution to that would be to rewrite the code to use a magic multiply instead of a divide, but now we're getting pretty far off the original code. Go back to the original in preparation for a different, less efficient but simpler fix. ««« original CL description cmd/5l, runtime: make ARM integer division profiler-friendly The implementation of division constructed non-standard stack frames that could not be handled by the traceback routines. CL 13239052 left the frames non-standard but fixed them for the specific case of a divide-by-zero panic. A profiling signal can arrive at any time, so that fix is not sufficient. Change the division to store the extra argument in the M struct instead of in a new stack slot. That keeps the frames bog standard at all times. Also fix a related bug in the traceback code: when starting a traceback, the LR register should be ignored if the current function has already allocated its stack frame and saved the original LR on the stack. The stack copy should be used, as the LR register may have been modified. Combined, these make the torture test from issue 6681 pass. Fixes #6681. R=golang-dev, r, josharian CC=golang-dev https://golang.org/cl/19810043 »»» TBR=r CC=golang-dev https://golang.org/cl/20350043
2013-10-30cmd/5l, runtime: make ARM integer division profiler-friendlyRuss Cox
The implementation of division constructed non-standard stack frames that could not be handled by the traceback routines. CL 13239052 left the frames non-standard but fixed them for the specific case of a divide-by-zero panic. A profiling signal can arrive at any time, so that fix is not sufficient. Change the division to store the extra argument in the M struct instead of in a new stack slot. That keeps the frames bog standard at all times. Also fix a related bug in the traceback code: when starting a traceback, the LR register should be ignored if the current function has already allocated its stack frame and saved the original LR on the stack. The stack copy should be used, as the LR register may have been modified. Combined, these make the torture test from issue 6681 pass. Fixes #6681. R=golang-dev, r, josharian CC=golang-dev https://golang.org/cl/19810043
2013-09-11runtime: show m stack during crash on m stackRuss Cox
The various throwing > 0 finish a change started in a previous CL, which sets throwing = -1 to mean "don't show the internals". That gets set during the "all goroutines are asleep - deadlock!" crash, and it should also be set during any other expected crash that does not indicate a problem within the runtime. Most runtime.throw do indicate a problem within the runtime, however, so we should be able to enumerate the ones that should be silent. The goroutine sleeping deadlock is the only one I can think of. Update #5139 R=golang-dev, iant CC=golang-dev https://golang.org/cl/13662043
2013-08-06runtime: use gcpc/gcsp during traceback of goroutines in syscallsDmitriy Vyukov
gcpc/gcsp are used by GC in similar situation. gcpc/gcsp are also more stable than gp->sched, because gp->sched is mutated by entersyscall/exitsyscall in morestack and mcall. So it has higher chances of being inconsistent. Also, rename gcpc/gcsp to syscallpc/syscallsp. This is the same as reverted change 12250043 with save marked as textflag 7. The problem was that if save calls morestack, then subsequent lessstack spoils g->sched.pc/sp. And that bad values were remembered in g->syscallpc/sp. Entersyscallblock had the same problem, but it was never triggered to date. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/12478043
2013-08-05undo CL 12250043 / e911f94c4902Dmitriy Vyukov
Break all 386 builders. ««« original CL description runtime: use gcpc/gcsp during traceback of goroutines in syscalls gcpc/gcsp are used by GC in similar situation. gcpc/gcsp are also more stable than gp->sched, because gp->sched is mutated by entersyscall/exitsyscall in morestack and mcall. So it has higher chances of being inconsistent. Also, rename gcpc/gcsp to syscallpc/syscallsp. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/12250043 »»» R=rsc CC=golang-dev https://golang.org/cl/12424045
2013-08-05runtime: use gcpc/gcsp during traceback of goroutines in syscallsDmitriy Vyukov
gcpc/gcsp are used by GC in similar situation. gcpc/gcsp are also more stable than gp->sched, because gp->sched is mutated by entersyscall/exitsyscall in morestack and mcall. So it has higher chances of being inconsistent. Also, rename gcpc/gcsp to syscallpc/syscallsp. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/12250043
2013-08-01runtime: print "created by" for running goroutines in tracebackDmitriy Vyukov
This allows to at least determine goroutine "identity". Now it looks like: goroutine 12 [running]: goroutine running on other thread; stack unavailable created by testing.RunTests src/pkg/testing/testing.go:440 +0x88e R=golang-dev, r, rsc CC=golang-dev https://golang.org/cl/12248043
2013-08-01runtime: remove unused varDmitriy Vyukov
R=golang-dev, r CC=golang-dev https://golang.org/cl/12249043
2013-07-31cmd/gc: record argument size for all indirect function callsDmitriy Vyukov
This is required to properly unwind reflect.methodValueCall/makeFuncStub. Fixes #5954. Stats for 'go install std': 61849 total INSTCALL 24655 currently have ArgSize metadata 27278 have ArgSize metadata with this change godoc size before: 11351888, after: 11364288 R=golang-dev, rsc CC=golang-dev https://golang.org/cl/12163043
2013-07-19runtime: use funcdata to supply garbage collection informationRuss Cox
This CL introduces a FUNCDATA number for runtime-specific garbage collection metadata, changes the C and Go compilers to emit that metadata, and changes the runtime to expect it. The old pseudo-instructions that carried this information are gone, as is the linker code to process them. R=golang-dev, dvyukov, cshapiro CC=golang-dev https://golang.org/cl/11406044
2013-07-19runtime: cleanup: use ArgsSizeUnknown to mark all functionsKeith Randall
whose argument size is unknown (C vararg functions, and assembly code without an explicit specification). We used to use 0 to mean "unknown" and 1 to mean "zero". Now we use ArgsSizeUnknown (0x80000000) to mean "unknown". R=golang-dev, rsc CC=golang-dev https://golang.org/cl/11590043
2013-07-18runtime: handle morestack/lessstack in stack traceRuss Cox
If we start a garbage collection on g0 during a stack split or unsplit, we'll see morestack or lessstack at the top of the stack. Record an argument frame size for those, and record that they terminate the stack. R=golang-dev, dvyukov CC=golang-dev https://golang.org/cl/11533043
2013-07-18cmd/ld, runtime: use new contiguous pcln tableRuss Cox
R=golang-dev, r, dave CC=golang-dev https://golang.org/cl/11494043
2013-07-17runtime: use new frame argument size informationRuss Cox
With this CL, I believe the runtime always knows the frame size during the gc walk. There is no fallback to "assume entire stack frame of caller" anymore. R=golang-dev, khr, cshapiro, dvyukov CC=golang-dev https://golang.org/cl/11374044
2013-07-16cmd/ld, runtime: new in-memory symbol table formatRuss Cox
Design at http://golang.org/s/go12symtab. This enables some cleanup of the garbage collector metadata that will be done in future CLs. This CL does not move the old symtab and pclntab back into an unmapped section of the file. That's a bit tricky and will be done separately. Fixes #4020. R=golang-dev, dave, cshapiro, iant, r CC=golang-dev, nigeltao https://golang.org/cl/11085043
2013-07-11runtime: adjust traceback for new preemptive realityDmitriy Vyukov
Currently it crashes as follows: fatal error: unknown pc ... goroutine 71698 [runnable]: runtime.racegoend() src/pkg/runtime/race.c:171 runtime.goexit() src/pkg/runtime/proc.c:1276 +0x9 created by runtime_test.testConcurrentReadsAfterGrowth src/pkg/runtime/map_test.go:264 +0x332 R=golang-dev, rsc CC=golang-dev https://golang.org/cl/10674047
2013-06-27runtime: fix argument printing during tracebackDmitriy Vyukov
Current code can print more arguments than necessary and also incorrectly prints "...". Update #5723. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/10689043
2013-06-27runtime: record proper goroutine state during stack splitRuss Cox
Until now, the goroutine state has been scattered during the execution of newstack and oldstack. It's all there, and those routines know how to get back to a working goroutine, but other pieces of the system, like stack traces, do not. If something does interrupt the newstack or oldstack execution, the rest of the system can't understand the goroutine. For example, if newstack decides there is an overflow and calls throw, the stack tracer wouldn't dump the goroutine correctly. For newstack to save a useful state snapshot, it needs to be able to rewind the PC in the function that triggered the split back to the beginning of the function. (The PC is a few instructions in, just after the call to morestack.) To make that possible, we change the prologues to insert a jmp back to the beginning of the function after the call to morestack. That is, the prologue used to be roughly: TEXT myfunc check for split jmpcond nosplit call morestack nosplit: sub $xxx, sp Now an extra instruction is inserted after the call: TEXT myfunc start: check for split jmpcond nosplit call morestack jmp start nosplit: sub $xxx, sp The jmp is not executed directly. It is decoded and simulated by runtime.rewindmorestack to discover the beginning of the function, and then the call to morestack returns directly to the start label instead of to the jump instruction. So logically the jmp is still executed, just not by the cpu. The prologue thus repeats in the case of a function that needs a stack split, but against the cost of the split itself, the extra few instructions are noise. The repeated prologue has the nice effect of making a stack split double-check that the new stack is big enough: if morestack happens to return on a too-small stack, we'll now notice before corruption happens. The ability for newstack to rewind to the beginning of the function should help preemption too. If newstack decides that it was called for preemption instead of a stack split, it now has the goroutine state correctly paused if rescheduling is needed, and when the goroutine can run again, it can return to the start label on its original stack and re-execute the split check. Here is an example of a split stack overflow showing the full trace, without any special cases in the stack printer. (This one was triggered by making the split check incorrect.) runtime: newstack framesize=0x0 argsize=0x18 sp=0x6aebd0 stack=[0x6b0000, 0x6b0fa0] morebuf={pc:0x69f5b sp:0x6aebd8 lr:0x0} sched={pc:0x68880 sp:0x6aebd0 lr:0x0 ctxt:0x34e700} runtime: split stack overflow: 0x6aebd0 < 0x6b0000 fatal error: runtime: split stack overflow goroutine 1 [stack split]: runtime.mallocgc(0x290, 0x100000000, 0x1) /Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:21 fp=0x6aebd8 runtime.new() /Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:682 +0x5b fp=0x6aec08 go/build.(*Context).Import(0x5ae340, 0xc210030c71, 0xa, 0xc2100b4380, 0x1b, ...) /Users/rsc/g/go/src/pkg/go/build/build.go:424 +0x3a fp=0x6b00a0 main.loadImport(0xc210030c71, 0xa, 0xc2100b4380, 0x1b, 0xc2100b42c0, ...) /Users/rsc/g/go/src/cmd/go/pkg.go:249 +0x371 fp=0x6b01a8 main.(*Package).load(0xc21017c800, 0xc2100b42c0, 0xc2101828c0, 0x0, 0x0, ...) /Users/rsc/g/go/src/cmd/go/pkg.go:431 +0x2801 fp=0x6b0c98 main.loadPackage(0x369040, 0x7, 0xc2100b42c0, 0x0) /Users/rsc/g/go/src/cmd/go/pkg.go:709 +0x857 fp=0x6b0f80 ----- stack segment boundary ----- main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc2100e6c00, 0xc2100e5750, ...) /Users/rsc/g/go/src/cmd/go/build.go:539 +0x437 fp=0x6b14a0 main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc21015b400, 0x2, ...) /Users/rsc/g/go/src/cmd/go/build.go:528 +0x1d2 fp=0x6b1658 main.(*builder).test(0xc2100902a0, 0xc210092000, 0x0, 0x0, 0xc21008ff60, ...) /Users/rsc/g/go/src/cmd/go/test.go:622 +0x1b53 fp=0x6b1f68 ----- stack segment boundary ----- main.runTest(0x5a6b20, 0xc21000a020, 0x2, 0x2) /Users/rsc/g/go/src/cmd/go/test.go:366 +0xd09 fp=0x6a5cf0 main.main() /Users/rsc/g/go/src/cmd/go/main.go:161 +0x4f9 fp=0x6a5f78 runtime.main() /Users/rsc/g/go/src/pkg/runtime/proc.c:183 +0x92 fp=0x6a5fa0 runtime.goexit() /Users/rsc/g/go/src/pkg/runtime/proc.c:1266 fp=0x6a5fa8 And here is a seg fault during oldstack: SIGSEGV: segmentation violation PC=0x1b2a6 runtime.oldstack() /Users/rsc/g/go/src/pkg/runtime/stack.c:159 +0x76 runtime.lessstack() /Users/rsc/g/go/src/pkg/runtime/asm_amd64.s:270 +0x22 goroutine 1 [stack unsplit]: fmt.(*pp).printArg(0x2102e64e0, 0xe5c80, 0x2102c9220, 0x73, 0x0, ...) /Users/rsc/g/go/src/pkg/fmt/print.go:818 +0x3d3 fp=0x221031e6f8 fmt.(*pp).doPrintf(0x2102e64e0, 0x12fb20, 0x2, 0x221031eb98, 0x1, ...) /Users/rsc/g/go/src/pkg/fmt/print.go:1183 +0x15cb fp=0x221031eaf0 fmt.Sprintf(0x12fb20, 0x2, 0x221031eb98, 0x1, 0x1, ...) /Users/rsc/g/go/src/pkg/fmt/print.go:234 +0x67 fp=0x221031eb40 flag.(*stringValue).String(0x2102c9210, 0x1, 0x0) /Users/rsc/g/go/src/pkg/flag/flag.go:180 +0xb3 fp=0x221031ebb0 flag.(*FlagSet).Var(0x2102f6000, 0x293d38, 0x2102c9210, 0x143490, 0xa, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:633 +0x40 fp=0x221031eca0 flag.(*FlagSet).StringVar(0x2102f6000, 0x2102c9210, 0x143490, 0xa, 0x12fa60, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:550 +0x91 fp=0x221031ece8 flag.(*FlagSet).String(0x2102f6000, 0x143490, 0xa, 0x12fa60, 0x0, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:563 +0x87 fp=0x221031ed38 flag.String(0x143490, 0xa, 0x12fa60, 0x0, 0x161950, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:570 +0x6b fp=0x221031ed80 testing.init() /Users/rsc/g/go/src/pkg/testing/testing.go:-531 +0xbb fp=0x221031edc0 strings_test.init() /Users/rsc/g/go/src/pkg/strings/strings_test.go:1115 +0x62 fp=0x221031ef70 main.init() strings/_test/_testmain.go:90 +0x3d fp=0x221031ef78 runtime.main() /Users/rsc/g/go/src/pkg/runtime/proc.c:180 +0x8a fp=0x221031efa0 runtime.goexit() /Users/rsc/g/go/src/pkg/runtime/proc.c:1269 fp=0x221031efa8 goroutine 2 [runnable]: runtime.MHeap_Scavenger() /Users/rsc/g/go/src/pkg/runtime/mheap.c:438 runtime.goexit() /Users/rsc/g/go/src/pkg/runtime/proc.c:1269 created by runtime.main /Users/rsc/g/go/src/pkg/runtime/proc.c:166 rax 0x23ccc0 rbx 0x23ccc0 rcx 0x0 rdx 0x38 rdi 0x2102c0170 rsi 0x221032cfe0 rbp 0x221032cfa0 rsp 0x7fff5fbff5b0 r8 0x2102c0120 r9 0x221032cfa0 r10 0x221032c000 r11 0x104ce8 r12 0xe5c80 r13 0x1be82baac718 r14 0x13091135f7d69200 r15 0x0 rip 0x1b2a6 rflags 0x10246 cs 0x2b fs 0x0 gs 0x0 Fixes #5723. R=r, dvyukov, go.peter.90, dave, iant CC=golang-dev https://golang.org/cl/10360048
2013-06-12runtime: add lr, ctxt, ret to GobufRuss Cox
Add gostartcall and gostartcallfn. The old gogocall = gostartcall + gogo. The old gogocallfn = gostartcallfn + gogo. R=dvyukov, minux.ma CC=golang-dev https://golang.org/cl/10036044
2013-06-12runtime: adjust traceback / garbage collector boundaryRuss Cox
The garbage collection routine addframeroots is duplicating logic in the traceback routine that calls it, sometimes correctly, sometimes incorrectly, sometimes incompletely. Pass necessary information to addframeroots instead of deriving it anew. Should make addframeroots significantly more robust. It's certainly smaller. Also try to standardize on uintptr for saved pc, sp values. Will make CL 10036044 trivial. R=golang-dev, dave, dvyukov CC=golang-dev https://golang.org/cl/10169045
2013-03-28cmd/ld, runtime: restrict stack root scan to locals and argumentsCarl Shapiro
Updates #5134 R=golang-dev, bradfitz, cshapiro, daniel.morsing, ality, iant CC=golang-dev https://golang.org/cl/8022044
2013-03-26runtime: ensure forward progress when unwinding an arm stack frameCarl Shapiro
The arm gentraceback mishandled frame linkage values pointing to the assembly return function. This function is special as its frame size is zero and it contains only one instruction. These conditions would preserve the frame pointer and result in an off by one error when unwinding the caller. Fixes #5124 R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/8023043
2013-03-05undo CL 7301062 / 9742f722b558Russ Cox
broke arm garbage collector traceback_arm fails with a missing pc. It needs CL 7494043. But that only makes the build break later, this time with "invalid freelist". Roll back until it can be fixed correctly. ««« original CL description runtime: restrict stack root scan to locals and arguments R=rsc CC=golang-dev https://golang.org/cl/7301062 »»» R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/7493044
2013-03-04runtime: restrict stack root scan to locals and argumentsCarl Shapiro
R=rsc CC=golang-dev https://golang.org/cl/7301062
2013-02-22runtime: delete old closure codeRuss Cox
Step 4 of http://golang.org/s/go11func. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/7393049
2013-02-21cmd/gc, reflect, runtime: switch to indirect func value representationRuss Cox
Step 1 of http://golang.org/s/go11func. R=golang-dev, r, daniel.morsing, remyoudompheng CC=golang-dev https://golang.org/cl/7393045
2013-02-21cmd/5g, cmd/5l, cmd/6l, cmd/8l, cmd/gc, cmd/ld, runtime: accurate args and ↵Carl Shapiro
locals information Previously, the func structure contained an inaccurate value for the args member and a 0 value for the locals member. This change populates the func structure with args and locals values computed by the compiler. The number of args was already available in the ATEXT instruction. The number of locals is now passed through in the new ALOCALS instruction. This change also switches the unit of args and locals to be bytes, just like the frame member, instead of 32-bit words. R=golang-dev, bradfitz, cshapiro, dave, rsc CC=golang-dev https://golang.org/cl/7399045
2013-02-15runtime: show frame pointer values during throwRuss Cox
Should help if stack overflows start happening again. Fixes #3582. R=golang-dev, iant CC=golang-dev https://golang.org/cl/7311098
2013-02-15runtime: allocate heap metadata at run timeRuss Cox
Before, the mheap structure was in the bss, but it's quite large (today, 256 MB, much of which is never actually paged in), and it makes Go binaries run afoul of exec-time bss size limits on some BSD systems. Fixes #4447. R=golang-dev, dave, minux.ma, remyoudompheng, iant CC=golang-dev https://golang.org/cl/7307122
2013-02-08runtime: fix build for Linux/ARMShenghou Ma
R=dave, rsc CC=golang-dev https://golang.org/cl/7299055
2013-02-06runtime: save LR to stack when panicking to handle leaf function tracebackShenghou Ma
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/7289047
2013-02-01runtime: cgo-related fixesRuss Cox
* Separate internal and external LockOSThread, for cgo safety. * Show goroutine that made faulting cgo call. * Never start a panic due to a signal caused by a cgo call. Fixes #3774. Fixes #3775. Fixes #3797. R=golang-dev, iant CC=golang-dev https://golang.org/cl/7228081
2013-01-29runtime: clear up lr commentsRuss Cox
R=cshapiro CC=golang-dev https://golang.org/cl/7230052
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 04:50:55 +0000