Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Gary Benson <gbenson@redhat.com>,
	bug-hurd@gnu.org,	thomas@codesourcery.com,
	gdb-patches@sourceware.org
Subject: Re: [PATCHv3,Hurd] Add hardware watch support
Date: Fri, 12 Sep 2014 16:51:00 -0000	[thread overview]
Message-ID: <20140912165149.GD4871@adacore.com> (raw)
In-Reply-To: <20140910224919.GP3244@type.youpi.perso.aquilenet.fr>

> 2014-09-06  Samuel Thibault  <samuel.thibault@ens-lyon.org>
> 
> 	Add hardware watch support to gnu-i386 platform.
> 
> 	* gdb/gdb/gnu-nat.c (inf_threads): New function.
> 	* gdb/gdb/gnu-nat.h (inf_threads_ftype): New type.
> 	(inf_threads): New declaration.
> 	* gdb/gdb/i386gnu-nat.c: Include "x86-nat.h" and "inf-child.h".
> 	[i386_DEBUG_STATE] (i386_gnu_dr_get, i386_gnu_dr_set,
> 	i386_gnu_dr_set_control_one, i386_gnu_dr_set_control,
> 	i386_gnu_dr_set_addr_one, i386_gnu_dr_set_addr, i386_gnu_dr_get_reg,
> 	i386_gnu_dr_get_addr, 386_gnu_dr_get_status, i386_gnu_dr_get_control):
> 	New functions
> 	(reg_addr): New structure.
> 	(_initialize_i386gnu_nat) [i386_DEBUG_STATE]: Initialize hardware i386
> 	debugging register hooks.

In addition to Sergio's comments, I noticed:

You forgot the comment I made about having the function documented
at only one location, and the contents of that documentat. For easy
reference, here are my comments again:

    | Use...
    |
    | /* See gnu-nat.h.  */
    |
    | ... instead.  This is a fairly trivial comment in this case, so
    | not biggie, but the idea is that want to avoid duplicating
    | documentation in order to avoid having one of them being out
    | of sync.
    |
    | And please also make sure to always have an empty line before
    | function documentation and start of implementation.
    |
    | >  void
    | > diff --git a/gdb/gnu-nat.h b/gdb/gnu-nat.h
    | > index 8e949eb..011c38c 100644
    | > --- a/gdb/gnu-nat.h
    | > +++ b/gdb/gnu-nat.h
    | > @@ -29,6 +29,11 @@ extern struct inf *gnu_current_inf;
    | >  /* Converts a GDB pid to a struct proc.  */
    | >  struct proc *inf_tid_to_thread (struct inf *inf, int tid);
    | >
    | > +typedef void (inf_threads_ftype) (struct proc *thread);
    | > +
    | > +/* Iterate F over threads.  */
    |
    | Suggest:
    |
    | /* Call F for every thread in inferior INF.  */
    |
    | This addresses two issues: "Iterate F" sounds odd, but perhaps
    | that's because English is not my native language; but also,
    | it also documents what INF is.

> +static void i386_gnu_dr_set_control_one (struct proc *thread, void *arg)
> +{

For the function implementations, the name of the function should
be at the first column on the next line. This is a GNU Coding Style
(GCS) requirement, and allows easy searching of a function's body by
grepping for "^FUNCTION_NAME". I also think it helps having the name
of the function for each hunk in "diff -p" (not completely sure about
that one).

> +  unsigned long *control = arg;
> +  struct i386_debug_state regs;
> +  i386_gnu_dr_get (&regs, thread);

I just wanted to add that Sergio's request to add an empty line after
the variable declarations is actually a rule in the GDB project.
For the record, our coding standards are documented at:
https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards
It's not complete yet, so do not be too surprise if we come up with
things that you haven't seen there or in the GCS. Do call us on it,
though, and we will update the doc.

> +struct reg_addr {
> +  int regnum;
> +  CORE_ADDR addr;
> +};

While touching this code, we tend to prefer it for struct
definitions if the opening curly brace is at the start of
the next line, please.

        struct reg_addr
        {
          int regnum;
          CORE_ADDR addr;
        };


> +static void i386_gnu_dr_set_addr_one (struct proc *thread, void *arg)

Same as above.

> +  struct reg_addr reg_addr;
> +  gdb_assert (DR_FIRSTADDR <= regnum && regnum <= DR_LASTADDR);

Missing empty line between var declaration and rest of code.


-- 
Joel


  parent reply	other threads:[~2014-09-12 16:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10 22:49 Samuel Thibault
2014-09-10 23:23 ` Sergio Durigan Junior
2014-09-12 18:21   ` Samuel Thibault
2014-09-12 19:18     ` Sergio Durigan Junior
2014-09-12 16:51 ` Joel Brobecker [this message]
2014-09-12 18:24   ` Samuel Thibault
2014-09-12 17:56 ` Thomas Schwinge
2014-09-12 18:01   ` Samuel Thibault
2014-09-12 20:01     ` Joel Brobecker
2014-09-12 21:24       ` Samuel Thibault
2014-09-12 21:42         ` Sergio Durigan Junior
2014-09-15 13:50         ` Joel Brobecker
2014-09-12 18:25   ` Samuel Thibault
2014-09-15 22:08   ` Thomas Schwinge
2014-09-15 23:09     ` Samuel Thibault
2014-09-16  9:00       ` Thomas Schwinge
2014-09-16 23:17         ` Samuel Thibault
2014-09-16 23:29           ` Samuel Thibault

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=20140912165149.GD4871@adacore.com \
    --to=brobecker@adacore.com \
    --cc=bug-hurd@gnu.org \
    --cc=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=thomas@codesourcery.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