From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18166 invoked by alias); 21 Apr 2003 16:31:39 -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 18090 invoked from network); 21 Apr 2003 16:31:37 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 21 Apr 2003 16:31:37 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7AC232B2F; Mon, 21 Apr 2003 12:31:34 -0400 (EDT) Message-ID: <3EA41CE6.9000706@redhat.com> Date: Mon, 21 Apr 2003 16:31: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: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [just for the record]: new prologue analyzer for S/390 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00369.txt.bz2 > I think this patch shouldn't be committed; I'm just posting it for > reference. > > This patch implements a new prologue analyzer for the S/390. It's > meant to be general enough to handle the complex prologues GCC emits > on the S/390, and robust enough to tolerate compiler changes. In my > experience, it does pretty well, even on optimized code. > > However, the S/390 GDB folks at IBM and I agree that GDB on the S/390 > should move towards using Dwarf 2 CFI and location lists whenever > possible, and do only minimal prologue analysis to handle those few > common cases where Dwarf 2 CFI is not available. And it looks to me > as if the work needed in GDB's core code to make it possible for any > target to use Dwarf 2 CFI is almost complete. In that light, it > doesn't make sense to dump a new, large, complex prologue analyzer > into the code base that will soon be eclipsed by a better solution. 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: - the unpredictability of the CFI timetable (a bird in the hand vs ...) - the unpredictability of the legal processes sometimes required before accepting changes (must assume that the change doesn't exist) - 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? - 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?) - what tests it actually fixes (data?) > 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. I'd also strongly recommend putting your the file / changes through gdb_indent.sh - GNU indent will likely have a field day on the formatting of the comments :-( Andrew