From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3114 invoked by alias); 23 Nov 2012 16:01:41 -0000 Received: (qmail 3097 invoked by uid 22791); 23 Nov 2012 16:01:39 -0000 X-SWARE-Spam-Status: No, hits=-7.8 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,TW_FD 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 16:01:33 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qANG1Ght027601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 23 Nov 2012 11:01:27 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qANG13ds003220; Fri, 23 Nov 2012 11:01:09 -0500 Message-ID: <50AF9DBF.1090406@redhat.com> Date: Fri, 23 Nov 2012 16:01: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: Jan Kratochvil CC: 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> <50AF65E1.1090308@redhat.com> <20121123123952.GA15371@host2.jankratochvil.net> In-Reply-To: <20121123123952.GA15371@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 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/msg00618.txt.bz2 On 11/23/2012 12:39 PM, Jan Kratochvil wrote: > On Fri, 23 Nov 2012 13:02:41 +0100, Pedro Alves wrote: >> Won't real file based DSOs in the loader list _always_ be full paths, >> never relative paths? I'd think we could always ignore DSOs whose >> path doesn't start with '/', everywhere. > > :|gcc -shared -fPIC -o x.so -x c -;echo 'main(){}'|gcc -o x ./x.so -x c -;gdb ./x -ex start -ex 'p *_r_debug.r_map' -ex 'p *_r_debug.r_map.l_next' -ex 'p *_r_debug.r_map.l_next.l_next' -ex 'p *_r_debug.r_map.l_next.l_next.l_next' -ex 'p *_r_debug.r_map.l_next.l_next.l_next.l_next' -ex 'p *_r_debug.r_map.l_next.l_next.l_next.l_next.l_next' > > $1 = {l_addr = 0, l_name = 0x37e3a1bd69 "", l_ld = 0x600778, l_next = 0x37e3c23818, l_prev = 0x0} > $2 = {l_addr = 140737363566592, l_name = 0x37e3a1bd69 "", l_ld = 0x7ffff7ffe488, l_next = 0x7ffff7ffd648, l_prev = 0x37e3c23288} > $3 = {l_addr = 140737352024064, l_name = 0x7ffff7ffd640 "./x.so", l_ld = 0x7ffff7ffc5e8, l_next = 0x7ffff7dd5000, l_prev = 0x37e3c23818} > ^^^^^^^^ > $4 = {l_addr = 0, l_name = 0x7ffff7ffdb60 "/lib64/libc.so.6", l_ld = 0x37e45b0b40, l_next = 0x37e3c22998, l_prev = 0x7ffff7ffd648} > $5 = {l_addr = 0, l_name = 0x400200 "/lib64/ld-linux-x86-64.so.2", l_ld = 0x37e3c21de8, l_next = 0x0, l_prev = 0x7ffff7dd5000} > > So file based solibs do not have to start with '/'. Interesting. This means that looking for relative path DSOs in the file system is currently depending on GDB's current directory. E.g., take your example, stick a "sleep(1000);" in main, compile, and start x outside gdb. Then, attach to it, and make sure gdb's cwd is not the same as the directory holding the 'x' binary: (gdb) info sharedlibrary >From To Syms Read Shared Object Library No ./x.so 0x0000003d25e1ef60 0x0000003d25f5f7a0 Yes /lib64/libc.so.6 0x0000003d25a00b20 0x0000003d25a1a2e9 Yes /lib64/ld-linux-x86-64.so.2 (gdb) info sharedlibrary >From To Syms Read Shared Object Library No ./x.so 0x0000003d25e1ef60 0x0000003d25f5f7a0 Yes /lib64/libc.so.6 0x0000003d GDB should be able to know where "./x.so" is... But even just looking for the file relative to the inferior's PWD isn't fully correct, as the inferior might have changed current directory before GDB attaches. > Besides that there is no standard for any such rule and I consider this patch > only as a workaround of a WONTFIXed glibc PR. Given the new order of glibc maintenance, if we believe glibc's WONTFIX was wrong, then we should reopen the PR, and retry discussing the issue. > In such case I believe the impact should be minimal. > > Maybe there is even a way how to make l_name really "x.so" above, not sure. Yeah. I haven't looked at relevant glibc's code, but the ELF spec says (thanks to Matt Rice for pointing at it): "If a shared object name has one or more slash (/) characters anywhere in the name, such as /usr/lib/lib2 above or directory/file, the dynamic linker uses that string directly as the path name. If the name has no slashes, such as lib1 above, three facilities specify shared object path search-ing, with the following precedence." So your example had a slash. If there'd be no slash, the below applies: "First, the dynamic array tag DT_RPATH may give a string that holds a list of directories, separated by colons (:). For example, the string /home/dir/lib:/home/dir2/lib: tells the dynamic linker to search first the directory /home/dir/lib, then /home/dir2/lib, and then the current directory to find dependencies. Second, a variable called LD_LIBRARY_PATH in the process environment [see exec(BA_OS)] may hold a list of directories as above, optionally followed by a semicolon (;) and another directory list." The following values would be equivalent to the previous example: LD_LIBRARY_PATH=/home/dir/lib:/home/dir2/lib: LD_LIBRARY_PATH=/home/dir/lib;/home/dir2/lib: LD_LIBRARY_PATH=/home/dir/lib:/home/dir2/lib:; All LD_LIBRARY_PATH directories are searched after those from DT_RPATH. Although some programs (such as the link editor) treat the lists before and after the semicolon differently, the dynamic linker does not. Nevertheless, the dynamic linker accepts the semicolon notation, with the semantics described above. Finally, if the other two groups of directories fail to locate the desired library, the dynamic linker searches /usr/lib." GDB does look at LD_LIBRARY_PATH, but doesn't at DT_RPATH. And gdb also looks at PATH. But this is all best-effort. It reminds me of the the libraries-changed-on-disk-already problem. Similar kind of problem - we miss a reliable way to find the exact same file the inferior loaded, and that'd need better help from the kernel or the loader. My favorite is opening a DSO symlink like we /proc/PID/exe. Maybe the checkpoint/restore work going on the kernel has given us the interfaces already. -- Pedro Alves