From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25745 invoked by alias); 27 Nov 2012 21:58:23 -0000 Received: (qmail 25732 invoked by uid 22791); 27 Nov 2012 21:58:22 -0000 X-SWARE-Spam-Status: No, hits=-9.0 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 21:58:17 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 6677333BF55; Tue, 27 Nov 2012 21:58:15 +0000 (UTC) From: Mike Frysinger To: gdb-patches@sourceware.org Subject: Re: [patch+7.5.1] Work around PR libc/13097 "linux-vdso.so.1" #3 Date: Tue, 27 Nov 2012 21:58:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.6.5; KDE/4.6.5; x86_64; ; ) Cc: Pedro Alves , Jan Kratochvil References: <20121122201737.GA32172@host2.jankratochvil.net> <20121123123952.GA15371@host2.jankratochvil.net> <50AF9DBF.1090406@redhat.com> In-Reply-To: <50AF9DBF.1090406@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4210279.Py62W9WFO0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201211271659.11975.vapier@gentoo.org> X-IsSubscribed: yes 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/msg00784.txt.bz2 --nextPart4210279.Py62W9WFO0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 3022 On Friday 23 November 2012 11:01:03 Pedro Alves wrote: > On 11/23/2012 12:39 PM, Jan Kratochvil wrote: > > Besides that there is no standard for any such rule and I consider this > > patch only as a workaround of a WONTFIXed glibc PR. >=20 > Given the new order of glibc maintenance, if we believe glibc's WONTFIX w= as > wrong, then we should reopen the PR, and retry discussing the issue. i think the glibc behavior is actually nice and we don't want to revert it.= =20=20 if i'm single stepping through code that enters the vdso, if gdb doesn't kn= ow=20 about it, it looks like i just stepped off into the weeds and the program i= s=20 doing something wrong. if, instead, it told me i was in the vdso (and we h= ad=20 some way of communicating symbol information), that's a lot more useful. > "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." >=20 > So your example had a slash. If there'd be no slash, the below applies: >=20 > "First, the dynamic array tag DT_RPATH may give a string that holds a li= st > 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 [s= ee > exec(BA_OS)] may hold a list of directories as above, optionally followed > by a semicolon (;) and another directory list." >=20 > The following values would be equivalent to the previous example: > LD_LIBRARY_PATH=3D/home/dir/lib:/home/dir2/lib: > LD_LIBRARY_PATH=3D/home/dir/lib;/home/dir2/lib: > LD_LIBRARY_PATH=3D/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." there's actually a 4th way according to the ELF spec: DT_RUNPATH is after=20 LD_LIBRARY_PATH and before the runtime ldso falls back to its own=20 configuration. further, if DT_RUNPATH is set, the DT_RPATH settings are=20 ignored. this can make a difference if LD_LIBRARY_PATH is in use. beyond that, while not part of the ELF spec, every ldso worth using has a=20 ld.so.cache which it consults before the paths it has hardcoded internally.= =20=20 although any path loaded via either of those mechanisms will be a full path= ,=20 so gdb probably need not worry about it. -mike --nextPart4210279.Py62W9WFO0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJQtTevAAoJEEFjO5/oN/WBkCoP/jM7vElA5VPY7WgSgOIkbkW5 S6WAUHjoRcaN07FwNn0XW4GBoHM22cOaeKt2E2G78CoEMGC5VET7aH52zCBArEZt zTEbXXBqV9gbkoNunMvcgPpEdrkheyDoel17HCq1C1eAnmdQXxQAknk/cnJQPsik iNxQU758LjgqveS09Kwcu6bRY6dsu5c+V3hY55HOQ4Ehe/IM7a36fTcMIOdpBFmI qXC4JdUbdRYBuQBnXPImKNMmExj3DXPKge3AGd546yd7HXNDkwwAKI68AZQPDZUw +KSSZybAlh07U/9ieGABhrq5KWLNXWg9U+B+AFpdNds6Badws08nsp8Af66A6LQM aKfHdv4pXmlHScOm0jqoX6sHmKaz8PLIiqVuEvhRVVC497mmPmugu5UukUgOt5vb gmWrJcnbEkc/BkV9piDrnt8l0Bl0eN0KJxubkbp83t+vNTGigOh8Gl0uFDB9OBpZ ds7R8tF0pv9i7UMIw0vcywRGKHenJhoZ9VbsiHkh/uuK2Hzm7STY5M3zrR2HLvrH vmRsxIb/VBNFscGQwaK8j/sSj4YUBhmZMIkcFU3BcKb23llyClQ2wq+r9TgVDP/v 8cBIRfocTfT6s7FO9Qfid3wiTr1N31waIeE24d0hbH+/YSaPymjs0vcp5koTx096 Wa73WjnnXJj7h7cfAK5O =GYvW -----END PGP SIGNATURE----- --nextPart4210279.Py62W9WFO0--