From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21677 invoked by alias); 28 Jan 2007 01:22:26 -0000 Received: (qmail 21663 invoked by uid 22791); 28 Jan 2007 01:22:25 -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 01:22:20 +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 l0S1MDf7005426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 27 Jan 2007 19:22:18 -0600 (CST) Message-ID: <45BBFAC5.80009@cse.unl.edu> Date: Sun, 28 Jan 2007 01:22:00 -0000 From: Neo User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: gdb Subject: Failed to read a valid object file image from memory (gdb_6_6-branch, kernel 2.6.20-rc6) Content-Type: text/plain; charset=ISO-8859-1; 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]); Sat, 27 Jan 2007 19:22:18 -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/msg00338.txt.bz2 hi, When I was playing java vm with the latest linux kernel 2.6.20-rc6 on my IA32 machine, I got the following error message while using the latest gdb_6_6-branch. > /home/cjia/research/gdb-6.6-cvs.official/build/gdb/gdb java_g GNU gdb 6.6.0.20070128-cvs Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r -Xlogmm:success_log -XX:+DebugCompPoint -XX:+MonitorCompaction -XmonitorHeap -Xms96m -Xmx96m -cp .:/spec/jvm98 -Dinstall.root=/spec/jvm98/ SpecApplication _202_jess Starting program: /home/cjia/research/jdk/jdk5_svn/control/build/linux-i586/bin/java_g -Xlogmm:success_log -XX:+DebugCompPoint -XX:+MonitorCompaction -XmonitorHeap -Xms96m -Xmx96m -cp .:/spec/jvm98 -Dinstall.root=/spec/jvm98/ SpecApplication _202_jess Failed to read a valid object file image from memory. <<< Erorr message here <<< [Thread debugging using libthread_db enabled] [New Thread -1208969536 (LWP 20786)] Although it will not block my debugging procedure, I still took some time to investigate the problem for fun. The problem happens in the function "add_vsyscall_page", which is going to find object "AT_SYSINFO_EHDR". The following is the debugging output on kernel 2.6.9, which has no such problem with the latest gdb. child:target_xfer_partial (4, (null), 0xa29c8c0, 0x0, 0x0, 4096) = 128, bytes = 10 00 00 00 ff f3 eb bf 06 00 00 00 00 10 00 00 11 00 00 00 64 00 00 00 03 00 00 00 34 80 04 08 04 00 00 00 20 00 00 00 05 00 00 00 07 00 00 00 07 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 09 00 00 00 c0 82 04 08 0b 00 00 00 f4 01 00 00 0c 00 00 00 f4 01 00 00 0d 00 00 00 f4 01 00 00 0e 00 00 00 f4 01 00 00 17 00 00 00 00 00 00 00 0f 00 00 00 3b 46 f0 fe 00 00 00 00 00 00 00 00 This is the current log information: child:target_xfer_partial (4, (null), 0x83118c8, 0x0, 0x0, 4096) = 144, bytes = 20 00 00 00 00 44 ff b7 21 00 00 00 00 e0 ff ff 10 00 00 00 ff fb eb bf 06 00 00 00 00 10 00 00 11 00 00 00 64 00 00 00 03 00 00 00 34 80 04 08 04 00 00 00 20 00 00 00 05 00 00 00 07 00 00 00 07 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 09 00 00 00 c0 82 04 08 0b 00 00 00 f4 01 00 00 0c 00 00 00 f4 01 00 00 0d 00 00 00 f4 01 00 00 0e 00 00 00 f4 01 00 00 17 00 00 00 00 00 00 00 0f 00 00 00 4b eb e0 bf 00 00 00 00 00 00 00 00 In the log file, we can easily identify the AT_SYSINFO_EHDR object as "21 00 00 00 00 e0 ff ff". And gdb correctly uses the "0xFFFFE000" as the memory offset. But the problem happens in the checking function. The output with LD_SHOW_AUXV=1 > LD_SHOW_AUXV=1 /home/cjia/tmp/helloworld AT_SYSINFO: 0xb7f34400 AT_SYSINFO_EHDR: 0xffffe000 AT_HWCAP: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe AT_PAGESZ: 4096 AT_CLKTCK: 100 AT_PHDR: 0x8048034 AT_PHENT: 32 AT_PHNUM: 7 AT_BASE: 0x0 AT_FLAGS: 0x0 AT_ENTRY: 0x80482c0 AT_UID: 500 AT_EUID: 500 AT_GID: 500 AT_EGID: 500 AT_SECURE: 0 AT_PLATFORM: i686 Hello World! 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. 3) Can we just drop the AT_SYSINFO_EHDR that we found in function add_vsyscall_page? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!