Fwd: vdso
vijay nag <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAKhyrx_aX76L70XGWes+M2qsMu+=6E2UhO160YWCkxgGsL5XKA@mail.gmail.com> |
---------- Forwarded message ---------- From: vijay nag <[email protected]> Date: Fri, Jul 5, 2013 at 11:38 AM Subject: Re: vdso To: Jan Kratochvil <[email protected]> On Thu, Jul 4, 2013 at 11:40 AM, Jan Kratochvil <[email protected]> wrote: > On Wed, 03 Jul 2013 17:23:39 +0200, vijay nag wrote: >> On Wednesday, July 3, 2013, Jan Kratochvil <[email protected]> wrote: >> > This warning is tracked as: >> > http://sourceware.org/bugzilla/show_bug.cgi?id=14466 >> > >> > and it is harmless, it should not affect functionality/symbols of GDB. >> > >> > >> > Jan >> > >> Are you suggesting me that it could be a problem with glibc ? > > No. > > > Jan The function linux_proc_xfer_partial() is returning result zero when trying to pread64 /proc/<pid>/mem and errno is set to -EIO. Does that mean kernel doesn't support pread64 on /proc/xxx/mem files ? gdb) l 4392 4393 /* We could keep this file open and cache it - possibly one per 4394 thread. That requires some juggling, but is even faster. */ 4395 sprintf (filename, "/proc/%d/mem", PIDGET (inferior_ptid)); 4396 fd = open (filename, O_RDONLY | O_LARGEFILE); 4397 if (fd == -1) 4398 return 0; 4399 4400 /* If pread64 is available, use it. It's faster if the kernel 4401 supports it (only one syscall), and it's 64-bit safe even on (gdb) l 4402 32-bit platforms (for instance, SPARC debugging a SPARC64 4403 application). */ 4404 #ifdef HAVE_PREAD64 4405 if (pread64 (fd, readbuf, len, offset) != len) 4406 #else 4407 if (lseek (fd, offset, SEEK_SET) == -1 || read (fd, readbuf, len) != len) 4408 #endif 4409 ret = 0; 4410 else 4411 ret = len; (gdb) p *__errno_location() $18 = 5 (gdb)