From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7737 invoked by alias); 13 Oct 2011 15:00:00 -0000 Received: (qmail 7728 invoked by uid 22791); 13 Oct 2011 14:59:59 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate7.uk.ibm.com (HELO mtagate7.uk.ibm.com) (194.196.100.167) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Oct 2011 14:59:40 +0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p9DExcxK023438 for ; Thu, 13 Oct 2011 14:59:38 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p9DExcBt2531580 for ; Thu, 13 Oct 2011 15:59:38 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p9DExcIF013368 for ; Thu, 13 Oct 2011 08:59:38 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p9DExbK9013317; Thu, 13 Oct 2011 08:59:37 -0600 Message-Id: <201110131459.p9DExbK9013317@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 13 Oct 2011 16:59:37 +0200 Subject: Re: New ARI warning Thu Oct 13 01:55:36 UTC 2011 To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Thu, 13 Oct 2011 15:00:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20111013135412.GA2276@host1.jankratochvil.net> from "Jan Kratochvil" at Oct 13, 2011 03:54:12 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00396.txt.bz2 Jan Kratochvil wrote: > On Thu, 13 Oct 2011 03:55:36 +0200, GDB Administrator wrote: > > 216a217 > > > gdb/dwarf2-frame-tailcall.c:283: obsolete: get_frame_base: Replace get_frame_base with get_frame_id, get_frame_base_address, get_frame_locals_address, or get_frame_args_address. > > gdb/dwarf2-frame-tailcall.c:283: addr = get_frame_base (this_frame) - cache->entry_cfa_sp_offset; > > This comes from my: > [patch 04/12] entryval#3: Virtual tail call frames > http://sourceware.org/ml/gdb-patches/2011-09/msg00556.html > > where the code is specific to gdbarch_sp_regnum, so I think it should operate > with this_frame->stack_addr, which is exactly what get_frame_base does. Unfortunately this code reintroduced a number of platform-specific assumptions that Andrew went to a lot of effort to eliminate from common frame-handling code. Generic code is not supposed to make the assumption that there *is* a single "sp" (or "pc") register; instead it should leave the details up to the gdbarch's unwind_pc and unwind_sp routines. (And on various platforms those routines *are* more complicated that just unwinding one particular register ...) I don't like re-introducing a new use of get_frame_base in common code; we've been really close to eliminating this (for good reasons; see the various comments in the code). The problem is that frame->stack_addr is supposed to be opaque to common code; it is explicitly *not* defined to equal the value of some SP register. It's meaning is solely up to the frame unwinders. For DWARF frames specifically, the convention is that ->stack_addr will equal the CFA. So if you are in DWARF-specific code, and need the CFA, you can make use of that convention; but the best way to do that would probably be to call dwarf2_frame_cfa instead of get_frame_base. Note however, that even the CFA is not automatically equal to some "value of a SP register"; for example, on s390(x), the CFA is always biased by 96 (or 160) bytes against the SP at function entry ... > I understand such code ($sp simulation with shift for return address in tail > call frames) could have been rather gdbarch-specific but I am not aware of any > gdbarch where it should be done differently. If such gdbarch exists and there > is interest in fixing this very minor feature of the entryval patchset this > can be moved to gdbarch-specific code where maybe get_frame_base may not be > appropriate. I have no idea without being aware of any such gdbarch. I'm afraid I'm not sure exactly what all this SP manipulation code is intended to achieve; could you elaborate (or is there documentation somewhere that I missed)? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com