From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5033 invoked by alias); 2 Sep 2013 14:01:04 -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 5019 invoked by uid 89); 2 Sep 2013 14:01:04 -0000 Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.222.212) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Sep 2013 14:01:04 +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 B9F2E14084E; Mon, 2 Sep 2013 16:01:00 +0200 (CEST) Received: from mailhost.u-strasbg.fr (localhost [127.0.0.1]) by antivirus (Postfix) with ESMTP id ABE76140848; Mon, 2 Sep 2013 16:01:00 +0200 (CEST) Received: from md16.u-strasbg.fr (md16.u-strasbg.fr [130.79.200.206]) by mr2.u-strasbg.fr (Postfix) with ESMTP id 8C7CC14084E; Mon, 2 Sep 2013 16:00:58 +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 r82E0wLH009103 ; Mon, 2 Sep 2013 16:00:58 +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 2956F1FD84; Mon, 2 Sep 2013 16:00:57 +0200 (CEST) From: "Pierre Muller" To: "'Pedro Alves'" Cc: References: <5223bb46.c6c0420a.5a41.008dSMTPIN_ADDED_BROKEN@mx.google.com> <52248978.90500@redhat.com> <000301cea7dd$17bc4af0$4734e0d0$@muller@ics-cnrs.unistra.fr> <52249053.6050103@redhat.com> <522494dc.297a420a.6ab0.6047SMTPIN_ADDED_BROKEN@mx.google.com> <522497AF.8080800@redhat.com> In-Reply-To: <522497AF.8080800@redhat.com> Subject: RE: [RFA] gdbserver/win32-low.c: Check Read/WriteProcessMemory return value (followup to [RFA] windows-nat.c: Handle ERROR_PARTIAL_COPY in windows_xfer_memory function) Date: Mon, 02 Sep 2013 14:01:00 -0000 Message-ID: <000901cea7e4$d75bc1e0$861345a0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00025.txt.bz2 > > What about this patch, > > it still does not allow to really return the number of bytes read or > > written, > > but at least it checks correctly if the API calls succeeded. > > No, as long as the read_memory/write_memory interfaces do not > support partial transfers, we should only return true if the > all of LEN was transferred. Otherwise, things like: > > static int > gdb_read_memory (CORE_ADDR memaddr, unsigned char *myaddr, int len) > { > ... > { > res = read_inferior_memory (memaddr, myaddr, len); > done_accessing_memory (); > > return res == 0 ? len : -1; > } > } > > will behave incorrectly in the ERROR_PARTIAL_COPY scenario... This is still done in win32_{read/write}_inferior_memory which are the two only callers of the static child_xfer_memory function in win32-low.c Thus the aim was to narrow the behavior gap between windows-nat.c windows_xfer_memory function and the win32-low.c child_xfer_memory function, without (for now) changing anything to the beghavior of gdbserver, as guaranteed by the static int win32_write_inferior_memory (CORE_ADDR memaddr, const unsigned char *myaddr, int len) { return child_xfer_memory (memaddr, (char *) myaddr, len, 1, 0) != len; } code... The only thing I changed is that child_xfer_memory returns the correct amount of read/written memory or -1 if an error, other than ERRO_PARTIAL_COPY, occurred. Thus I think that your answer is missing the intermediate win32_{read/write}_inferior_memory level. Pierre Muller