re: vdso

re: vdso

[vijay nag]

Hello,

I recently upgraded my compiler/glibc to gcc-4.7.2/glibc-2.17. If I
enable vdso, gdb is unable to crawl through the stack(back-trace) when
the program does a jump to vdso-area to execute
sysenter system call.

Is it a known issue ?

(gdb) bt
#0  0xb7fff410 in ?? ()
#1  0x122f234e in main (argc=4, argv=0xbffff854, env=0xbffff86c) at
main/sn_main.c:450
(gdb) info register
eax            0xfffffffc	-4
ecx            0x19	25
edx            0x6	6
ebx            0x1dc24c48	499272776
esp            0xbffff2b8	0xbffff2b8
ebp            0xbffff768	0xbffff768
esi            0x6	6
edi            0x43	67
eip            0xb7fff410	0xb7fff410
eflags         0x246	[ PF ZF IF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51
(gdb)  disassemble $eip

0xb7fff400      push   %ecx

                              │
   │0xb7fff401      push   %edx

                                  │
   │0xb7fff402      push   %ebp

                                  │
   │0xb7fff403      mov    %esp,%ebp

                                  │
   │0xb7fff405      sysenter

                                  │
   │0xb7fff407      nop

                                  │
   │0xb7fff408      nop

                                  │
   │0xb7fff409      nop

                                  │
   │0xb7fff40a      nop

                                  │
   │0xb7fff40b      nop

                                  │
   │0xb7fff40c      nop

                                  │
   │0xb7fff40d      nop

                                  │
   │0xb7fff40e      jmp    0xb7fff403

                                  │
   │0xb7fff410      pop    %ebp

                                  │
   │0xb7fff411      pop    %edx

                                  │
   │0xb7fff412      pop    %ecx

                                  │
   │0xb7fff413      ret

cat /proc/15896/smaps | grep vdso
778:b7fff000-b8000000 r-xp b7fff000 00:00 0          [vdso]

Does vdso come with symbols ?

Re: vdso

[Jan Kratochvil]

On Wed, 03 Jul 2013 10:34:43 +0200, vijay nag wrote:
> cat /proc/15896/smaps | grep vdso
> 778:b7fff000-b8000000 r-xp b7fff000 00:00 0          [vdso]
> 
> Does vdso come with symbols ?

For basic ELF symbols it does. Try:
	dump memory /tmp/vdso.so 0xb7fff000 0xb8000000
	readelf -Ws /tmp/vdso.so

and .dynsym section there should contain the symbols:
     4: ffffffffff700ba0   404 FUNC    GLOBAL DEFAULT   15 __vdso_gettimeofday@@LINUX_2.6
     5: ffffffffff700d60    61 FUNC    GLOBAL DEFAULT   15 __vdso_getcpu@@LINUX_2.6
etc.

Then there are also DWARF symbols to see even filenames / line numbers but
those .debug_* sections at least Fedora ships only on disk in kernel-debuginfo
rpm. The symbols get loaded automatically by GDB:
lrwxrwxrwx 1 root root 61 Jul  2 00:43 /usr/lib/debug/.build-id/92/0bba09195bde2b45a7a4eaec1dc78c3157c0f5 -> ../../../../../lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so*
lrwxrwxrwx 1 root root 58 Jul  2 00:43 /usr/lib/debug/.build-id/92/0bba09195bde2b45a7a4eaec1dc78c3157c0f5.debug -> ../../lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so.debug
-rwxr-xr-x 1 root root   4856 Jun 28 16:56 /lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so*
-r--r--r-- 1 root root 104848 Jun 28 16:56 /usr/lib/debug/lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so.debug
$ rpm -qf /lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so /usr/lib/debug/lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so.debug
kernel-3.9.8-200.fc18.x86_64
kernel-debuginfo-3.9.8-200.fc18.x86_64


You should check first /tmp/vdso.so to see whether your Linux kernel or GDB is
the problem.


Jan

Re: vdso

[Jan Kratochvil]

On Wed, 03 Jul 2013 10:48:48 +0200, vijay nag wrote:
>      5: ffffe400    20 FUNC    GLOBAL DEFAULT    6 __kernel_vsyscall@@LINUX_2.5

So your Linux kernel is OK.  You should check GDB function add_vsyscall_page
on your system why it did not do what it should do.


Regards,
Jan

Re: vdso

[vijay nag]

On Wed, Jul 3, 2013 at 2:32 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Wed, 03 Jul 2013 10:48:48 +0200, vijay nag wrote:
>>      5: ffffe400    20 FUNC    GLOBAL DEFAULT    6 __kernel_vsyscall@@LINUX_2.5
>
> So your Linux kernel is OK.  You should check GDB function add_vsyscall_page
> on your system why it did not do what it should do.
>
>
> Regards,
> Jan

Below are the code excerpts from that function. My gdb version is 7.5

dd_vsyscall_page (struct target_ops *target, int from_tty)
{
  CORE_ADDR sysinfo_ehdr;

  if (target_auxv_search (target, AT_SYSINFO_EHDR, &sysinfo_ehdr) > 0
      && sysinfo_ehdr != (CORE_ADDR) 0)
    {
      struct bfd *bfd;
      struct symbol_file_add_from_memory_args args;

      if (core_bfd != NULL)
  bfd = core_bfd;
      else if (exec_bfd != NULL)
  bfd = exec_bfd;
      else
       /* FIXME: cagney/2004-05-06: Should not require an existing
    BFD when trying to create a run-time BFD of the VSYSCALL
    page in the inferior.  Unfortunately that's the current
    interface so for the moment bail.  Introducing a
    ``bfd_runtime'' (a BFD created using the loaded image) file
    format should fix this.  */
  {
    warning (_("Could not load vsyscall page "
         "because no executable was specified\n"
         "try using the \"file\" command first."));
    return;
  }
      args.bfd = bfd;
      args.sysinfo_ehdr = sysinfo_ehdr;
      args.name = xstrprintf ("system-supplied DSO at %s",
            paddress (target_gdbarch, sysinfo_ehdr));
      /* Pass zero for FROM_TTY, because the action of loading the
   vsyscall DSO was not triggered by the user, even if the user
  typed "run" at the TTY.  */
      args.from_tty = 0;
      catch_exceptions (current_uiout, symbol_file_add_from_memory_wrapper,
      &args, RETURN_MASK_ALL);
    }
}

Re: vdso

[vijay nag]

On Wed, Jul 3, 2013 at 2:12 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Wed, 03 Jul 2013 10:34:43 +0200, vijay nag wrote:
>> cat /proc/15896/smaps | grep vdso
>> 778:b7fff000-b8000000 r-xp b7fff000 00:00 0          [vdso]
>>
>> Does vdso come with symbols ?
>
> For basic ELF symbols it does. Try:
>         dump memory /tmp/vdso.so 0xb7fff000 0xb8000000
>         readelf -Ws /tmp/vdso.so
>
> and .dynsym section there should contain the symbols:
>      4: ffffffffff700ba0   404 FUNC    GLOBAL DEFAULT   15 __vdso_gettimeofday@@LINUX_2.6
>      5: ffffffffff700d60    61 FUNC    GLOBAL DEFAULT   15 __vdso_getcpu@@LINUX_2.6
> etc.
>
> Then there are also DWARF symbols to see even filenames / line numbers but
> those .debug_* sections at least Fedora ships only on disk in kernel-debuginfo
> rpm. The symbols get loaded automatically by GDB:
> lrwxrwxrwx 1 root root 61 Jul  2 00:43 /usr/lib/debug/.build-id/92/0bba09195bde2b45a7a4eaec1dc78c3157c0f5 -> ../../../../../lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so*
> lrwxrwxrwx 1 root root 58 Jul  2 00:43 /usr/lib/debug/.build-id/92/0bba09195bde2b45a7a4eaec1dc78c3157c0f5.debug -> ../../lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so.debug
> -rwxr-xr-x 1 root root   4856 Jun 28 16:56 /lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so*
> -r--r--r-- 1 root root 104848 Jun 28 16:56 /usr/lib/debug/lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so.debug
> $ rpm -qf /lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so /usr/lib/debug/lib/modules/3.9.8-200.fc18.x86_64/vdso/vdso.so.debug
> kernel-3.9.8-200.fc18.x86_64
> kernel-debuginfo-3.9.8-200.fc18.x86_64
>
>
> You should check first /tmp/vdso.so to see whether your Linux kernel or GDB is
> the problem.
>
>
> Jan

Following are output of readelf and something is surely amiss like you suggested

readelf -Ws /tmp/vdso.so

Symbol table '.dynsym' contains 9 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: ffffe400     0 SECTION LOCAL  DEFAULT    6
     2: ffffe478     0 SECTION LOCAL  DEFAULT    8
     3: ffffe480     0 SECTION LOCAL  DEFAULT    9
     4: ffffe618     0 SECTION LOCAL  DEFAULT   11
     5: ffffe400    20 FUNC    GLOBAL DEFAULT    6 __kernel_vsyscall@@LINUX_2.5
     6: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS LINUX_2.5
     7: ffffe440     7 FUNC    GLOBAL DEFAULT    6
__kernel_rt_sigreturn@@LINUX_2.5
     8: ffffe420     8 FUNC    GLOBAL DEFAULT    6 __kernel_sigreturn@@LINUX_2.5

Re: vdso

[Jan Kratochvil]

On Wed, 03 Jul 2013 14:05:11 +0200, vijay nag wrote:
> target_memory_read_xxxx returned EIO errno when it tried to read the
> elf of linux-gate.so.1.

And why?  Was the address correct?


> I also observed these console prints from gdb "Failed to read a valid
> object file image from memory." and these logs correspond to
> the same error.
> 
> (gdb) info shared
> warning: Could not load shared library symbols for linux-gate.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> >From        To          Syms Read   Shared Object Library
>                         No          linux-gate.so.1

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

Fwd: vdso

[vijay nag]

---------- Forwarded message ----------
From: vijay nag <vijunag@gmail.com>
Date: Fri, Jul 5, 2013 at 11:38 AM
Subject: Re: vdso
To: Jan Kratochvil <jan.kratochvil@redhat.com>


On Thu, Jul 4, 2013 at 11:40 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Wed, 03 Jul 2013 17:23:39 +0200, vijay nag wrote:
>> On Wednesday, July 3, 2013, Jan Kratochvil <jan.kratochvil@redhat.com> 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)

