From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27418 invoked by alias); 30 Dec 2006 20:48:34 -0000 Received: (qmail 27409 invoked by uid 22791); 30 Dec 2006 20:48:33 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 30 Dec 2006 20:48:29 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H0l7y-0006nt-UN; Sat, 30 Dec 2006 15:48:27 -0500 Date: Sat, 30 Dec 2006 20:48:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb-patches@sourceware.org, Mark Kettenis Subject: Re: [PATCH] i386_skip_prologue. Message-ID: <20061230204826.GD25539@nevyn.them.org> Mail-Followup-To: Pedro Alves , gdb-patches@sourceware.org, Mark Kettenis References: <455EE79E.6000109@portugalmail.pt> <455EF845.40902@portugalmail.pt> <455F2754.5060703@portugalmail.pt> <20061118163738.GA14800@nevyn.them.org> <457B1D40.7060302@portugalmail.pt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457B1D40.7060302@portugalmail.pt> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00373.txt.bz2 On Sat, Dec 09, 2006 at 08:32:00PM +0000, Pedro Alves wrote: > The i386 targets currently don't look at line number markers > or the symbol table at all in i386_skip_prologue. > > I used the attached patch to test the gcc side of the fix, > (http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00633.html) > > With the gcc patch above applied, this patch fixes all the runto_main issues > on Cygwin. There are a few other FAILs related to breakpoints and main, > but those are testsuite bugs, unrelated to this. I will send patches for > those shortly. As this is an i386-specific change, I'd been hoping Mark Kettenis could take a look at it. Mark, any opinion on this? We've been going back and forth on prologue skipping choices for a long time now. We have at least four options, each with at least two users: - skip_prologue_using_sal - refine_prologue_limit - this simple approach using line numbers, i.e. what you did - sticking to analysis of the instructions Aside from how difficult the analysis is, there's very little target dependent about this. It's a shame we've got so many different ways to do it. Is there a general philosophy we could adopt that would apply to most or all targets? Here's a proposal to get us started: when skipping the prologue to place a breakpoint or finish single stepping (skip_prologue), try to skip to the end of the first sal. But some targets may optionally run their prologue analyzer and make sure it doesn't see anything it objects to - like jumps. That would mean the i386 prologue analyzer would need to know about this new call to __main. When scanning the prologue to build frame unwind information, ignore sals entirely. Scan until we hit the saved PC or until we believe we understand the entire frame. -- Daniel Jacobowitz CodeSourcery