From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5148 invoked by alias); 11 Nov 2004 19:42:16 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4814 invoked from network); 11 Nov 2004 19:41:48 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 11 Nov 2004 19:41:48 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iABJfjq0004443; Thu, 11 Nov 2004 20:41:45 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iABJfjet098486; Thu, 11 Nov 2004 20:41:45 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iABJfeuD098483; Thu, 11 Nov 2004 20:41:40 +0100 (CET) Date: Thu, 11 Nov 2004 19:47:00 -0000 Message-Id: <200411111941.iABJfeuD098483@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: randolph@tausq.org CC: gdb@sources.redhat.com In-reply-to: <20041111164852.GS15714@tausq.org> (message from Randolph Chung on Thu, 11 Nov 2004 08:48:52 -0800) Subject: Re: dwarf2 and frame bases References: <20041110235149.GO15714@tausq.org> <20041110235649.GA741@nevyn.them.org> <20041111000933.GP15714@tausq.org> <20041111030938.GA4784@nevyn.them.org> <20041111164852.GS15714@tausq.org> X-SW-Source: 2004-11/txt/msg00109.txt.bz2 Date: Thu, 11 Nov 2004 08:48:52 -0800 From: Randolph Chung sounds like it should still work (i.e it should still be a valid address), except the hppa targer has an explicit check for when we expect r3 to be modified but we may be in the process of changing it (since it's a 3 insn sequence). In that case, we zero the register to tell the unwinder not to use the value in the r3 to calculate the frame base (it uses the stack pointer and other unwind information in that case) See http://sources.redhat.com/ml/gdb-patches/2004-06/msg00108.html for more details. i know it is kind of hacky, but the frame unwinding code is explicitly asking "what is the frame base of this frame", and the target code is especially tuned for that..... It is certainly hacky, and defenitely wrong. "Thou shallt not lie about your register contents". i see two possible solutions: 1) perhaps the hppa target should use some other mechanism (instead of mucking with r3) to tell the next frame that the frame pointer is not available..... Why does the next frame need that frame pointer? 2) in the dwarf code, when trying to get the frame base, should we explicitly ask for the frame base instead of using the dwarf expression? perhaps this could be something that can be overridden by the target, so that the default still uses the dwarf information. The problem here is that the debug information provided my the compiler is wrong, or at least incomplete. This should be fixed in the compiler, not in GDB. Unfortunately this probably means we need to have proper support for location expressions in GDB. Mark