From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5148 invoked by alias); 14 Dec 2003 16:40:59 -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 5141 invoked from network); 14 Dec 2003 16:40:58 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 14 Dec 2003 16:40:58 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9A2352B8F; Sun, 14 Dec 2003 11:40:50 -0500 (EST) Message-ID: <3FDC9292.6030601@gnu.org> Date: Sun, 14 Dec 2003 16:40: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: Mark Kettenis Cc: weigand@i1.informatik.uni-erlangen.de, gdb-patches@sources.redhat.com, uweigand@de.ibm.com Subject: Re: [PATCH] S/390 DWARF-2 CFI frame support References: <200312131532.QAA19238@faui1d.informatik.uni-erlangen.de> <200312141521.hBEFLddh008828@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00369.txt.bz2 > From: Ulrich Weigand > Date: Sat, 13 Dec 2003 16:32:12 +0100 (CET) > Cc: cagney@gnu.org, weigand@i1.informatik.uni-erlangen.de, > gdb-patches@sources.redhat.com, uweigand@de.ibm.com > Content-Type: text/plain; charset=us-ascii > X-Spam-Level: > X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on > elgar.kettenis.dyndns.org > X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham > version=2.60 > > Mark Kettenis wrote: > > > 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. > > However, I rather like to see 'value not available' instead of > an incorrect value in an 'info reg' display. So if we do have > an arch-dependent callback, we might as well use ABI knowledge > to get this right. > > It probably depends a bit on the context. IMHO it is perfectly > all-right for a compiler to generate code that doesn't conform to the > ABI if it knows what it's doing. Or for to user to ask the compiler > to generate code that doesn't conform to the ABI. IIRC this happens > at various places in glibc. It would be a bit unfortunately if we > made it hard or impossible for the user to view (valid) variables in > registers, just because we're strictly enforcing the ABI. Of course > the real solution here would be to get GCC to emit CFI for all > registers, at least for .dwarf_frame (as opposed to .eh_frame) > sections. Let me scare you a little .... GCC is working towards to being able to do non-ABI local function calls (and knowing them a few global ones as well :-) With that said, I think for values, GDB should print value-unknown, but for registers, print the likely wrong value (we could always add "info known-registers" :-). But its a judgment call, anyone want to toss the coin? > > 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. > > The only hack that cannot be replaced using the rules described > above (as far as I can see) is the > if (column == fs->retaddr_column) > continue; > in dwarf2_frame_cache. Does any platform rely on this behaviour? > > The reason why I added that hack in the first place is the case where > the return address column does not correspond to an actual register. > In that case we must make sure that we don't map it onto one of GDB's > (pseudo-)registers. Assuming that the compiler has some freedom in > choosing the return address column number, and considering that the > DWARF-2 register numbers are largely undocumented for most targets, I > was worried that I couldn't guarantee this. > > AFAICT there is no platform yet where GCC uses a return address column > number that would be mapped on the wrong GDB register, so I think we > can safely remove the code. New targets that start using the DWARF-2 > CFI stuff should make sure theur DWARF-2 register number mapping is > right. Well, ... the PPC64 return-column, when I last looked, specified the dwarf2' floating-point status and control register number! But let the person framifying the PPC64 sort that one out :-) Anyway, with respect to your proposal, yes like it. Andrew