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

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

[Jan Kratochvil]

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.


Thanks,
Jan


gdb/
2012-11-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdbarch.c: Regenerate.
	* gdbarch.h: Regenerate.
	* gdbarch.sh (solib_file_not_found_is_ok): New.
	Include solib.h.
	* linux-tdep.c (linux_solib_file_not_found_is_ok): New function.
	(linux_init_abi): Install it.
	* solib.c (default_solib_file_not_found_is_ok): New function.
	(update_solib_list): New variable gdbarch.  Substitute it for variable
	ops.  Call gdbarch_solib_file_not_found_is_ok.
	* solib.h (default_solib_file_not_found_is_ok): New declaration.

diff --git a/gdb/gdbarch.sh b/gdb/gdbarch.sh
index 81a70b0..76f0ec9 100755
--- a/gdb/gdbarch.sh
+++ b/gdb/gdbarch.sh
@@ -955,6 +955,10 @@ M:void:info_proc:char *args, enum info_proc_what what:args, what
 # inspected when the symbol search was requested.
 m:void:iterate_over_objfiles_in_search_order:iterate_over_objfiles_in_search_order_cb_ftype *cb, void *cb_data, struct objfile *current_objfile:cb, cb_data, current_objfile:0:default_iterate_over_objfiles_in_search_order::0
 
+# Return non-zero if it is OK we failed to locate shared library file.
+# For example these libraries may exist only in memory (vDSO).
+f:int:solib_file_not_found_is_ok:const char *so_name:so_name:0:default_solib_file_not_found_is_ok::0
+
 EOF
 }
 
@@ -1411,6 +1415,7 @@ cat <<EOF
 #include "observer.h"
 #include "regcache.h"
 #include "objfiles.h"
+#include "solib.h"
 
 /* Static function declarations */
 
diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index dbeed36..c4f7bdd 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -941,6 +941,17 @@ linux_make_corefile_notes_1 (struct gdbarch *gdbarch, bfd *obfd, int *note_size)
 				      linux_collect_thread_registers);
 }
 
+/* Newer glibc no longer clears the Linux vDSO name to "" empty string.  */
+
+static int
+linux_solib_file_not_found_is_ok (const char *so_name)
+{
+  return (strcmp (so_name, "linux-gate.so.1") == 0
+	  || strcmp (so_name, "linux-vdso.so.1") == 0
+	  || strcmp (so_name, "linux-vdso32.so.1") == 0
+	  || strcmp (so_name, "linux-vdso64.so.1") == 0);
+}
+
 /* To be called from the various GDB_OSABI_LINUX handlers for the
    various GNU/Linux architectures and machine types.  */
 
@@ -953,6 +964,8 @@ linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
   set_gdbarch_make_corefile_notes (gdbarch, linux_make_corefile_notes_1);
   set_gdbarch_has_shared_address_space (gdbarch,
 					linux_has_shared_address_space);
+  set_gdbarch_solib_file_not_found_is_ok (gdbarch,
+					  linux_solib_file_not_found_is_ok);
 }
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
diff --git a/gdb/solib.c b/gdb/solib.c
index db3842a..7976679 100644
--- a/gdb/solib.c
+++ b/gdb/solib.c
@@ -642,6 +642,15 @@ solib_used (const struct so_list *const known)
   return 0;
 }
 
+/* By default GDB complains on any missing shared library file via
+   gdbarch_solib_file_not_found_is_ok.  */
+
+int
+default_solib_file_not_found_is_ok (const char *so_name)
+{
+  return 0;
+}
+
 /* Synchronize GDB's shared object list with inferior's.
 
    Extract the list of currently loaded shared objects from the
@@ -668,7 +677,8 @@ solib_used (const struct so_list *const known)
 static void
 update_solib_list (int from_tty, struct target_ops *target)
 {
-  struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  struct gdbarch *gdbarch = target_gdbarch ();
+  struct target_so_ops *ops = solib_ops (gdbarch);
   struct so_list *inferior = ops->current_sos();
   struct so_list *gdb, **gdb_link;
 
@@ -798,7 +808,9 @@ update_solib_list (int from_tty, struct target_ops *target)
 	  TRY_CATCH (e, RETURN_MASK_ERROR)
 	    {
 	      /* Fill in the rest of the `struct so_list' node.  */
