From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4278 invoked by alias); 11 Nov 2005 18:05:44 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 4248 invoked by uid 22791); 11 Nov 2005 18:05:42 -0000 Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.196) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 11 Nov 2005 18:05:42 +0000 Received: by zproxy.gmail.com with SMTP id l1so754027nzf for ; Fri, 11 Nov 2005 10:05:40 -0800 (PST) Received: by 10.36.24.5 with SMTP id 5mr1537300nzx; Fri, 11 Nov 2005 10:05:40 -0800 (PST) Received: by 10.37.2.35 with HTTP; Fri, 11 Nov 2005 10:05:40 -0800 (PST) Message-ID: <8f2776cb0511111005p7def7f5dv518fd2f9674e4b76@mail.gmail.com> Date: Fri, 11 Nov 2005 18:05:00 -0000 From: Jim Blandy To: gdb@sources.redhat.com Subject: Fwd: frame_id question In-Reply-To: <8f2776cb0511110943p1bb2b03g1b158fb8a82f2528@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200511111335.18605.ghost@cs.msu.su> <8f2776cb0511110943p1bb2b03g1b158fb8a82f2528@mail.gmail.com> X-SW-Source: 2005-11/txt/msg00230.txt.bz2 ---------- Forwarded message ---------- From: Jim Blandy Date: Nov 11, 2005 9:43 AM Subject: Re: frame_id question To: Vladimir Prus Cc: Jim Blandy , gdb@sources.redhat.com On 11/11/05, Vladimir Prus wrote: > Do I understand correctly that this can happen only on architectures whe= re > return address is not automatically pushed to the stack, but moved to a > special register? Like MIPS's "jal" instructions that moves return addres= s to > $31 Yes, that's right. > Does it mean that for architectures with automatic pushing of return addr= ess, > using '0' as code address in frame_id will be safe? Or there are some cor= ner > cases? I think this is true. It used to be that some architectures used the top of the stack as the frame ID's stack address (even though this is wrong: a call to alloca could change the sp, or the code itself could push and pop things for its own reasons; either would produce a "new" frame ID when no call, return, or longjmp has taken place). On these architectures, I think you could run into problems. But the modern thing to do is to use the base of the stack frame --- the top of the stack upon entry to the function, or some fixed offset from that --- as the frame ID's stack address. When you have Dwarf CFI for the function, we use the Dwarf CFA for the frame ID stack address, which meets those qualifications. I'm not sure what the code address would be needed for in those architectures. If you're porting to a new architecture, you'll want to go through the test suite results very carefully to look for stack unwinding problems.