From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 555 invoked by alias); 23 Nov 2012 18:19:05 -0000 Received: (qmail 542 invoked by uid 22791); 23 Nov 2012 18:19:04 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Nov 2012 18:19:00 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qANIIxS5028722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Nov 2012 13:18:59 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qANIIwJp000692; Fri, 23 Nov 2012 13:18:58 -0500 Message-ID: <50AFBE11.2050908@redhat.com> Date: Fri, 23 Nov 2012 18:19:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "H.J. Lu" CC: Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [patch+7.5.1] Work around PR libc/13097 "linux-vdso.so.1" #3 References: <20121122201737.GA32172@host2.jankratochvil.net> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00627.txt.bz2 On 11/23/2012 04:30 PM, H.J. Lu wrote: > On Thu, Nov 22, 2012 at 12:17 PM, Jan Kratochvil > wrote: >> Hi, >> >> this is an updated version of >> [RFC] Work around PR libc/13097 "linux-vdso.so.1" #2 >> http://sourceware.org/ml/gdb-patches/2011-08/msg00331.html >> according to the Tom's comment >> http://sourceware.org/bugzilla/show_bug.cgi?id=14466#c3 >> >> I remembered it when Joel plans 7.5.1 release, the patch is safe enough and it >> is a FAQ at least on IRC. >> >> Fedora does not have this issue with its Fedora glibc but I have it >> reproducible with FSF glibc build: >> ./gdb -ex r --args $HOME/glibc-root/lib/ld-linux-x86-64.so.2 --library-path $HOME/glibc-root/lib /bin/true >> Starting program: /home/.../glibc-root/lib/ld-linux-x86-64.so.2 --library-path /home/.../glibc-root/lib /bin/true >> warning: Could not load shared library symbols for linux-vdso.so.1. >> Do you need "set solib-search-path" or "set sysroot"? >> [Inferior 1 (process 31807) exited normally] >> >> So there is no testcase as I do not know a real OS where it fails (it probably >> fails on Ubuntu AFAIK). >> >> No regressions on {x86_64,x86_64-m32,i686}-fedora18-linux-gnu. >> >> > > vdso is available from /proc: > > #include > #include > > int > main() > { > FILE *maps; > void *vdso_begin, *vdso_end; > > maps = fopen("/proc/self/maps", "r"); > char buf[1024]; > while (fgets(buf, 1024, maps)) { > if (strstr(buf, "[vdso]")) break; > } > fclose(maps); > > sscanf(buf, "%p-%p", &vdso_begin, &vdso_end); > write(1, vdso_begin, vdso_end - vdso_begin); It's found in AT_SYSINFO_EHDR too. Alternatively to hard coding the names, maybe we could match the vdso address found through that with the addresses found iterating the dynamic linker list, to know which dynamic linker entry is the vdso. > extern int dl_iterate_phdr (int (*__callback) (struct dl_phdr_info *, > size_t, void *), > void *__data); This is basically what GDB does, manually. The issue is knowing _which_ of the DSOs is the vdso, and therefore not finding a file on the file system with that name should be okay. > Can GDB use them to locate vdso? -- Pedro Alves