From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14929 invoked by alias); 21 Apr 2003 21:54:53 -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 14912 invoked from network); 21 Apr 2003 21:54:50 -0000 Received: from unknown (HELO zenia.red-bean.com) (12.222.151.100) by sources.redhat.com with SMTP; 21 Apr 2003 21:54:50 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h3LLviFq004732; Mon, 21 Apr 2003 16:57:44 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h3LLvhOI004728; Mon, 21 Apr 2003 16:57:43 -0500 To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [just for the record]: new prologue analyzer for S/390 References: <3EA41CE6.9000706@redhat.com> From: Jim Blandy Date: Mon, 21 Apr 2003 21:54:00 -0000 In-Reply-To: <3EA41CE6.9000706@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.95 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00381.txt.bz2 Andrew Cagney writes: > It is important to ensure that all technical decisions related to GDB > are discussed here, in this forum. Issues, specific to this change, > that come to mind, include: I think it's okay to chat with folks off-line to get their thoughts on a topic, as long as the decisions are made here. I haven't sworn on a bible not to commit the patch, just adjusted my presentation of it so as not to shock the people who, if legal strangeness weren't in the way, would be maintaining the code in question. > - the unpredictability of the CFI timetable (a bird in the hand vs > ...) Right; I think that's the only point in favor of the patch: it does work, and is committable right now. > - the unpredictability of the legal processes sometimes required > before accepting changes (must assume that the change doesn't exist) Well, the present situation doesn't depend on any changes from IBM: the choice is between arch-generic Dwarf 2 CFI support or mondo prologue analysis. > - the need to get the existing s390's frame code updated so that it > implements frame-unwind (this is in addition, and largely orthogonal > to the missing generic CFI unwinder). Ignoring > s390_get_signal_frame_info, which should be separated out, the > attached appears to only affect the prologe analyzer so is relatively > independant? Yes, it's a drop-in replacement. Even s390_get_signal_frame_info consists of code which used to be part of the old prologue analyzer; breaking it out is a separate patch. It looks to me, though, that if one simply changed s390-tdep.c to use the modern frame unwinding stuff, it would go away, or at least work very differently, anyway. > - the need to have gdb behave reasonably well when there is no, or > minimal, debug info > > - the need to fix the s390 problem of having a wrong frame ID > . stack_addr (does this change address that problem?) Nope. Its only effect is to make prologue analysis accurate more often. I've put together a list of projectlets needed to bring the s390 up to date, which I'll post in a bit; fixing the frame ID is on that list. > - what tests it actually fixes (data?) I'll go make that list. It doesn't seem to have a major effect on the test suite, but it makes a big difference when debugging optimized code. > > This patch assumes that IBM's s390x ABI patch has been applied. That > > patch is currently working its way through the IBM/FSF IP process. > > http://sources.redhat.com/ml/gdb-patches/2003-02/msg00097.html > > To be honest, I don't understand the dependency. This patch modifies > the prologue analysier while the other change appears to be fixing the > push_arguments function. While they might interact in positive ways, > I don't think that they are dependant. The patch doesn't apply. The context doesn't match, textually. There is no major semantic dependency.