From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16640 invoked by alias); 13 Oct 2011 21:15:49 -0000 Received: (qmail 16585 invoked by uid 22791); 13 Oct 2011 21:15:47 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_FD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Oct 2011 21:15:33 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9DLFUso011367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2011 17:15:30 -0400 Received: from host1.jankratochvil.net (ovpn-116-16.ams2.redhat.com [10.36.116.16]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p9DLFSqd027508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Oct 2011 17:15:30 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p9DLFRYF011057; Thu, 13 Oct 2011 23:15:27 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p9DLFQT8011052; Thu, 13 Oct 2011 23:15:26 +0200 Date: Thu, 13 Oct 2011 21:15:00 -0000 From: Jan Kratochvil To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: entryval tail call frames $sp adjustment vs. gdbarches [Re: New ARI warning Thu Oct 13 01:55:36 UTC 2011] Message-ID: <20111013211526.GA5377@host1.jankratochvil.net> References: <20111013135412.GA2276@host1.jankratochvil.net> <201110131459.p9DExbK9013317@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110131459.p9DExbK9013317@d06av02.portsmouth.uk.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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/msg00404.txt.bz2 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? > 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. > 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'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. Thanks, Jan x86_64: static __attribute__ ((noinline, noclone)) void g (void) { asm volatile (""); } static __attribute__ ((noinline, noclone)) void f (void) { g (); } int main (void) { f (); return 0; } gcchead-root/bin/gcc -o tailcall4 tailcall4.c -Wall -g -O2 gdb -nx -x ~/.gdbinit ./tailcall4 -ex 'set disassemble-next-line on' -ex start 3 int main (void) { f (); return 0; } => 0x0000000000400360 : e8 ab 00 00 00 callq 0x400410 0x0000000000400365 : 31 c0 xor %eax,%eax 0x0000000000400367 : c3 retq (gdb) display/x $sp 1: /x $sp = 0x7fffffffdb08 (gdb) stepi f () at tailcall4.c:2 2 static __attribute__ ((noinline, noclone)) void f (void) { g (); } => 0x0000000000400410 : eb ee jmp 0x400400 1: /x $sp = 0x7fffffffdb00 XXX ^^^^^^^^^^^^^^ (gdb) stepi g () at tailcall4.c:1 1 static __attribute__ ((noinline, noclone)) void g (void) { asm volatile (""); } => 0x0000000000400400 : c3 retq 0x0000000000400401: 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 data32 data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 1: /x $sp = 0x7fffffffdb00 (gdb) bt #0 g () at tailcall4.c:1 #1 0x0000000000400412 in f () at tailcall4.c:2 #2 0x0000000000400365 in main () at tailcall4.c:3 (gdb) up #1 0x0000000000400412 in f () at tailcall4.c:2 2 static __attribute__ ((noinline, noclone)) void f (void) { g (); } 0x0000000000400410 : eb ee jmp 0x400400 (gdb) p/x $sp $1 = 0x7fffffffdb00 XXX ^^^^^^^^^^^^^^ (gdb) up #2 0x0000000000400365 in main () at tailcall4.c:3 3 int main (void) { f (); return 0; } 0x0000000000400360 : e8 ab 00 00 00 callq 0x400410 => 0x0000000000400365 : 31 c0 xor %eax,%eax 0x0000000000400367 : c3 retq (gdb) p/x $sp $2 = 0x7fffffffdb08