From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22330 invoked by alias); 21 Apr 2003 16:38:48 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22322 invoked from network); 21 Apr 2003 16:38:47 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 21 Apr 2003 16:38:47 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 197eJo-0002cg-00; Mon, 21 Apr 2003 11:39:00 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 197eJZ-0005rX-00; Mon, 21 Apr 2003 12:38:45 -0400 Date: Mon, 21 Apr 2003 16:38:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [just for the record]: new prologue analyzer for S/390 Message-ID: <20030421163845.GA22489@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jim Blandy , gdb-patches@sources.redhat.com References: <3EA41CE6.9000706@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA41CE6.9000706@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00370.txt.bz2 On Mon, Apr 21, 2003 at 12:31:34PM -0400, Andrew Cagney wrote: > >I think this patch shouldn't be committed; I'm just posting it for > >reference. > > > >This patch implements a new prologue analyzer for the S/390. It's > >meant to be general enough to handle the complex prologues GCC emits > >on the S/390, and robust enough to tolerate compiler changes. In my > >experience, it does pretty well, even on optimized code. > > > >However, the S/390 GDB folks at IBM and I agree that GDB on the S/390 > >should move towards using Dwarf 2 CFI and location lists whenever > >possible, and do only minimal prologue analysis to handle those few > >common cases where Dwarf 2 CFI is not available. And it looks to me > >as if the work needed in GDB's core code to make it possible for any > >target to use Dwarf 2 CFI is almost complete. In that light, it > >doesn't make sense to dump a new, large, complex prologue analyzer > >into the code base that will soon be eclipsed by a better solution. > - the need to have gdb behave reasonably well when there is no, or > minimal, debug info The others aside for the moment, I believe this is the best reason to continue to support the prologue analyzers. On the other hand, we're making active progress in providing more and better CFI; and now we support debug info in a separate file from the code; so some day soon I expect that I won't even care how GDB behaves without debug info except for debugging other people's proprietary software to which I don't have source. And in that case (which comes up occasionally) the level of sophistication needed from a prologue analyzer is extremely low. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer