From c792bde9eff10869a503910f9c14ea24047ecafa Mon Sep 17 00:00:00 2001
From: Keith Randall <khr@golang.org>
Date: Mon, 2 Dec 2013 13:07:15 -0800
Subject: runtime: don't use ... formal argument to deferreturn.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/28860043
---
 src/pkg/runtime/panic.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

(limited to 'src/pkg/runtime/panic.c')

diff --git a/src/pkg/runtime/panic.c b/src/pkg/runtime/panic.c
index 8227a444d3..b60547ea10 100644
--- a/src/pkg/runtime/panic.c
+++ b/src/pkg/runtime/panic.c
@@ -157,14 +157,12 @@ runtime·deferproc(int32 siz, FuncVal *fn, ...)
 // is called again and again until there are no more deferred functions.
 // Cannot split the stack because we reuse the caller's frame to
 // call the deferred function.
-//
-// The ... in the prototype keeps the compiler from declaring
-// an argument frame size. deferreturn is a very special function,
-// and if the runtime ever asks for its frame size, that means
-// the traceback routines are probably broken.
+
+// The single argument isn't actually used - it just has its address
+// taken so it can be matched against pending defers.
 #pragma textflag NOSPLIT
 void
-runtime·deferreturn(uintptr arg0, ...)
+runtime·deferreturn(uintptr arg0)
 {
 	Defer *d;
 	byte *argp;
-- 
cgit v1.3