Re: Fwd: vdso

[vijay nag]

On Sat, Jul 6, 2013 at 12:12 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Fri, 05 Jul 2013 08:12:29 +0200, vijay nag wrote:
>> The function linux_proc_xfer_partial() is returning result zero when
>> trying to pread64 /proc/<pid>/mem and errno is set to -EIO.
>
> And what is 'offset' (and 'len') that time and what is in /proc/PID/maps that
> time?
> Isn't there also some incorrect signed extension of 32-bit address to 64-bit
> address, for example?
>
>
>> Does that mean kernel doesn't support pread64 on /proc/xxx/mem files ?
>
> I do not think so.
>
>
> Jan

Well the problem is not with pread64 and  the same problem is observed
with (lseek, read) pair.
Offset  0xffffe000 doesn't correspond to any mapping in the process
address space and probably is that reason why read is returning EIO ?

Breakpoint 1, linux_proc_xfer_partial (ops=0x8499230,
object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0xbffff250 "\r",
writebuf=0x0, offset=4294967296, len=4294959104)
    at linux-nat.c:4386
4386	  if (object != TARGET_OBJECT_MEMORY || !readbuf)
(gdb) p /x offset
$3 = 0xffffe000
(gdb) p /x len
$4 = 0x34
(gdb)


smap details of VDSO
b7fff000-b8000000 r-xp b7fff000 00:00 0          [vdso]
Size:                 4 kB
Rss:                  0 kB
Shared_Clean:         0 kB
Shared_Dirty:         0 kB
Private_Clean:        0 kB
Private_Dirty:        0 kB