-	      if (!solib_map_sections (i))
+	      if (!solib_map_sections (i)
+	          && !gdbarch_solib_file_not_found_is_ok (gdbarch,
+							  i->so_original_name))
 		{
 		  not_found++;
 		  if (not_found_filename == NULL)
diff --git a/gdb/solib.h b/gdb/solib.h
index 7a2ff84..04510b8 100644
--- a/gdb/solib.h
+++ b/gdb/solib.h
@@ -91,4 +91,6 @@ extern CORE_ADDR gdb_bfd_lookup_symbol_from_symtab (bfd *abfd,
 								      void *),
 						    void *data);
 
+extern int default_solib_file_not_found_is_ok (const char *so_name);
+
 #endif /* SOLIB_H */

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

[Luis Gustavo]

On 11/22/2012 06: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.
>
>
> Thanks,
> Jan
>
>
> gdb/
> 2012-11-22  Jan Kratochvil<jan.kratochvil@redhat.com>
>
> 	* gdbarch.c: Regenerate.
> 	* gdbarch.h: Regenerate.
> 	* gdbarch.sh (solib_file_not_found_is_ok): New.
> 	Include solib.h.
> 	* linux-tdep.c (linux_solib_file_not_found_is_ok): New function.
> 	(linux_init_abi): Install it.
> 	* solib.c (default_solib_file_not_found_is_ok): New function.
> 	(update_solib_list): New variable gdbarch.  Substitute it for variable
> 	ops.  Call gdbarch_solib_file_not_found_is_ok.
> 	* solib.h (default_solib_file_not_found_is_ok): New declaration.
>
> diff --git a/gdb/gdbarch.sh b/gdb/gdbarch.sh
> index 81a70b0..76f0ec9 100755
> --- a/gdb/gdbarch.sh
> +++ b/gdb/gdbarch.sh
> @@ -955,6 +955,10 @@ M:void:info_proc:char *args, enum info_proc_what what:args, what
>   # inspected when the symbol search was requested.
>   m:void:iterate_over_objfiles_in_search_order:iterate_over_objfiles_in_search_order_cb_ftype *cb, void *cb_data, struct objfile *current_objfile:cb, cb_data, current_objfile:0:default_iterate_over_objfiles_in_search_order::0
>
> +# Return non-zero if it is OK we failed to locate shared library file.
> +# For example these libraries may exist only in memory (vDSO).
> +f:int:solib_file_not_found_is_ok:const char *so_name:so_name:0:default_solib_file_not_found_is_ok::0
> +
>   EOF
>   }
>
> @@ -1411,6 +1415,7 @@ cat<<EOF
>   #include "observer.h"
>   #include "regcache.h"
>   #include "objfiles.h"
> +#include "solib.h"
>
>   /* Static function declarations */
>
> diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
> index dbeed36..c4f7bdd 100644
> --- a/gdb/linux-tdep.c
> +++ b/gdb/linux-tdep.c
> @@ -941,6 +941,17 @@ linux_make_corefile_notes_1 (struct gdbarch *gdbarch, bfd *obfd, int *note_size)
>   				      linux_collect_thread_registers);
>   }
>
> +/* Newer glibc no longer clears the Linux vDSO name to "" empty string.  */
> +
> +static int
> +linux_solib_file_not_found_is_ok (const char *so_name)
> +{
> +  return (strcmp (so_name, "linux-gate.so.1") == 0
> +	  || strcmp (so_name, "linux-vdso.so.1") == 0
> +	  || strcmp (so_name, "linux-vdso32.so.1") == 0
> +	  || strcmp (so_name, "linux-vdso64.so.1") == 0);
> +}
> +
>   /* To be called from the various GDB_OSABI_LINUX handlers for the
>      various GNU/Linux architectures and machine types.  */
>
> @@ -953,6 +964,8 @@ linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>     set_gdbarch_make_corefile_notes (gdbarch, linux_make_corefile_notes_1);
>     set_gdbarch_has_shared_address_space (gdbarch,
>   					linux_has_shared_address_space);
> +  set_gdbarch_solib_file_not_found_is_ok (gdbarch,
> +					  linux_solib_file_not_found_is_ok);
>   }
>
>   /* Provide a prototype to silence -Wmissing-prototypes.  */
> diff --git a/gdb/solib.c b/gdb/solib.c
> index db3842a..7976679 100644
> --- a/gdb/solib.c
> +++ b/gdb/solib.c
> @@ -642,6 +642,15 @@ solib_used (const struct so_list *const known)
>     return 0;
>   }
>
> +/* By default GDB complains on any missing shared library file via
> +   gdbarch_solib_file_not_found_is_ok.  */
> +
> +int
> +default_solib_file_not_found_is_ok (const char *so_name)
> +{
> +  return 0;
> +}
> +
>   /* Synchronize GDB's shared object list with inferior's.
>
>      Extract the list of currently loaded shared objects from the
> @@ -668,7 +677,8 @@ solib_used (const struct so_list *const known)
>   static void
>   update_solib_list (int from_tty, struct target_ops *target)
>   {
> -  struct target_so_ops *ops = solib_ops (target_gdbarch ());
> +  struct gdbarch *gdbarch = target_gdbarch ();
> +  struct target_so_ops *ops = solib_ops (gdbarch);
>     struct so_list *inferior = ops->current_sos();
>     struct so_list *gdb, **gdb_link;
>
> @@ -798,7 +808,9 @@ update_solib_list (int from_tty, struct target_ops *target)
>   	  TRY_CATCH (e, RETURN_MASK_ERROR)
>   	    {
>   	      /* Fill in the rest of the `struct so_list' node.  */
> -	      if (!solib_map_sections (i))
> +	      if (!solib_map_sections (i)
> +	&&  !gdbarch_solib_file_not_found_is_ok (gdbarch,
> +							  i->so_original_name))
>   		{
>   		  not_found++;
>   		  if (not_found_filename == NULL)
> diff --git a/gdb/solib.h b/gdb/solib.h
> index 7a2ff84..04510b8 100644
> --- a/gdb/solib.h
> +++ b/gdb/solib.h
> @@ -91,4 +91,6 @@ extern CORE_ADDR gdb_bfd_lookup_symbol_from_symtab (bfd *abfd,
>   								      void *),
>   						    void *data);
>
> +extern int default_solib_file_not_found_is_ok (const char *so_name);
> +
>   #endif /* SOLIB_H */
>

