From: Michael Snyder <msnyder@vmware.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
Daniel Jacobowitz <drow@false.org>,
teawater <teawater@gmail.com>
Subject: Re: [RFA] Reverse Debugging, 3/5
Date: Mon, 06 Oct 2008 21:22:00 -0000 [thread overview]
Message-ID: <48EA8101.2070506@vmware.com> (raw)
In-Reply-To: <200810062214.49011.pedro@codesourcery.com>
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? ;-)
next prev parent reply other threads:[~2008-10-06 21:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 19:20 Michael Snyder
2008-10-06 20:09 ` Pedro Alves
2008-10-06 20:54 ` Michael Snyder
2008-10-06 21:14 ` Pedro Alves
2008-10-06 21:22 ` Michael Snyder [this message]
2008-10-06 21:26 ` Joel Brobecker
2008-10-06 21:47 ` Michael Snyder
2008-10-06 21:22 ` Joel Brobecker
[not found] ` <48EA83AD.9040004@vmware.com>
2008-10-06 21:43 ` Joel Brobecker
2008-10-06 23:46 ` Michael Snyder
2008-10-07 4:07 ` Joel Brobecker
2008-10-07 18:46 ` Michael Snyder
2008-10-08 0:31 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48EA8101.2070506@vmware.com \
--to=msnyder@vmware.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.com \
--cc=teawater@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox