public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [rfc] Fix remote shared library tests
@ 2011-07-07 17:17 Ulrich Weigand
  2011-07-15 14:33 ` Ulrich Weigand
  0 siblings, 1 reply; 2+ messages in thread
From: Ulrich Weigand @ 2011-07-07 17:17 UTC (permalink / raw)
  To: gdb-patches

Hello,

I've been running the remote testsuite again, and noticed that just about
all shared library tests fail.  This is because:

- we build shared libraries without soname
- when they are linked into the exectuable, the linker creates a DT_NEEDED
  refering to the the library by full pathname
- both executable and libraries are then copied to the home directory of
  the remote machine
- when the executable is started on the remote machine, the dynamic loader
  cannot find the DT_NEEDED under its original pathname

I hadn't seen this problem in the past, because I was always using either
"remote" tests actually running on the same machine, or a setup where
host and target would both have the same home directory NFS-mounted.
In both cases, the target would see the host library at its original
pathname ...

Now, there is a piece of code in gdb_compile that appears to be intended
to handle this: if we're doing remote tests, it adds a -rpath $ORIGIN.
However, this doesn't work for two reasons:

- it tests [is_remote host] instead of [is_remote target]
  (which seems just a mistake; executables generated by gdb_compile
  always execute on the target, so whether or not the *host* where
  GDB runs is itself remote should not matter at all)

- in any case, for DT_NEEDED including full pathnames, -rpath
  setting are completely ignored

To fix the second problem, we need to omit the pathname from the
DT_NEEDED entry.  Since DT_NEEDED is always set to the soname of
the library we link against, we need to set that.  The patch below
sets the soname to just the plain basename when targeting a
remote machine.

With the two changes, all shared library test cases (except tls-shared.exp
which has a separate problem that I'll fix in a follow-up patch) pass.

Tested on an arm-linux-gnueabi target from an x86 host.

Comments?  Am I missing something here?

Bye,
Ulrich


ChangeLog:

	* lib/gdb.exp (gdb_compile): Specify rpath if the *target* is
	a remote machine, not the host.
	(gdb_compile_shlib): Set soname if target is remote.

Index: gdb/testsuite/lib/gdb.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.182
diff -u -p -r1.182 gdb.exp
--- gdb/testsuite/lib/gdb.exp	1 Jul 2011 00:19:25 -0000	1.182
+++ gdb/testsuite/lib/gdb.exp	7 Jul 2011 13:19:23 -0000
@@ -2168,7 +2168,7 @@ proc gdb_compile {source dest type optio
     # dynamically load one by basename, we must specify rpath.  If we
     # are using a remote host, DejaGNU will link to the shared library
     # using a relative path, so again we must specify an rpath.
-    if { $shlib_load || ($shlib_found && [is_remote host]) } {
+    if { $shlib_load || ($shlib_found && [is_remote target]) } {
 	if { ([istarget "*-*-mingw*"]
 	      || [istarget *-*-cygwin*]
 	      || [istarget *-*-pe*]
@@ -2383,7 +2383,17 @@ proc gdb_compile_shlib {sources dest opt
 		 || [istarget *-*-cygwin*]
 		 || [istarget *-*-pe*])} {
 	       lappend link_options "additional_flags=-Wl,--out-implib,${dest}.a"
-	   }
+	   } elseif [is_remote target] {
+	     # By default, we do not set the soname.  This causes the linker
+	     # on ELF systems to create a DT_NEEDED entry in the executable
+	     # refering to the full path name of the library.  This is a
+	     # problem in remote testing if the library is in a different
+	     # directory there.  To fix this, we set a soname of just the
+	     # base filename for the library, and add an appropriate -rpath
+	     # to the main executable (in gdb_compile).
+             set destbase [file tail $dest]
+             lappend link_options "additional_flags=-Wl,-soname,$destbase"
+           }
        }
        if {[gdb_compile "${objects}" "${dest}" executable $link_options] != ""} {
            return -1
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [rfc] Fix remote shared library tests
  2011-07-07 17:17 [rfc] Fix remote shared library tests Ulrich Weigand
@ 2011-07-15 14:33 ` Ulrich Weigand
  0 siblings, 0 replies; 2+ messages in thread
From: Ulrich Weigand @ 2011-07-15 14:33 UTC (permalink / raw)
  To: Ulrich Weigand; +Cc: gdb-patches


> 	* lib/gdb.exp (gdb_compile): Specify rpath if the *target* is
> 	a remote machine, not the host.
> 	(gdb_compile_shlib): Set soname if target is remote.

I've checked this in now.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-07-15 14:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-07 17:17 [rfc] Fix remote shared library tests Ulrich Weigand
2011-07-15 14:33 ` Ulrich Weigand

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).