From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7986 invoked by alias); 18 May 2012 20:11:46 -0000 Received: (qmail 7974 invoked by uid 22791); 18 May 2012 20:11:45 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 May 2012 20:11:32 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4IKBS2h026740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 May 2012 16:11:29 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4IKBRAw023046; Fri, 18 May 2012 16:11:28 -0400 Message-ID: <4FB6ACEF.2030600@redhat.com> Date: Fri, 18 May 2012 20:11:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Linux/gdbserver: Fix memory read ptrace fallback issues References: <4FB67E6D.2040406@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-05/txt/msg00711.txt.bz2 On 05/18/2012 07:45 PM, Maciej W. Rozycki wrote: >> > So how about just returning immediately if reading from /proc manages to >> > read something? From what you say, the PEEKTEXT fallback then won't just >> > normally fail; it'll _always_ fail. I suspect that'd make the code a bit >> > simpler. > Maybe. Question is, actually why it was written like this in the first > place. And the only answer I could come up with was: to retrieve the > right error code for the caller to investigate. You won't get that with > pread64/read if they succeed reading any data at all, even if the amount > is less than requested. Hence I decided to preserve the original flow. > I do not feel comfortable with cooking up an artificial value of errno. Ah, right, we can't return immediately --- but if we loop pread64/read, handling partial reads (and EINTR, while at it), until it returns error would get us the errno we want, I'd think. I think the code would be more straightforward that way if it works, but anyway, just a suggestion; I'm super fine with your version. > > Alternatively we could revamp the whole API to make > the_target->read_memory return the number of bytes actually read, just > like read and friends do. That would of course ask for a complementing > change to the_target->write_memory too. I even thought about it when I > finally tracked down what the cause of odd behaviour was, but I decided I > was too tired debugging this issue already to turn gdbserver upside down > at that stage. Yeah, certainly not worth the effort at this stage. >> > You shouldn't assume that "errno" is preserved across library >> > calls (memcpy in this case). > Oh, that was an oversight rather than a deliberate assumption, sorry > about that. Here's a trivial update that I have applied to my fix. Thanks. The whole patch is fine with me with this fix. -- Pedro Alves