All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v5 1/4] gdb: Add OpenRISC or1k and or1knd target support
Date: Fri, 17 Mar 2017 10:48:25 +0200	[thread overview]
Message-ID: <83lgs4z3ty.fsf@gnu.org> (raw)
In-Reply-To: <61be7be503333904f9533549b0a809bed4066ac3.1489728533.git.shorne@gmail.com> (message from Stafford Horne on Fri, 17 Mar 2017 14:43:17 +0900)

> From: Stafford Horne <shorne@gmail.com>
> Cc: Franck Jullien <franck.jullien@gmail.com>,	openrisc at lists.librecores.org
> Date: Fri, 17 Mar 2017 14:43:17 +0900
> 
> This patch prepates the current GDB port of the openrisc processor from
> https://github.com/openrisc/binutils-gdb for upstream merging.

Thanks.  Some comments on the documentation part of the patch.

> + at node OpenRISC 1000
> + at subsection OpenRISC 1000
> + at cindex OpenRISC 1000
> +
> +Previous development versions of @value{GDBN} supported remote connection
> +via a proprietary JTAG protocol using the @samp{target jtag} command.
> +Support for this has now been dropped.
> +
> +Also, previous verions had support for a @samp{spr} command to access
> +OpenRISC's numberous special purpose registers.  These are now available
> +via the normal @samp{info registers} command.

I'm not sure this is appropriate for the manual.  The manual should
describe what GDB currently does, not what it did before and no longer
does.  This text is more appropriate for NEWS, which specifically
describe changes wrt previous code.

> + at kindex target remote
> + at item target remote
> +
> +Connects to remote JTAG server.
> +This is now the only way to connect to a remote OpenRISC 1000
> +target.

Likewise for this sentence: if you don't describe any other way of
connecting, there's no need to say this is the only way.

> +There are some known problems with the current implementation

This should have a colon at its end.

> + at cindex OpenRISC 1000 known problems
> +
> + at enumerate
> +
> + at item
> + at cindex OpenRISC 1000 known problems, hardware breakpoints and watchpoints

It is not useful to have 2 or more index entries starting from the
same string and pointing to the same or very close places.  I would
suggest instead

  @cindex hardware breakpoints and watchpoints, known problems on OpenRISC 1000

> +Some OpenRISC 1000 targets support hardware breakpoints and watchpoints.
> +Consult the target documentation for details.  @value{GDBN} is not
> +perfect in handling of watchpoints.  It is possible to allocate hardware
> +watchpoints and not discover until running that sufficient watchpoints
> +are not available.  It is also possible that GDB will report watchpoints
> +being hit spuriously.  This can be down to the assembly code having
> +additional memory accesses that are not obviously reflected in the
> +source code.

The index entry mentions hardware breakpoints, but the text
exclusively mentions only watchpoints.  Are hardware breakpoints
affected like that as well?

> + at item
> + at cindex OpenRISC 1000 known problems, architectural compatibility

Same comment as above about this index entry.

> +The OpenRISC 1000 architecture has evolved since the first port for
> + at value{GDBN}.  In particular the structure of the Unit Present register has
> +changed and the CPU Configuration register has been added.  The port of
> + at value{GDBN} version @value{GDBVN} uses the @emph{current}
> +specification of the OpenRISC 1000.

I'm not sure what this text conveys.  Can you tell why it is important
to have this information in the manual?  I might then suggest a change
in wording.

  reply	other threads:[~2017-03-17  8:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17  5:43 [OpenRISC] [PATCH v5 0/4] OpenRISC gdb port Stafford Horne
2017-03-17  5:43 ` [OpenRISC] [PATCH v5 1/4] gdb: Add OpenRISC or1k and or1knd target support Stafford Horne
2017-03-17  8:48   ` Eli Zaretskii [this message]
2017-03-17  9:32     ` Stafford Horne
2017-03-17  9:35       ` Eli Zaretskii
2017-03-17 10:03         ` Stafford Horne
2017-04-04 21:17   ` Yao Qi
2017-04-08  9:36     ` Stafford Horne
2017-03-17  5:43 ` [OpenRISC] [PATCH v5 2/4] gdb: provide openrisc target description XML files Stafford Horne
2017-04-04 21:25   ` Yao Qi
2017-04-08  9:38     ` Stafford Horne
2017-03-17  5:43 ` [OpenRISC] [PATCH v5 3/4] gdb: testsuite: Add or1k l.nop inscruction Stafford Horne
2017-04-04 21:29   ` Yao Qi
2017-03-17  5:43 ` [OpenRISC] [PATCH v5 4/4] Add gdb for or1k build Stafford Horne
2017-04-04 21:32   ` Yao Qi
2017-03-21  9:14 ` [OpenRISC] [PATCH v5 0/4] OpenRISC gdb port Yao Qi
2017-03-21 14:17   ` Stafford Horne

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=83lgs4z3ty.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=openrisc@lists.librecores.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.