Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Michael Snyder <msnyder@vmware.com>,
	 Daniel Jacobowitz <drow@false.org>,
	 teawater <teawater@gmail.com>
Subject: Re: [RFA] Reverse Debugging, 3/5
Date: Mon, 06 Oct 2008 21:14:00 -0000	[thread overview]
Message-ID: <200810062214.49011.pedro@codesourcery.com> (raw)
In-Reply-To: <48EA7A5B.4040701@vmware.com>

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.  :-)

> 
> >> +        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...

"
For the body of the function, our recommended style looks like this:

     if (x < foo (y, z))
       haha = bar[4] + 5;
     else
       {
         while (z)
           {
             haha += foo (z, z);
             z--;
           }
         return ++x + bar ();
       }
"


> >> +       }
> >> +      else
> >> +       {
> >> +         /* Set a breakpoint at callee's return address (the address
> >> +            at which the caller will resume).  */
> >> +         insert_step_resume_breakpoint_at_caller (get_current_frame ());
> >> +       }
> > 
> > Unneeded braces.
> 
> Oh come on -- I know they're syntactic null, but
> they serve to keep the comment together with the
> code it refers to.
> 

I'm not going to argue about these issues, but, personally, and to
stick with the standard, I do things like this a lot:

      if (foo)
        {
          /* Set a breakpoint at callee's return address (the address
             at which the caller will resume).  */
          goo ();
          bar ();
        }
      else
        /* Set a breakpoint at callee's return address (the address
           at which the caller will resume).  */
        insert_step_resume_breakpoint_at_caller (get_current_frame ());

> >> +      /* Else just reset the step range and keep going.
> >> +        No step-resume breakpoint, they don't work for
> >> +        epilogues, which can have multiple entry paths.  */
> >> +      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.

-- 
Pedro Alves


  reply	other threads:[~2008-10-06 21:14 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 [this message]
2008-10-06 21:22       ` Michael Snyder
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=200810062214.49011.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=msnyder@vmware.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