From owner-freebsd-mips@FreeBSD.ORG Thu Jul 30 23:50:30 2009 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8340A106564A for ; Thu, 30 Jul 2009 23:50:30 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from core.tav.kiev.ua (tavex.colocall.com [62.149.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF818FC16 for ; Thu, 30 Jul 2009 23:50:29 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from [76.77.86.2] (helo=[10.80.5.136]) by core.tav.kiev.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1MWfOT-000KHM-O1; Fri, 31 Jul 2009 02:50:42 +0300 Message-ID: <4A7231BE.3090703@freebsd.org> Date: Thu, 30 Jul 2009 16:50:22 -0700 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Neelkanth Natu References: <681122.20462.qm@web34407.mail.mud.yahoo.com> In-Reply-To: <681122.20462.qm@web34407.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Core-Spam-Level: - X-Core-Spam-Report: Spam detection software, running on the system "core.tav.kiev.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Neelkanth Natu wrote: > Hi, > > This diff fixes a problem I encountered with ddb backtrace. > > The problem with looking for just 'j ra' instruction to find out the > end of the previous function is that gcc does not emit that > instruction for functions that are not supposed to return (for e.g. > boot() or panic()). This is especially bad because the backtrace > generated by calling panic() is unusable because boot() is right > above panic() in the object file. > > This change looks for start of a function by looking for an instruction > of the form: addiu sp, sp, - > > It so happens that gcc emits this as the first instruction for all > functions that use the stack. We keep the 'j ra' method around for > functions that don't use the stack. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] 0.8 AWL AWL: From: address is in the auto white-list Cc: freebsd-mips@freebsd.org Subject: Re: Diffs to fix ddb backtrace X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 23:50:30 -0000 Neelkanth Natu wrote: > Hi, > > This diff fixes a problem I encountered with ddb backtrace. > > The problem with looking for just 'j ra' instruction to find out the > end of the previous function is that gcc does not emit that > instruction for functions that are not supposed to return (for e.g. > boot() or panic()). This is especially bad because the backtrace > generated by calling panic() is unusable because boot() is right > above panic() in the object file. > > This change looks for start of a function by looking for an instruction > of the form: addiu sp,sp,- > > It so happens that gcc emits this as the first instruction for all > functions that use the stack. We keep the 'j ra' method around for > functions that don't use the stack. Thanks! This is something I've always wanted to do but never did :) commited to projects/mips