Thansk for the patch.

I don't know about the others, but i find the name 
"solib_not_found_is_ok" a little odd. What about "is_ignored_dso", or 
"ignored_solib_p" or something in those veins?

What about linux-gate(32|64).so?

Regards,
Luis

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

[Jan Kratochvil]

On Fri, 23 Nov 2012 12:30:36 +0100, Luis Gustavo wrote:
> I don't know about the others, but i find the name
> "solib_not_found_is_ok" a little odd.

Me too.


> What about "is_ignored_dso", or "ignored_solib_p" or something in those
> veins?

The problem is they are not ignored.


> What about linux-gate(32|64).so?

I have not found any:
	egrep -r 'linux-gate(32|64)' linux

Have you?  Sure the grep above may miss it.


Thanks,
Jan

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

[Luis Machado]

On 11/23/2012 09:40 AM, Jan Kratochvil wrote:
> On Fri, 23 Nov 2012 12:30:36 +0100, Luis Gustavo wrote:
>> I don't know about the others, but i find the name
>> "solib_not_found_is_ok" a little odd.
>
> Me too.
>
>
>> What about "is_ignored_dso", or "ignored_solib_p" or something in those
>> veins?
>
> The problem is they are not ignored.
>
>
>> What about linux-gate(32|64).so?
>
> I have not found any:
> 	egrep -r 'linux-gate(32|64)' linux
>
> Have you?  Sure the grep above may miss it.

