From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11712 invoked by alias); 19 Oct 2011 15:52:10 -0000 Received: (qmail 11701 invoked by uid 22791); 19 Oct 2011 15:52:08 -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 mtagate1.uk.ibm.com (HELO mtagate1.uk.ibm.com) (194.196.100.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Oct 2011 15:51:49 +0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p9JFplbT002189 for ; Wed, 19 Oct 2011 15:51:47 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 p9JFpl7t2486408 for ; Wed, 19 Oct 2011 16:51:47 +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 p9JFpkh3020336 for ; Wed, 19 Oct 2011 09:51:47 -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 p9JFpjs3020322; Wed, 19 Oct 2011 09:51:45 -0600 Message-Id: <201110191551.p9JFpjs3020322@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 19 Oct 2011 17:51:45 +0200 Subject: Re: entryval tail call frames $sp adjustment vs. gdbarches [Re: New ARI warning Thu Oct 13 01:55:36 UTC 2011] To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Wed, 19 Oct 2011 16:05:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20111013211526.GA5377@host1.jankratochvil.net> from "Jan Kratochvil" at Oct 13, 2011 11:15:26 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/msg00531.txt.bz2 Jan Kratochvil wrote: > On Thu, 13 Oct 2011 16:59:37 +0200, Ulrich Weigand wrote: > > Generic code is not supposed to make the assumption that there *is* > > a single "sp" (or "pc") register; > > The current code does everything in a "best effort" mode. If anything fails > $sp in tail call frames is just not adjusted - it should not be such a problem. > So far I would set such behavior for all gdbarches anyway (*). > > (*) I guess the correct approach is to set it only for gdbarches where one > verifies it is correct. Still if the code succeeds I believe the result is > always correct - so what is the point of gdbarch in such case? It's just that some of those assumptions seem really unnecessary to me. For example, the assumption that there is a fixed "PC" register: prev_gdbarch = frame_unwind_arch (this_frame); pc_regnum = gdbarch_pc_regnum (prev_gdbarch); if (pc_regnum == -1) break; /* Simulate frame_unwind_pc without setting this_frame->prev_pc.p. */ prev_pc = frame_unwind_register_unsigned (this_frame, pc_regnum); Why don't you just do something like: prev_gdbarch = frame_unwind_arch (this_frame); /* Simulate frame_unwind_pc without setting this_frame->prev_pc.p. */ prev_pc = gdbarch_unwind_pc (prev_gdbarch, this_frame); Similarly, when injecting the tailcall PC values, you hook into the prev_register routine -- which assumes that unwind_pc will end up doing an unwind_register of pc_regnum. This assumptium would be unnecessary if you just hooked into frame_unwind_pc directly instead. Now as to SP, what happens is that you detect the rule for the CFA at the entry point is CFA = + Tailcall unwinding doesn't directly know the value of sp_register, but it does know the CFA, so you hook into prev_register to return a value of sp_register that is designed such that the above computation will yield the desired CFA. However -- nothing in that design depends on the CFA being relative to the SP register in particular. You could avoid this by detecting the more general rule CFA = + and then remember both the register and the offset, and hook into prev_register for whatever the register is -- no need at all to enforce that this must be gdbarch_sp_regnum ... (You could then even generalize this to even more generic expressions to compute the CFA, if necessary for certain platforms.) > > 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. > > I see now dwarf2_frame_cfa is more appropriate by its name. The detection > code is based on CFA (CFA_REG_OFFSET, regs.cfa_reg etc.). > And dwarf2_frame_cfa in such case effectively just calls get_frame_base. > > Unless you advice me differently I will change it this way. Yes, dwarf2_frame_cfa would be preferable here. > > 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 ... > > On s390x the adjustment code in dwarf2_tailcall_prev_register_first (detected > inside dwarf2_frame_cache, from .debug_frame) gets into effect but in fact it > does not change the $sp value. Which is correct, as "brasl" does not modify > $sp. I see that I misunderstood your code; it does take the offset between SP and CFA into account correctly, so it will work on s390 too. > > 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)? > > I dd not think it needs to be documented in the manual as it just simulates > the expected state of inferior. > > In the x86_64 sample code below when we unwind function `f' the register set > there should be already the unwound one - the same like in the function > `main'. `f' just stands on the jmp instruction so it does not have any its > own register state to unwind. > > Just there is the exception $sp - in function `f' the value of $sp should not > be the same like in the function `main' as there is the return address there. > The two lines `XXX' - the real register state should match the later unwound > register state. OK, thanks for the explanation. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com