From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8840 invoked by alias); 10 Feb 2006 17:15:48 -0000 Received: (qmail 8832 invoked by uid 22791); 10 Feb 2006 17:15:47 -0000 X-Spam-Check-By: sourceware.org Received: from mta07-winn.ispmail.ntl.com (HELO mta07-winn.ispmail.ntl.com) (81.103.221.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Feb 2006 17:15:43 +0000 Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20060210171539.EZAX8780.mta07-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com> for ; Fri, 10 Feb 2006 17:15:39 +0000 Received: from cpc2-oxfd8-0-0-cust771.oxfd.cable.ntl.com ([86.8.143.4]) by aamta11-winn.ispmail.ntl.com with ESMTP id <20060210171539.OXYG11351.aamta11-winn.ispmail.ntl.com@cpc2-oxfd8-0-0-cust771.oxfd.cable.ntl.com> for ; Fri, 10 Feb 2006 17:15:39 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by cpc2-oxfd8-0-0-cust771.oxfd.cable.ntl.com (8.13.4/8.13.4) with ESMTP id k1AHFaEW021176 for ; Fri, 10 Feb 2006 17:15:37 GMT Subject: Whacky ia64: linux_proc_xfer_partial and lseek vs pread64 From: David Lecomber To: gdb Content-Type: text/plain Date: Fri, 10 Feb 2006 17:15:00 -0000 Message-Id: <1139591736.3780.26.camel@cpc2-oxfd8-0-0-cust771.oxfd.cable.ntl.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00084.txt.bz2 Dear Dan and all, It's great that these days we use file access to get at the memory via the /proc filesystem - but there's an interesting sighting on the ia64 (suse 9) in linux_proc_xfer_partial. #ifdef HAVE_PREAD64 if (pread64 (fd, readbuf, len, offset) != len) #else if (lseek (fd, offset, SEEK_SET) == -1 || read (fd, readbuf, len) != len) #endif ret = 0; else ret = len; So, Mr Itanium has pread64, it calls pread64.. it seems to fail regularly.. As the strace log shows. rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 open("/proc/21785/mem", O_RDONLY) = 4 pread(4, 0x60000fffffffa040, 64, 11529215046068469760) = -1 EINVAL (Invalid argument) close(4) = 0 ptrace(PTRACE_PEEKTEXT, 21785, 0xa000000000000000, NULL) = 282584257676671 open("/proc/21785/mem", O_RDONLY) = 4 pread(4, 0x60000fffffffa048, 56, 11529215046068469768) = -1 EINVAL (Invalid argument) close(4) = 0 ptrace(PTRACE_PEEKTEXT, 21785, 0xa000000000000008, NULL) = 0 open("/proc/21785/mem", O_RDONLY) = 4 But, if you change this to actually call lseek, instead of pread, it's a bit more successful. rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 open("/proc/22498/mem", O_RDONLY) = 4 lseek(4, 11529215046068469760, SEEK_SET) = 11529215046068469760 read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0`\6\1\0"..., 64) = 64 close(4) = 0 open("/proc/22498/mem", O_RDONLY) = 4 lseek(4, 11529215046068469824, SEEK_SET) = 11529215046068469824 read(4, "\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\240\0\0"..., 224) = 224 close(4) = 0 open("/proc/22498/mem", O_RDONLY) = 4 lseek(4, 11529215046068469760, SEEK_SET) = 11529215046068469760 read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0`\6\1\0"..., 3408) = 3408 Literally saving over 500 calls to ptrace() in just one stroke. Anyone any idea what's going on? I'd be happy to let someone else formulate the rather obvious patch, as I don't know the behaviour on other platforms. d. -- David Lecomber