From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9287 invoked by alias); 22 May 2012 00:05:57 -0000 Received: (qmail 9270 invoked by uid 22791); 22 May 2012 00:05:54 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 May 2012 00:05:41 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SWcbb-0005Xi-VY from Maciej_Rozycki@mentor.com ; Mon, 21 May 2012 17:05:39 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 17:05:20 -0700 Received: from [172.30.0.105] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 22 May 2012 01:05:37 +0100 Date: Tue, 22 May 2012 00:05:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Subject: Re: [PATCH] Linux/gdbserver: Fix memory read ptrace fallback issues In-Reply-To: <4FB6ACEF.2030600@redhat.com> Message-ID: References: <4FB67E6D.2040406@redhat.com> <4FB6ACEF.2030600@redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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/msg00800.txt.bz2 On Fri, 18 May 2012, Pedro Alves wrote: > 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. You're correct, especially EINTR is worth getting right, interrupted syscalls are always rare and unpredictable enough to make debugging their consequences a nightmare. > > 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. I think ultimately we should do it though. The /proc path is surely a later addition and can explain the resulting unfit API that was originally just fine with ptrace, but I think we should straighten it out and give an advantage to the common case. Especially as it's not like the ptrace fallback or platforms where it's the only choice are going to suffer from such a read/write-like API. I think the two choices in the Linux handlers should be factored out into separate functions too. > Thanks. The whole patch is fine with me with this fix. Applied now, thanks for the review. Maciej