/proc/xxx/maps
08048000-1829a000 r-xp 00000000 00:15 85524508   vdso_trial
1829a000-1befa000 rwxp 10252000 00:15 85524508   vdso_trial
1befa000-1dea0000 rwxp 1befa000 00:00 0          [heap]
b7fff000-b8000000 r-xp b7fff000 00:00 0          [vdso]
bffeb000-c0000000 rwxp bffeb000 00:00 0          [stack]

Re: Fwd: vdso

[Jan Kratochvil]

On Mon, 08 Jul 2013 08:50:49 +0200, vijay nag wrote:
> Breakpoint 1, linux_proc_xfer_partial (ops=0x8499230, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0xbffff250 "\r", writebuf=0x0, offset=4294967296, len=4294959104)
>     at linux-nat.c:4386
> 4386	  if (object != TARGET_OBJECT_MEMORY || !readbuf)
> (gdb) p /x offset
> $3 = 0xffffe000
> (gdb) p /x len
> $4 = 0x34

offset and len in the first line correspond to offset 0x100000000
and len 0xffffe000 resp.  So I do not see the values you printed from GDB
below.

This is general debugging of GDB, it no longer belongs to this list.
You should best file it to GDB Bugzilla and try to provide reproducibility
information.


There seems to be some 32->64bit extension problem (0x100000000).  Isn't the
GDB built for x86_64 target while you run it for i386 target?  This sure
should work but there may be some issues.  Try to build 32-bit host GDB as
troubleshooting:
	CFLAGS=-m32 ./configure i386-unknown-linux-gnu
But this is already rather for the Bugzilla.


Jan

Re: Fwd: vdso

[vijay nag]

On Mon, Jul 8, 2013 at 2:17 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Mon, 08 Jul 2013 08:50:49 +0200, vijay nag wrote:
>> Breakpoint 1, linux_proc_xfer_partial (ops=0x8499230, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0xbffff250 "\r", writebuf=0x0, offset=4294967296, len=4294959104)
>>     at linux-nat.c:4386
>> 4386    if (object != TARGET_OBJECT_MEMORY || !readbuf)
>> (gdb) p /x offset
>> $3 = 0xffffe000
>> (gdb) p /x len
>> $4 = 0x34
>
> offset and len in the first line correspond to offset 0x100000000
> and len 0xffffe000 resp.  So I do not see the values you printed from GDB
> below.
>
> This is general debugging of GDB, it no longer belongs to this list.
> You should best file it to GDB Bugzilla and try to provide reproducibility
> information.
>
>
> There seems to be some 32->64bit extension problem (0x100000000).  Isn't the
> GDB built for x86_64 target while you run it for i386 target?  This sure
> should work but there may be some issues.  Try to build 32-bit host GDB as
> troubleshooting:
>         CFLAGS=-m32 ./configure i386-unknown-linux-gnu
> But this is already rather for the Bugzilla.
>
>
> Jan
I've built 32 bit gdb configured for i686-pc-linux-gnu and my kernel
too is 32 bit one.

gdb
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

uname -a
Linux 2.6.18-myos-v2-38059-deb #1 SMP Sun Apr 3 01:48:20 EDT 2011 i686 GNU/Linux

Are you saying that gdb is miscalculating offset of vdso ?