From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13349 invoked by alias); 10 Dec 2003 17:14:56 -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 13342 invoked from network); 10 Dec 2003 17:14:56 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 10 Dec 2003 17:14:56 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 435E72B8F; Wed, 10 Dec 2003 12:14:53 -0500 (EST) Message-ID: <3FD7548D.7080300@gnu.org> Date: Wed, 10 Dec 2003 17:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Cagney , Mark Kettenis Cc: Ulrich Weigand , gdb-patches@sources.redhat.com, uweigand@de.ibm.com Subject: Re: [PATCH] S/390 DWARF-2 CFI frame support References: <200312042009.VAA07733@faui1d.informatik.uni-erlangen.de> <3FD0ABF9.4090201@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00292.txt.bz2 Mark, This is really a question for you. If you want I can hack up the code (although I don't know exactly when that would happen). Andrew > Hello, > > this patch adds support for DWARF-2 frame handling to the s390 backend. > > However, the DWARF-2 frame common code makes a couple of assumptions > that are not valid on s390: > > - The return address column is not unwound into the specified register, > only into the PC. On s390, it should be unwound into both. > > The patch below fixes this by unwinding into both register > and PC if the return column corresponds to a GDB register. > > What does the CFI output look like here? (I'm mainly curious but it always helps to have concrete examples). > > For a variant of the PPC64 GCC I found: > > - return column pointed at the FSCR > (which is stupid) > > - return column same-value as "LR" was implied > (which is contrary to the DWARF2's example, and what you also encountered) > > this means that we've now got the following initial states all mapping onto "unspecified": > > - same value > - unknown > - (for SP_REGNUM) it's the CFA (but is it one frame out?) > - (for return column) it's the LR > > I'm wondering if it would be easier, here to "give up". Throw the whole problem back at the architecture vis: > > - initialize unwind table using per OSABI (?) method > > - update the unwind table using the CFI initialize info > > - update the unwind table using the PC's CFI unwind info > > - if after all this a register is still unspecified, we complain > (btw, the compaint is only ment to appear once but apparently appears repeatedly?). > > Thoughts for the moment on the theory? Mark? > > It should also open the way for the elimination of SP_REGNUM and PC_REGNUM from this file (ya!). > > As for an interface, the _gdbarch_init code could something like: > > dwarf2_frame_add_sniffer (gdbarch, (*_dwarf2_cfi_init) (struct cfi_table *table)); > > (but with better names :-). > > Andrew