I saw a patch addressing this name in libc, but it is a few months old. 
Maybe this is just old naming. I checked out the sources and it's gone now.

Luis

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

[Pedro Alves]

On 11/22/2012 08: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.
> 
> 

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.

-- 
Pedro Alves

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

[Jan Kratochvil]

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

Besides that there is no standard for any such rule and I consider this patch
only as a workaround of a WONTFIXed glibc PR.  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.


Jan

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

[Mark Kettenis]

> Date: Fri, 23 Nov 2012 12:02:41 +0000
> From: Pedro Alves <palves@redhat.com>
> 
> On 11/22/2012 08: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.
> > 
> > 
> 
> Won't real file based DSOs in the loader list _always_ be full paths,
> never relative paths?

I doubt it.

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

[Luis Machado]

On 11/23/2012 10:39 AM, 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 '/'.
>
> Besides that there is no standard for any such rule and I consider this patch
> only as a workaround of a WONTFIXed glibc PR.  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.
>
>
> Jan
>

Maybe something like lrealpath? That would canonicalize the library path.

Luis

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

[Jan Kratochvil]

On Fri, 23 Nov 2012 15:04:53 +0100, Luis Machado wrote:
> Maybe something like lrealpath? That would canonicalize the library path.

I do not see the purpose.

Also calling something like lrealpath is difficult with remote targets,
whether it should be called in gdbserver (but which usually does not have an
idea about shared library names) etc.


Regards,
Jan

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

[Pedro Alves]

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

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

[Mark Kettenis]

> Date: Fri, 23 Nov 2012 16:01:03 +0000
> From: Pedro Alves <palves@redhat.com>
> 
> This means that looking for relative path DSOs in the file system is
> currently depending on GDB's current directory.

Yup, you lose.

> My favorite is opening a DSO symlink like we /proc/PID/exe.

That doesn't really help.  If you replace the DSO the symlink will
point at the new one, not the one loaded by the executable.

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

[Jan Kratochvil]

On Fri, 23 Nov 2012 17:12:33 +0100, Mark Kettenis wrote:
> > My favorite is opening a DSO symlink like we /proc/PID/exe.
> 
> That doesn't really help.  If you replace the DSO the symlink will
> point at the new one, not the one loaded by the executable.

With Linux kernel it will work:

$ md5sum /tmp/sleep;/tmp/sleep 1h &p=$!;rm /tmp/sleep;ls -l /proc/$p/exe;md5sum /proc/$p/exe
85bde4e40576d0fd8172dd3b91822cff  /tmp/sleep
[1] 25677
lrwxrwxrwx 1 jkratoch jkratoch 0 Nov 23 17:17 /proc/25677/exe -> /tmp/sleep\ (deleted)
85bde4e40576d0fd8172dd3b91822cff  /proc/25677/exe


Jan

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

[Pedro Alves]

On 11/23/2012 04:12 PM, Mark Kettenis wrote:
>> Date: Fri, 23 Nov 2012 16:01:03 +0000
>> From: Pedro Alves <palves@redhat.com>
>>
>> This means that looking for relative path DSOs in the file system is
>> currently depending on GDB's current directory.
> 
> Yup, you lose.
> 
>> My favorite is opening a DSO symlink like we /proc/PID/exe.
> 
> That doesn't really help.  If you replace the DSO the symlink will
> point at the new one, not the one loaded by the executable.

No, no, no.   /proc/PID/exe is special.  It's kind of a hard link.   Opening it
opens the old,  before-replacement file.  E.g., try running a program, and
deleting its executable.  You can still open /proc/PID/exe, and it will
open the running program.

>cp /usr/bin/sleep sleep2

