Failed to read a valid object file image from memory (gdb_6_6-branch, kernel 2.6.20-rc6)

[Neo <cjia at cse dot unl dot edu>]

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!