From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25370 invoked by alias); 8 Sep 2014 14:18:20 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 25359 invoked by uid 89); 8 Sep 2014 14:18:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp13.uk.ibm.com Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 08 Sep 2014 14:18:19 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 8 Sep 2014 15:18:15 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 8 Sep 2014 15:18:14 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 3D5C517D8062 for ; Mon, 8 Sep 2014 15:20:14 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s88EIEjo27394180 for ; Mon, 8 Sep 2014 14:18:14 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s88EID49023611 for ; Mon, 8 Sep 2014 08:18:13 -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.14.4/NCO v10.0 AVin) with SMTP id s88EIBnC023550; Mon, 8 Sep 2014 08:18:12 -0600 Message-Id: <201409081418.s88EIBnC023550@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 08 Sep 2014 16:18:11 +0200 Subject: Re: Question about ppc reverse stepping To: green@moxielogic.com (Anthony Green) Date: Mon, 08 Sep 2014 14:18:00 -0000 From: "Ulrich Weigand" Cc: gdb@sourceware.org In-Reply-To: <8761gztsp3.fsf@moxielogic.com> from "Anthony Green" at Sep 07, 2014 10:23:52 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14090814-2966-0000-0000-0000010E6D52 X-SW-Source: 2014-09/txt/msg00026.txt.bz2 Anthony Green wrote: > solib-reverse.exp has an executable with undebuggable shared libraries. > The test is written such that it expects reverse stepping over calls to > the solib to skip the call completely. However, on ppc linux, reverse > stepping has me stepping through some glue magic before popping out the > other end. In the text below, when I'm on line 46, the test case > expects that reverse-step lands me on line 44 (at the bottom) without > all of the intermediate steps. > > 46 return 0; /* end part one */ > (gdb) reverse-step > 0x00003fffb7fb08b8 in .shr1 () from /home/green/binutils-gdb/gdb/testsuite/gdb.reverse/shr1.sl > (gdb) reverse-step > Single stepping until exit from function .shr1, > which has no line number information. > 0x00003fffb7fb08b0 in .shr1 () from /home/green/binutils-gdb/gdb/testsuite/gdb.reverse/shr1.sl > (gdb) reverse-step > Single stepping until exit from function .shr1, > which has no line number information. > 0x0000000010000638 in 00000011.plt_call.shr1+0 () > (gdb) reverse-step > Single stepping until exit from function 00000011.plt_call.shr1+0, > which has no line number information. > main () at ./gdb.reverse/solib-reverse.c:44 > 44 shr1 ("message 3\n"); /* shr1 three */ > > Is this what we really want? Or can I modify the test to repeatedly > step over the .shr1 lines? No, the test case is fine as is. When doing a "step" on line 44, you get directly to line 46 since "shr1" has no debug info. This means that doing a reverse-step on line 46 should get you directly to line 44. There is code in infrun.c that is supposed to achieve that. You'll need to figure out why that doesn't work on ppc at the moment. What does the output from "set debug infrun 1" say? This should be handled in infrun.c starting around line 4746: if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: stepped into subroutine\n"); and then: if (execution_direction == EXEC_REVERSE) { /* If we're already at the start of the function, we've either just stepped backward into a single instruction function without line number info, or stepped back out of a signal handler to the first instruction of the function without line number info. Just keep going, which will single-step back to the caller. */ if (ecs->stop_func_start != stop_pc) { /* Set a breakpoint at callee's start address. From there we can step once and be back in the caller. */ struct symtab_and_line sr_sal; init_sal (&sr_sal); sr_sal.pc = ecs->stop_func_start; sr_sal.pspace = get_frame_program_space (frame); insert_step_resume_breakpoint_at_sal (gdbarch, sr_sal, null_frame_id); } The insert_step_resume_breakpoint_at_sal should cause the debugger to continue backwards until the call to shr1. Skipping the PLT stub code may be a different issue, that is supposed to work via the gdbarch_skip_trampoline_code callback; maybe there's something in the ppc version of that callback that isn't right for reverse debugging. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com