From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15352 invoked by alias); 14 Dec 2003 17:16: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 15283 invoked from network); 14 Dec 2003 17:16:47 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 14 Dec 2003 17:16:47 -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 hBEHEqmb001851; Sun, 14 Dec 2003 18:14:52 +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 hBEHEqCq014093; Sun, 14 Dec 2003 18:14:52 +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 hBEHEqU2014090; Sun, 14 Dec 2003 18:14:52 +0100 (CET) Date: Sun, 14 Dec 2003 17:16:00 -0000 Message-Id: <200312141714.hBEHEqU2014090@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: weigand@i1.informatik.uni-erlangen.de, gdb-patches@sources.redhat.com, uweigand@de.ibm.com In-reply-to: <3FDC9292.6030601@gnu.org> (message from Andrew Cagney on Sun, 14 Dec 2003 11:40:50 -0500) Subject: Re: [PATCH] S/390 DWARF-2 CFI frame support References: <200312131532.QAA19238@faui1d.informatik.uni-erlangen.de> <200312141521.hBEFLddh008828@elgar.kettenis.dyndns.org> <3FDC9292.6030601@gnu.org> X-SW-Source: 2003-12/txt/msg00370.txt.bz2 Date: Sun, 14 Dec 2003 11:40:50 -0500 From: Andrew Cagney > 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 :-) Argh! Someone teach GCC about the PPC64 DWARF register numbering please! Before it is too late! Now it is using the PPC32 LR register number, which just happens to be the PPC64 FPSCR register. Anyway, with respect to your proposal, yes like it. I'll see whether I can implement it. Mark