This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Failed to read a valid object file image from memory (gdb_6_6-branch, kernel 2.6.20-rc6)
- From: Neo <cjia at cse dot unl dot edu>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sourceware dot org
- Date: Sun, 28 Jan 2007 12:11:35 -0600
- 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>
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!