From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15402 invoked by alias); 24 Oct 2008 01:23:54 -0000 Received: (qmail 15393 invoked by uid 22791); 24 Oct 2008 01:23:53 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 24 Oct 2008 01:23:20 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 7D9D025001; Thu, 23 Oct 2008 18:23:19 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost3.vmware.com (Postfix) with ESMTP id 7058AC9A38; Thu, 23 Oct 2008 18:23:19 -0700 (PDT) Message-ID: <4901225F.2030008@vmware.com> Date: Fri, 24 Oct 2008 01:23:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: teawater CC: "gdb-patches@sourceware.org" Subject: Re: [RFA] Deal with get ecs->stop_func_end fail References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2008-10/txt/msg00598.txt.bz2 teawater wrote: > Hi Michael, > > I try a program and got: > (gdb) start > Temporary breakpoint 1 at 0x80483c1: file 1.c, line 20. > Starting program: /media/disk/a.out > > Temporary breakpoint 1, main () at 1.c:20 > 20 int b = 0; > (gdb) rec > (gdb) n > 21 int c = 1; > (gdb) > 24 printf ("a = %d b = %d c = %d\n", a, b, c); > (gdb) > a = 0 b = 0 c = 1 > 25 b = cool (); > (gdb) rn > > No more reverse-execution history. > main () at 1.c:20 > 20 int b = 0; > > > It's clear that "rn" got error. > This is because: > find_pc_partial_function (stop_pc, &ecs->stop_func_name, > &ecs->stop_func_start, &ecs->stop_func_end); > This part get ecs->stop_func_end is 0. Aha. This is because we have stepped backward into a shared-library trampoline. You understand trampoline? It means that this was the first time the program calls "printf", which is in a shared library, so the program jumps into a jump table which causes the dymanic runtime resolver (ld-linux.so) to be called. We actually succeeded in "nexting" backward through printf, and then we succeeded in "nexting" backward thru _dl_runtime_resolver, but we failed when we hit the trampoline (backward). Give me some time, I need to figure out how to handle trampolines backward! ;-) Meanwhile, this is obviously a problem in infrun, so it does not need to affect your work on record/replay. Leave this to me. ;-)