From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2469 invoked by alias); 4 Apr 2008 17:37:33 -0000 Received: (qmail 2455 invoked by uid 22791); 4 Apr 2008 17:37:33 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 04 Apr 2008 17:37:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8DCCB2A9D6C; Fri, 4 Apr 2008 13:37:13 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MqALupE6jpDs; Fri, 4 Apr 2008 13:37:13 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4BB0B2AA0E1; Fri, 4 Apr 2008 13:37:13 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 9192EE7ACD; Fri, 4 Apr 2008 10:37:10 -0700 (PDT) Date: Fri, 04 Apr 2008 17:53:00 -0000 From: Joel Brobecker To: gdb@sourceware.org, Mark Kettenis , Ulrich Weigand Subject: Re: [RFC] Using values to handle unwinding Message-ID: <20080404173710.GE24753@adacore.com> References: <20071017160350.GA26804@caradoc.them.org> <20080331220500.GA21611@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080331220500.GA21611@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00044.txt.bz2 > Thoughts? I read the first patch (register values) pretty carefully, the second one (frame unwinding using struct value & using this_frame instead of next_frame) as carefully as I could, and skimed the other few patches. Overall, it looks pretty nice. I think it would be very valuable if others took the time to look at them, I had to spend a lot of time to understand them, and even now I'm sure there are things I missed. > I'd love comments on the patches, the overall approach, and how to > proceed. Ideally, we check this in (breaking many targets), update > each target completely as someone needs that target, and make sure all > targets are updated by the next release of GDB. I personally use > amd64, i386, arm, mips, m68k, and powerpc; so I'm pretty likely to > update all of those (mechanically). I'll do the laggards before the > next release too, but not right this minute. I would appreciate > assistance with other targets :-) You said "mechanically" - does it mean you are not able to test some of the targets you listed? I can help (including testing) with: hppa, ia64, sparc and powerpc (aix). I would prefer if you took care of mips if you're able to test that. In terms of other architectures that no one volunteers to convert, we can split them among ourselves, and perform mechanical conversions. We can use a second pair of eyes as our means of testing... In terms of how to proceed, I don't mind if we temporarily break some targets. -- Joel