From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15518 invoked by alias); 6 Oct 2008 21:22:32 -0000 Received: (qmail 15510 invoked by uid 22791); 6 Oct 2008 21:22:32 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.113.40.141) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Oct 2008 21:21:53 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 2DD976A1C; Mon, 6 Oct 2008 14:21:51 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost2.vmware.com (Postfix) with ESMTP id 2165B8E5CA; Mon, 6 Oct 2008 14:21:51 -0700 (PDT) Message-ID: <48EA8101.2070506@vmware.com> Date: Mon, 06 Oct 2008 21:22:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" , Daniel Jacobowitz , teawater Subject: Re: [RFA] Reverse Debugging, 3/5 References: <48E3CD0B.8020003@vmware.com> <200810062109.16785.pedro@codesourcery.com> <48EA7A5B.4040701@vmware.com> <200810062214.49011.pedro@codesourcery.com> In-Reply-To: <200810062214.49011.pedro@codesourcery.com> Content-Type: text/plain; charset=UTF-8; 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/msg00168.txt.bz2 Pedro Alves wrote: > On Monday 06 October 2008 21:51:39, Michael Snyder wrote: >> Pedro Alves wrote: >>> Hi Michael, >>> >>> Shouldn't failing to find ones >>> direction always be an error (hence an error call from inside >>> target_get_execution_direction, or something alike). >> Targets that don't implement reverse return EXEC_ERROR, >> rather than EXEC_FORWARD. It was an early interface >> design decision, and I'm not sure if I can remember the >> justification after over 2 years, but I made it >> consciously -- it seemed to simplify things. >> > > ... Okay. If nobody else remembers why, and I throw a > later patch at you to change this, please don't be mad > at me. :-) So long as you can argue that it makes things better. ;-) >>>> + keep going back to the call point). */ >>>> + if (stop_pc == ecs->event_thread->step_range_start && >>>> + stop_pc != ecs->stop_func_start && >>>> + target_get_execution_direction () == EXEC_REVERSE) >>>> + { >>>> + ecs->event_thread->stop_step = 1; >>>> + print_stop_reason (END_STEPPING_RANGE, 0); >>>> + stop_stepping (ecs); >>>> + } >>>> + else >>>> + { >>>> + keep_going (ecs); >>>> + } >>> Unneeded braces. >> Don't you think it's more readable if the if block >> and the else block match? > > Not really, and it's what the GDB/GNU coding standards prefer... OK, good enough for me. > I'm not going to argue about these issues, but, personally, and to > stick with the standard, I do things like this a lot: You got it. >>>> + ecs->event_thread->step_range_start = stop_func_sal.pc; >>>> + ecs->event_thread->step_range_end = stop_func_sal.end; >>> Somethings fishy with the whitespace. ^ >> I just like things to line up when possible! >> ;-) > > To me, visual vertical aligment is more distracting than good. It > distract me from the right -> left assignment flow. But, that's > just me. I'm not going to make a bid deal out of it. How about if I give you two out of three? ;-)