From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8212 invoked by alias); 28 Jan 2007 18:11:52 -0000 Received: (qmail 8197 invoked by uid 22791); 28 Jan 2007 18:11:52 -0000 X-Spam-Check-By: sourceware.org Received: from cse-mail.unl.edu (HELO cse-mail.unl.edu) (129.93.165.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 28 Jan 2007 18:11:46 +0000 Received: from [129.93.164.247] (cse-witty-01.unl.edu [129.93.164.247]) (authenticated bits=0) by cse-mail.unl.edu (8.13.6/8.13.5) with ESMTP id l0SIBZ7R000468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jan 2007 12:11:40 -0600 (CST) Message-ID: <45BCE757.60607@cse.unl.edu> Date: Sun, 28 Jan 2007 18:11:00 -0000 From: Neo User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sourceware.org Subject: Re: Failed to read a valid object file image from memory (gdb_6_6-branch, kernel 2.6.20-rc6) References: <45BBFAC5.80009@cse.unl.edu> <20070128140243.GB7486@nevyn.them.org> In-Reply-To: <20070128140243.GB7486@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (cse-mail.unl.edu [129.93.165.11]); Sun, 28 Jan 2007 12:11:40 -0600 (CST) X-Virus-Status: Clean X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00342.txt.bz2 Daniel Jacobowitz wrote: > On Sat, Jan 27, 2007 at 07:22:13PM -0600, Neo wrote: > >> On my machine the configure script assumes that I was equipped with >> pread64. But I got an EIO from that system call. Then, I disable the >> "HAS_PREAD64" macro, I got an invalid argument error from the read >> system call. (in file linux-nat.c) >> >> Now, I am curious about the potential fix for this problem. >> >> 1) Regardless the HAS_PREAD64 macro, it seems that it will definitely >> fail on 32bit machine without large offset support due to that large >> offset as 0xFFFE0000. >> 2) For those machines probably configured with pread64, it seems that >> the function does not working well. At least the checking in the >> ./gdb/configure is not that strict. >> > > No - these shouldn't matter. Glibc is supposed to support pread64 even > if the syscall is missing. We're just making sure the system library > has compile time support for pread64; runtime support is its > responsibility. See __emulate_pread64 in glibc. > > >> 3) Can we just drop the AT_SYSINFO_EHDR that we found in function >> add_vsyscall_page? >> > > I suspect it's actually a kernel bug that you can't read the vsyscall > page. You should be able to; for instance, I can using 32-bit > emulation on a 64-bit system. So, what is the kernel version on your emulator? Thanks, Neo > Unfortunately, I don't have a 32-bit > kernel running anywhere I can test. > > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!