>./sleep2 1000&
[1] 26504
>bg
[1]+ ./sleep2 1000 &
>readlink -f /proc/26504/exe
/home/pedro/sleep2
>rm sleep2
>readlink -f /proc/26504/exe
/home/pedro/sleep2 (deleted)
>ls -l /proc/26504/exe
lrwxrwxrwx. 1 pedro pedro 0 Nov 23 16:20 /proc/26504/exe -> /home/pedro/sleep2 (deleted)
>size /proc/26504/exe
   text    data     bss     dec     hex filename
  21645    1200     384   23229    5abd /proc/26504/exe

Let's try replacing it, even:

>echo "hahaha" > sleep2
>size /proc/26504/exe
   text    data     bss     dec     hex filename
  21645    1200     384   23229    5abd /proc/26504/exe

-- 
Pedro Alves

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

[H.J. Lu]

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);

	return 0;
}

or

extern int dl_iterate_phdr (int (*__callback) (struct dl_phdr_info *,
                                               size_t, void *),
                            void *__data);

Can GDB use them to locate vdso?

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

[Joel Brobecker]

Hello,

It seems that the resolution is still under discussion. Let me know
if you'd like me to hold the release while this is being discussed.

-- 
Joel

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

[Jan Kratochvil]

On Fri, 23 Nov 2012 18:28:14 +0100, Joel Brobecker wrote:
> It seems that the resolution is still under discussion. Let me know
> if you'd like me to hold the release while this is being discussed.

I expected it will be easier, as I will therefore start communication on
glibc list go ahead with the release.


Jan

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

[Pedro Alves]

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

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

[Pedro Alves]

On 11/23/2012 06:16 PM, Jan Kratochvil wrote:
> On Fri, 23 Nov 2012 18:28:14 +0100, Joel Brobecker wrote:
>> It seems that the resolution is still under discussion. Let me know
>> if you'd like me to hold the release while this is being discussed.
> 
> I expected it will be easier, as I will therefore start communication on
> glibc list go ahead with the release.

Thinking about this a bit, I realized that I guess the glibc change allows
having a separate debug info file on the file system for the vdso, and having
that just work (a "simpler" alternative to buildid matching).  So from that perspective,
the change seems to have been justified.  (but I don't know whether that was
the rationale).

-- 
Pedro Alves

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

[Jan Kratochvil]

On Fri, 23 Nov 2012 19:18:57 +0100, Pedro Alves wrote:
> 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.

THis is how elfutils does it.  But there can be multiple vDSOs I think while
AT_SYSINFO_EHDR is only one so I have to check that.


Jan

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

[Jan Kratochvil]

On Fri, 23 Nov 2012 19:43:22 +0100, Jan Kratochvil wrote:
> On Fri, 23 Nov 2012 19:18:57 +0100, Pedro Alves wrote:
> > 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.
> 
> THis is how elfutils does it.

Implemented below.

But now it discards any shared libraries which match a symbol file loaded via
add-symbol-file-from-memory.  Which may be OK but it is more widespread change
than before.

Otherwise there are some configuration/interface difficulties, symfile-mem.c
is not present in every configuration so duplicating its check of
target_auxv_search (AT_SYSINFO_EHDR) in solib-svr4.c may not be correct.

But otherwise the symbol file added via add_vsyscall_page cannot be
differentiated later from those added by add-symbol-file-from-memory.

To reduce the change impact some new field / method / interface would have to
be added to communicate with symfile-mem.c with solib-svr4.c

As is I do not recommend it for 7.5.x.


> But there can be multiple vDSOs I think while
> AT_SYSINFO_EHDR is only one so I have to check that.

There is [vdso] which is listed in _r_debug.r_map and handled above.

There is also [vsyscall] but this page does not have ELF format
(and therefore obviously it is also not listed in _r_debug.r_map).
       0:       48 c7 c0 60 00 00 00    mov    $0x60,%rax
       7:       0f 05                   syscall
       9:       c3                      retq
       a:       cc                      int3
[...]
     400:       48 c7 c0 c9 00 00 00    mov    $0xc9,%rax
     407:       0f 05                   syscall
     409:       c3                      retq
     40a:       cc                      int3
[...]
     800:       48 c7 c0 35 01 00 00    mov    $0x135,%rax
     807:       0f 05                   syscall
     809:       c3                      retq
     80a:       cc                      int3
