From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12556 invoked by alias); 22 Sep 2013 14:18:11 -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 12546 invoked by uid 89); 22 Sep 2013 14:18:11 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 22 Sep 2013 14:18:11 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8MEI7CX009179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Sep 2013 10:18:08 -0400 Received: from host2.jankratochvil.net (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8MEI4kt009557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Sep 2013 10:18:06 -0400 Date: Sun, 22 Sep 2013 14:18:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" Cc: "gdb-patches@sourceware.org" Subject: Re: [patch v4 14/24] record-btrace: provide xfer_partial target method Message-ID: <20130922141804.GB19149@host2.jankratochvil.net> References: <1372842874-28951-1-git-send-email-markus.t.metzger@intel.com> <1372842874-28951-15-git-send-email-markus.t.metzger@intel.com> <20130818190753.GK24153@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00798.txt.bz2 On Mon, 16 Sep 2013 11:30:48 +0200, Metzger, Markus T wrote: > > > +static LONGEST > > > +record_btrace_xfer_partial (struct target_ops *ops, enum target_object > > object, > > > + const char *annex, gdb_byte *readbuf, > > > + const gdb_byte *writebuf, ULONGEST offset, > > > + LONGEST len) > > > +{ > > > + struct target_ops *t; > > > + > > > + /* Normalize the request so len is positive. */ if (len < 0) > > > + { > > > + offset += len; > > > + len = - len; > > > + } > > > > I do not see LEN could be < 0, do you? Use just: > > gdb_assetr (len >= 0); > > (It even should never be LEN == 0 but that may not be guaranteed.) > > Hmm, why didn't we use ULONGEST, then? Nobody says the current GDB codebase / API is perfect. Feel free to submit a patch changing len LONGEST->ULONGEST. > It looks like all implementations in target.c assume LEN to be positive without > checking. I'm doing the same. I see you have just removed the "normalization" so btrace code is now like other GDB code, that is also fine. Thanks, Jan