Re: [patch+7.5.1] Work around PR libc/13097 "linux-vdso.so.1" #3

[Mike Frysinger <vapier at gentoo dot org>]

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.
> 
> 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.

i think the glibc behavior is actually nice and we don't want to revert it.  
if i'm single stepping through code that enters the vdso, if gdb doesn't know 
about it, it looks like i just stepped off into the weeds and the program is 
doing something wrong.  if, instead, it told me i was in the vdso (and we had 
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."
> 
> 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."

there's actually a 4th way according to the ELF spec: DT_RUNPATH is after 
LD_LIBRARY_PATH and before the runtime ldso falls back to its own 
configuration.  further, if DT_RUNPATH is set, the DT_RPATH settings are 
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 
ld.so.cache which it consults before the paths it has hardcoded internally.  
although any path loaded via either of those mechanisms will be a full path, 
so gdb probably need not worry about it.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.