[...]
     fff:       cc                      int3


Jan


gdb/
2012-11-25  Jan Kratochvil  <jan.kratochvil@redhat.com>

	PR 14466
	* solib-svr4.c (svr4_read_so_list): Rename to ...
	(svr4_current_sos_1): ... here and change the function comment.
	(svr4_current_sos): New function.

gdb/testsuite/
2012-11-25  Jan Kratochvil  <jan.kratochvil@redhat.com>

	PR 14466
	* gdb.base/vdso-warning.c: New file.
	* gdb.base/vdso-warning.exp: New file.

diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 37cc654..77f4adc 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -1248,10 +1248,10 @@ svr4_read_so_list (CORE_ADDR lm, struct so_list ***link_ptr_ptr,
     }
 }
 
-/* Implement the "current_sos" target_so_ops method.  */
+/* Implement the main part of the "current_sos" target_so_ops method.  */
 
 static struct so_list *
-svr4_current_sos (void)
+svr4_current_sos_1 (void)
 {
   CORE_ADDR lm;
   struct so_list *head = NULL;
@@ -1322,6 +1322,52 @@ svr4_current_sos (void)
   return head;
 }
 
+/* Filter out vDSO module, if present.  Its symbol file would not be
+   found on disk.  Such OBJFILE would come from add_vsyscall_page.  */
+
+static struct so_list *
+svr4_current_sos (void)
+{
+  struct so_list *so_head = svr4_current_sos_1 ();
+  struct objfile *objfile;
+  struct obj_section *osect;
+
+  ALL_OBJSECTIONS (objfile, osect)
+    {
+      const bfd *abfd = objfile->obfd;
+      const struct bfd_section *sect;
+      const char *name;
+      CORE_ADDR sect_vma;
+      struct so_list **sop;
+
+      if ((bfd_get_file_flags (abfd) & BFD_IN_MEMORY) == 0)
+	continue;
+
+      sect = osect->the_bfd_section;
+      name = bfd_get_section_name (abfd, sect);
+      if (name == NULL || strcmp (name, ".dynamic") != 0)
+	continue;
+
+      sect_vma = (bfd_get_section_vma (abfd, sect)
+		  + ANOFFSET (objfile->section_offsets, sect->index));
+      sop = &so_head;
+      while (*sop)
+	{
+	  struct so_list *so = *sop;
+
+	  if (so->lm_info->l_ld == sect_vma)
+	    {
+	      *sop = so->next;
+	      free_so (so);
+	    }
+	  else
+	    sop = &so->next;
+	}
+    }
+
+  return so_head;
+}
+
 /* Get the address of the link_map for a given OBJFILE.  */
 
 CORE_ADDR
diff --git a/gdb/testsuite/gdb.base/vdso-warning.c b/gdb/testsuite/gdb.base/vdso-warning.c
new file mode 100644
index 0000000..ef89fef
--- /dev/null
+++ b/gdb/testsuite/gdb.base/vdso-warning.c
@@ -0,0 +1,22 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2012 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+int
+main (void)
+{
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.base/vdso-warning.exp b/gdb/testsuite/gdb.base/vdso-warning.exp
new file mode 100644
index 0000000..506b376
--- /dev/null
+++ b/gdb/testsuite/gdb.base/vdso-warning.exp
@@ -0,0 +1,43 @@
+# Copyright 2012 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+standard_testfile
+
+# There's no support for passing environment variables in the remote protocol.
+if { [is_remote target] } {
+    return 0
+}
+
+if { [prepare_for_testing ${testfile}.exp ${testfile} $srcfile] } {
+    return -1
+}
+
+gdb_breakpoint "main"
+
+# Fedora/RHEL glibc does not have this problem reproducible without this line.
+# See PR libc/13097 Comment 2.
+gdb_test_no_output "set environment LD_DEBUG=unused"
+
+gdb_run_cmd
+
+set test "stopped"
+gdb_test_multiple "" $test {
+    -re "Could not load shared library symbols .*\r\n$gdb_prompt $" {
+	fail $test
+    }
+    -re "\r\nBreakpoint \[0-9\]+, main .*\r\n$gdb_prompt $" {
+	pass $test
+    }
+}

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 3019 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Matt Rice]

