From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113819 invoked by alias); 17 Mar 2017 09:32:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 113805 invoked by uid 89); 17 Mar 2017 09:32:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-pf0-f176.google.com Received: from mail-pf0-f176.google.com (HELO mail-pf0-f176.google.com) (209.85.192.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Mar 2017 09:32:50 +0000 Received: by mail-pf0-f176.google.com with SMTP id p189so14215933pfp.1 for ; Fri, 17 Mar 2017 02:32:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JRaedtjKravUjdgDCCfPlIXlVAvpf40AxeljwHsNmg8=; b=j0Hv4Cp1NINepzzMpPEg/VQq2F9bYlzAOmEcTfaYJO93OO9iaDVScRk94ORojMfAn2 tLfcW8LFfXY5ArcE8cJscJIn+3buSDCknP4lhUoUmQMz2SxQs9ZBvCqfWprwO8p3o1Ai yEG2FVaMtIwbiyyeivUicvgeO6SDGsYacAwm5pcoJ5XHIGVhsyw/xcU7Osk3n0HWgCKo i0nH3sO1E01e/FFMv1tUypphdNVRREIVx2cKy2ZVrtctyXoutGYj1ZJRhXl46+COA6L4 U2LAsl210Qqs89GsN75FDoIOEHn/Pc4vcfy68/tZpNChEmaCp6e2heET0gR18yikVqTA 5feA== X-Gm-Message-State: AFeK/H3obOJM5iVImjtQNx857gcdNQEYulvrQV9b2jdIo8jjPLEv9CM2SLjxxmoFJmoFXg== X-Received: by 10.98.99.196 with SMTP id x187mr15352096pfb.168.1489743170191; Fri, 17 Mar 2017 02:32:50 -0700 (PDT) Received: from localhost (z17.124-44-180.ppp.wakwak.ne.jp. [124.44.180.17]) by smtp.gmail.com with ESMTPSA id n8sm15629090pgd.5.2017.03.17.02.32.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 Mar 2017 02:32:49 -0700 (PDT) Date: Fri, 17 Mar 2017 09:32:00 -0000 From: Stafford Horne To: Eli Zaretskii Cc: gdb-patches@sourceware.org, franck.jullien@gmail.com, openrisc@lists.librecores.org Subject: Re: [PATCH v5 1/4] gdb: Add OpenRISC or1k and or1knd target support Message-ID: <20170317093247.GO2418@lianli.shorne-pla.net> References: <61be7be503333904f9533549b0a809bed4066ac3.1489728533.git.shorne@gmail.com> <83lgs4z3ty.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83lgs4z3ty.fsf@gnu.org> User-Agent: Mutt/1.8.0 (2017-02-23) X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00308.txt.bz2 On Fri, Mar 17, 2017 at 10:48:25AM +0200, Eli Zaretskii wrote: > > From: Stafford Horne > > Cc: Franck Jullien , 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. Thanks for reviewing, this is actually the second pass of the documentation. More reviews are welcome. > > +@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. Sure, I can remove. > > +@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. Right. I will correct it to better follow other architectures. > > +There are some known problems with the current implementation > > This should have a colon at its end. ok > > +@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 Good point > > +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? I don't think it applies to both, Ill add a statement explaining about breakpoints. Maybe they should be separate points if they are different. > > +@item > > +@cindex OpenRISC 1000 known problems, architectural compatibility > > Same comment as above about this index entry. Yes > > +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. Its saying that if you are using an old version of the CPU it might not run as expected with this version of GDB. Ill change to explain that without talking about previous ports of GDB. Something like: Earlier version of the OpenRISC architecture did not include the UPR (unit present) or CPUCFGR (CPU configuration) registers. This version of @value{GDBN} expects these to be present. -Stafford