From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21025 invoked by alias); 21 Jun 2004 07:54:23 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20775 invoked from network); 21 Jun 2004 07:54:22 -0000 Received: from unknown (HELO moutng.kundenserver.de) (212.227.126.173) by sourceware.org with SMTP; 21 Jun 2004 07:54:22 -0000 Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BcJd1-0004SO-00; Mon, 21 Jun 2004 09:54:07 +0200 Received: from [217.235.218.249] (helo=[217.235.218.249]) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BcJd0-0005gm-00; Mon, 21 Jun 2004 09:54:06 +0200 Message-ID: <40D69400.6090500@kay-mueller.de> Date: Mon, 21 Jun 2004 07:54:00 -0000 From: Michael Mueller User-Agent: Mozilla/5.0 MIME-Version: 1.0 To: Andrew Cagney CC: gdb@sources.redhat.com Subject: Re: Post GDB 6.2, require new frame code References: <40D34274.50803@gnu.org> In-Reply-To: <40D34274.50803@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:acfe4e233830c7fd36d26ada4c2bf87e X-SW-Source: 2004-06/txt/msg00204.txt.bz2 The new frame infrastructure is dwarf2 based if I understand that correctly. Does that mean that all stabs support will go away after 6.2? (I'm using gdb to debug Sun C compiled programs on Solaris/SPARC. The current version Sun C 5.5 can output dwarf2 but the default still is stabs and it seems they just have started the transition to dwarf2). Michael Andrew Cagney wrote: > GDB's new frame infrastructure was introduced more than a year ago > (dwarf2-frame added May '03) and then included in the 6.0 and 6.1 > releases. Since that introduction, we've seen: > > alpha ARM AVR CRIS d10v FRV > PA-RISC i386 ia64 m32r m68hcll > m68k m88k mips ppc s390 sh4 > sparc vax > > all updated to this new framework. Unfortunately, though, we're still > left with a few architectures relying on the old framework. > > We're now faced with the problem of what to do with the remaining > architectures. The choices I see are: > > - continue to support the legacy framework > > - convert the remaining architectures > > - phase out the remaining architectures > > So as to avoid the problem of this dragging on indefinitely, we need to > establish a clear schedule by which all architectures are expected to > have been updated. To that end: > > - make GDB 6.2 the last release to support the legacy frame code > > - in 6.2 NEWS, list unconverted architectures as about to be obsoleted > > - Post 6.2 release, obsolete any remaining architectures > > comments, > Andrew > > >