On Tue, Nov 27, 2012 at 1:59 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday 23 November 2012 11:01:03 Pedro Alves wrote:
>
>>  "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.

there is sort of a 5th, la_objsearch from rtld-audit(7) which can
happen at various stages through all of this to replace a path (see
its FLAG argument) I didn't find anything specifying it in the glibc
manual but  the 'slash characters rule' seems to apply to the return
value, under glibc there is currently no way to do this without
specifying an audit lib as a environment variable, but under sun, a
library could specify one itself by adding a DT_AUDIT or DT_DEPAUDIT
entry in the dynamic section.

not sure how this matters except to say it doesn't appear to be useful
for generating a relative path without a '/' due to the slash
characters rule applying.

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

[Pedro Alves]

On 11/27/2012 09:59 PM, Mike Frysinger wrote:
> 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.

Indeed.  GDB already loads the vDSO 's elf (symfile-mem.c).  GDB finds the vdso address
in the auxv.  I think in Fedora, the idea is to find the debug info file through
build id matching (I haven't checked if that's actually implemented, but in previous
online searches I found references to that).  In
<http://sourceware.org/ml/gdb-patches/2012-11/msg00628.html> I mentioned that this change
could make it possible to find the separate debug file by name.  I think it'd be
nice to turn things around, and list the vDSO in the shared libraries list instead of
hiding it.

BTW, before that change, when the vDSO was nameless, what made sure it didn't appear
in the DSO list?  Where was it skipped?

-- 
Pedro Alves

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1036 bytes --]

On Tuesday 27 November 2012 19:20:15 Pedro Alves wrote:
> BTW, before that change, when the vDSO was nameless, what made sure it
> didn't appear in the DSO list?  Where was it skipped?

i know little about the glibc internals when it comes to the debugger 
interface.  i think the gdb warning started happening after this commit:

commit 73d7af4f4c2b394063cb0b3a33ee2b00b5ad80b4
Author: Ulrich Drepper <drepper@gmail.com>
Date:   Sat Aug 13 22:24:08 2011 -0400

    Implement LD_DEBUG=scopes

which contains:

--- a/elf/rtld.c
+++ b/elf/rtld.c
@@ -1391,7 +1391,7 @@ of this helper program; chances are you did not intend 
to run this program.\n\
          char *copy = malloc (len);
          if (copy == NULL)
        _dl_fatal_printf ("out of memory\n");
-         l->l_libname->name = memcpy (copy, dsoname, len);
+         l->l_name = l->l_libname->name = memcpy (copy, dsoname, len);
        }
 
      /* Add the vDSO to the object list.  */

which is what is reverted in Fedora's glibc version
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Jan Kratochvil]

On Wed, 28 Nov 2012 01:20:15 +0100, Pedro Alves wrote:
> I mentioned that this change could make it possible to find the separate
> debug file by name.

I do not see how it could work, vDSO does not have and cannot have any disk
filename in L_NAME.

Besides that even if there was a way non-build-id verification should never be
implemented for anything new, it does not work well and there is no reason for
it.


Jan

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 777 bytes --]

On Wednesday 28 November 2012 17:44:21 Jan Kratochvil wrote:
> On Wed, 28 Nov 2012 01:20:15 +0100, Pedro Alves wrote:
> > I mentioned that this change could make it possible to find the separate
> > debug file by name.
> 
> I do not see how it could work, vDSO does not have and cannot have any disk
> filename in L_NAME.
> 
> Besides that even if there was a way non-build-id verification should never
> be implemented for anything new, it does not work well and there is no
> reason for it.

the existing mechanisms might not translate cleanly to providing symbol 
information for vdso's.  but i think it's worth figuring out.  i don't think 
Linux is alone when it comes to vdso type functionality ... certainly 
*BSD/Solaris does something similar ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]