This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v5 1/4] gdb: Add OpenRISC or1k and or1knd target support


> From: Stafford Horne <shorne@gmail.com>
> Cc: Franck Jullien <franck.jullien@gmail.com>,	openrisc@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.

> +@node OpenRISC 1000
> +@subsection OpenRISC 1000
> +@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.

> +@kindex target remote
> +@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.

> +@cindex OpenRISC 1000 known problems
> +
> +@enumerate
> +
> +@item
> +@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?

> +@item
> +@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
> +@value{GDBN}.  In particular the structure of the Unit Present register has
> +changed and the CPU Configuration register has been added.  The port of
> +@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]