From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19662 invoked by alias); 14 Dec 2003 15:23:43 -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 19648 invoked from network); 14 Dec 2003 15:23:39 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 14 Dec 2003 15:23:39 -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 hBEFLjmb001692; Sun, 14 Dec 2003 16:21:45 +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 hBEFLiCq008831; Sun, 14 Dec 2003 16:21:44 +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 hBEFLddh008828; Sun, 14 Dec 2003 16:21:39 +0100 (CET) Date: Sun, 14 Dec 2003 15:23:00 -0000 Message-Id: <200312141521.hBEFLddh008828@elgar.kettenis.dyndns.org> From: Mark Kettenis To: weigand@i1.informatik.uni-erlangen.de CC: cagney@gnu.org, weigand@i1.informatik.uni-erlangen.de, gdb-patches@sources.redhat.com, uweigand@de.ibm.com In-reply-to: <200312131532.QAA19238@faui1d.informatik.uni-erlangen.de> (message from Ulrich Weigand on Sat, 13 Dec 2003 16:32:12 +0100 (CET)) Subject: Re: [PATCH] S/390 DWARF-2 CFI frame support References: <200312131532.QAA19238@faui1d.informatik.uni-erlangen.de> X-SW-Source: 2003-12/txt/msg00368.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. > 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. Mark