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: Daniel Jacobowitz <drow at false dot org>
- To: Neo <cjia at cse dot unl dot edu>
- Cc: gdb <gdb at sourceware dot org>
- Date: Sun, 28 Jan 2007 09:02:43 -0500
- 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>
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. Unfortunately, I don't have a 32-bit
kernel running anywhere I can test.
--
Daniel Jacobowitz
CodeSourcery