From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22483 invoked by alias); 23 Oct 2003 20:18:35 -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 22476 invoked from network); 23 Oct 2003 20:18:35 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 23 Oct 2003 20:18:35 -0000 Received: by zenia.home (Postfix, from userid 5433) id 2F89A20766; Thu, 23 Oct 2003 15:18:16 -0500 (EST) To: "Larry McCourry" Cc: "Grant Edwards" , Subject: Re: ARM References: <000d01c39992$e2c78f70$6401a8c0@betsy> <20031023183633.GA21462@grante.dsl.visi.com> <000c01c39995$77fd1f40$6401a8c0@betsy> From: Jim Blandy Date: Thu, 23 Oct 2003 20:18:00 -0000 In-Reply-To: <000c01c39995$77fd1f40$6401a8c0@betsy> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00268.txt.bz2 "Larry McCourry" writes: > Does the following not mean that it doesn't work? > from > http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/PROBLEMS?con > tent-type=text/x-cvsweb-markup&cvsroot=src > > ... > > arm-*-* > > GDB's ARM target, in 6.0, has not been updated to use the new frame > mechanism. > > Fortunatly the ARM target, in the GDB's mainline sources, has been > updated so people encountering problems should consider downloading a > more current GDB (http://www.gnu.org/software/gdb/current). I think that note is a bit confusing. It's referring to the way the ARM back end within GDB is written, not to any directly user-visible behavior, like being compatible with some compilers but not others. The interfaces internal to GDB that the architecture-independent and architecture-dependent (i.e., back end) code use to handle stack frames have changed a lot in 6.0. The old interfaces are mostly still around, for compatibility with back ends that nobody has updated yet, but the new interfaces are simpler and more reliable, so in general one suspects that problems in stack frame management might go away if the code were brought up to date. I think that's what the note is trying to say. (If the audience for the PROBLEMS file were GDB developers, then it would be fine as written --- we can't help but notice all the deprecated and new gdbarch methods related to frame handling. But if the audience is GDB users, they'll generally have no idea what the "new frame mechanism" is, but they'll assume they should, leading them to conclude that it is some user-visible change they haven't heard about. Or at least that's what happened here.)