From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27881 invoked by alias); 2 Sep 2013 13:05:36 -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 27853 invoked by uid 89); 2 Sep 2013 13:05:36 -0000 Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.222.215) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Sep 2013 13:05:36 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MSGID_MULTIPLE_AT autolearn=no version=3.3.2 X-HELO: mailhost.u-strasbg.fr Received: from mailhost.u-strasbg.fr (localhost [127.0.0.1]) by antispam (Postfix) with ESMTP id 91D7CA0BEE; Mon, 2 Sep 2013 15:05:32 +0200 (CEST) Received: from mailhost.u-strasbg.fr (localhost [127.0.0.1]) by antivirus (Postfix) with ESMTP id 82ACCA0BD6; Mon, 2 Sep 2013 15:05:32 +0200 (CEST) Received: from md16.u-strasbg.fr (md16.u-strasbg.fr [130.79.200.206]) by mr5.u-strasbg.fr (Postfix) with ESMTP id 62533A0BFA; Mon, 2 Sep 2013 15:05:30 +0200 (CEST) Received: from ms14.u-strasbg.fr (ms14.u-strasbg.fr [130.79.204.114]) by md16.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r82D5Um5019514 ; Mon, 2 Sep 2013 15:05:30 +0200 (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (Authenticated sender: mullerp) by ms14.u-strasbg.fr (Postfix) with ESMTPSA id 1E71D1FD89; Mon, 2 Sep 2013 15:05:29 +0200 (CEST) From: "Pierre Muller" To: "'Pedro Alves'" Cc: References: <5223bb46.c6c0420a.5a41.008dSMTPIN_ADDED_BROKEN@mx.google.com> <52248978.90500@redhat.com> In-Reply-To: <52248978.90500@redhat.com> Subject: RE: [RFA] windows-nat.c: Handle ERROR_PARTIAL_COPY in windows_xfer_memory function Date: Mon, 02 Sep 2013 13:05:00 -0000 Message-ID: <000301cea7dd$17bc4af0$4734e0d0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-09/txt/msg00017.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=E9=A0: lundi 2 septembre 2013 14:50 > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFA] windows-nat.c: Handle ERROR_PARTIAL_COPY in > windows_xfer_memory function >=20 > On 09/01/2013 11:10 PM, Pierre Muller wrote: > > This is the patch that Pedro suggested I send > > after his commit to remove deprecated_xfer_memory > > in windows-nat.c. >=20 > Thanks. >=20 > > > > Pedro suggested that I submit this patch separately > > (which I do here)... and with a gdbserver counterpart, > > which I don't... > > > > I tried, but finally realized that given the > > read_memory / write_memory functions type defined > > in target.h target_ops structure, > > there is no way of passing information of partial > > copy and of the length of this partial copy. > > Indeed, the comments state that the return value is either 0 for success > > or errno... > > > > This is not compatible with returning information that only part of the > > request length > > was read/written. >=20 > Well, we could just change that interface to make it possible... >=20 > The thing I don't like with doing this only on the native > side, is that we're trying to get to a point where we > can share the target backends between GDB and gdbserver: Well, when you look at the code inside child_xfer_memory, you can notice that the return value of ReadProcessMemory or WriteProcessMemory is discarded, which means that it does behave more or less like the new windows-nat.c code (at least in case of ERROR_PARTIAL_COPY) for other errors, it might also return garbage... anyhow, the calling code compares the returned value to the requested length (LEN value) so that the risk of generating a successful read_memory despite a failure of ReadProcessMemory function is small... (the uninitialized variable done would need to return the value LEN..) It could of course still happen theoretically... =20 > . >=20 > Doing such a change on the GDB side only just means we're > pushing the feature-parity goal for the Windows port > further away... >=20 > > 2013-09-01 Pierre Muller > > > ... > > Handle ERROR_PARTIAL_COPY error code. > ... >=20 > This part is OK too. (Please commit it separately from the > plongest fix.) Thanks for the approval, patch committed, Pierre Muller