From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20021 invoked by alias); 3 Mar 2003 18:45:44 -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 20005 invoked from network); 3 Mar 2003 18:45:43 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 3 Mar 2003 18:45:43 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D9D072A9C; Mon, 3 Mar 2003 13:45:41 -0500 (EST) Message-ID: <3E63A2D5.8010007@redhat.com> Date: Mon, 03 Mar 2003 18:45:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb@sources.redhat.com, cfg@redhat.com, thropej@wasavisystems.com, rjl@sco.com, peter.schauer@regent.e-technik.tu-muenchen.de, brobecker@act-europe.fr Subject: Re: HEADS UP: converting the i386 to the new frame unwinding stuff References: <200303021731.h22HVsEl019548@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00052.txt.bz2 > Folks, > > I've been working on making the i386 target use the new frame > unwinding stuff. I'm at a stage where I'm seeing no regressions on > i386-unknown-freebsd4.7. So I'd like to check my work in, in the not > too distant future. However, this is probably going to cause some > fallout amongst the other targets. > > As far as I can see *BSD, GNU/Linux, GNU/Hurd, the various System > V-derived systems (including Solaris 2.x), Netware, DJGPP, Cygwin, and > the various embedded targets should be fine. > > My changes will break the various Sequent Symmetry targets, and I'll > probably leave them broken (which they probably already are). > > I'll see whether I can fix LynxOS before actually committing the > patch. > > However, Interix will need some serious work. The frame methods it > redefines will have to be replaced by *_frame_pc_unwind and > *_frame_id_unwind functions. Should I leave that to you Joel, or > would you like me to write some initial versions and leave the > necessary testing and bug-fixing to you? Mark, Per several recent discussions, can you create a branch and commit it to that. That way I can look at it now (regardless of your intended commit schedule)? I've started writing up the doco and in doing it, I suspect I may have found an `off by one' error with the unwinder cache. Having a second implementation using the current code should help sort this out. Andrew (1) The best way of explaining the problem is to document how things work.