This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch+7.5.1] Work around PR libc/13097 "linux-vdso.so.1" #3
On 11/23/2012 04:30 PM, H.J. Lu wrote:
> On Thu, Nov 22, 2012 at 12:17 PM, Jan Kratochvil
> <jan.kratochvil@redhat.com> 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 <stdio.h>
> #include <string.h>
>
> 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