From owner-freebsd-current@FreeBSD.ORG Thu Jun 12 15:48:21 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FB8A37B401 for ; Thu, 12 Jun 2003 15:48:21 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D915D43FA3 for ; Thu, 12 Jun 2003 15:48:19 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id IAA23135; Fri, 13 Jun 2003 08:48:05 +1000 Date: Fri, 13 Jun 2003 08:48:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kris Kennaway In-Reply-To: <20030612080756.GA39730@rot13.obsecurity.org> Message-ID: <20030613082424.F15033@gamplex.bde.org> References: <200306112248.AA655556764@141.com> <20030612045022.GA36033@rot13.obsecurity.org> <20030612073836.GA39115@rot13.obsecurity.org> <20030612080756.GA39730@rot13.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Wiktor Niesiobedzki cc: current@freebsd.org Subject: Re: adsl/pppoe no longer connecting on 5.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 22:48:21 -0000 On Thu, 12 Jun 2003, Kris Kennaway wrote: > On Thu, Jun 12, 2003 at 12:44:51AM -0700, Kris Kennaway wrote: > > > + leal 24(%esp), %eax /* base of newly allocated space */ > > After I figured out what the 24(...) meant ("add 24 to ...") it's > clear that this isn't a fix (except in the special case of PPPoE > support ;-). gcc's builtin inline alloca() is tuning that offset > value at compile-time, so alloca.S is just broken (and has been since > 386BSD, looks like), but it's beyond my pattern-monkey asm skills to > fix. Something like that is needed just to realign the stack frame. Alignment of the (eventual) stack to at least a 16-byte boundary is now required. Since the required alignment depends on the compiler vendor version and flags, and possibly on the calling function's environment, this is impossible to do in all cases. It may be possible to keep current gcc cases working by not disturbing the the stack's alignment mod 16 relative to what it was when the function was called. I don't think misalignment of the stack could cause the current problems. Those are more likely to be caused by "copy possible [sic] saved registers" (see tjr's mail about pushl vs movl to the stack). Bruce