From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8275 invoked by alias); 12 Dec 2003 17:43:42 -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 8268 invoked from network); 12 Dec 2003 17:43:40 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 12 Dec 2003 17:43:40 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id hBCHfk9h001266; Fri, 12 Dec 2003 18:41:46 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id hBCHfjrL036659; Fri, 12 Dec 2003 18:41:46 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id hBCHfeRW036656; Fri, 12 Dec 2003 18:41:40 +0100 (CET) Date: Fri, 12 Dec 2003 17:43:00 -0000 Message-Id: <200312121741.hBCHfeRW036656@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: cagney@gnu.org, weigand@i1.informatik.uni-erlangen.de, gdb-patches@sources.redhat.com, uweigand@de.ibm.com In-reply-to: <3FD7548D.7080300@gnu.org> (message from Andrew Cagney on Wed, 10 Dec 2003 12:14:53 -0500) Subject: Re: [PATCH] S/390 DWARF-2 CFI frame support References: <200312042009.VAA07733@faui1d.informatik.uni-erlangen.de> <3FD0ABF9.4090201@gnu.org> <3FD7548D.7080300@gnu.org> X-SW-Source: 2003-12/txt/msg00333.txt.bz2 I've been thinking about this over the last few days, but I haven't reached a conclusion yet. I've considered per-architecture initialization of the unwind table before. However, the things Richard Henderson says about treating uninitialized columns as "same value" make sense. And as Ulrich pointed out, it doesn't immediately solve our problems with the PC and SP. On the other hand, we should be able to introduce our own "rules" in addition to the ones given by the DWARF2/3 specification. We could add the following two: * REG_RETURN_ADDRESS: Set the particular register to the return address of the function. * REG_CFA: Set the particular register to the call frame address. We could even allow for an offset, such that we could specify rules such as: set the ISA PC register to the return address plus an offset of 8 bytes, or set the ISA SP register to the call frame address plus minus an offset of 128 bytes. I might need such a facility for SPARC. How does that sound? In the meantime, I'm going to try to remove some of the PC and SP-related hacks in dwarf2-frame.c and see what happens. Mark