An ELF linker patch

An ELF linker patch

[H.J. Lu]

Hi,

This patch fixes the bug with

# gcc -O -g -o sharedstatic main.c libfoo.so -Wl,-rpath,. -Wl,-Bstatic

under glibc 2.1. The problem is there are some data symbols defined in
both the dynamic linker as well as libc.a under glibc 2.1. When
-Wl,-Bstatic is added at the end, the dynamic linker and libc.a are
used for the final link. As the result, those data symbols are defined
in the dynamic executable. But when it runs, the dynamic linker will
be invoked by the kernel to load the dynamic executable. During the
loading, the data symbol definitions in the dynamic linker are used.
But after switching to the executable, the definitions in the executable
are used. It doesn't work very well since the dynamic linker depends on
those data symbols very much.

This patch seems to fix the problem by loading the dynamic linker first
before anything else such that the definitions in libc.a are not used
if the dynamic linker presents.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
Thu Apr 30 08:17:47 1998  H.J. Lu  (hjl@gnu.org)

	* ldlang.c (lang_load_interpreter): LNew function to load the
	dynamic linker.
	(lang_process): Call lang_load_interpreter () before
	open_input_bfds ().

Index: ldlang.c
===================================================================
RCS file: /home/work/cvs/gnu/binutils/ld/ldlang.c,v
retrieving revision 1.32
diff -u -p -r1.32 ldlang.c
--- ldlang.c	1998/03/31 22:25:42	1.32
+++ ldlang.c	1998/04/30 18:36:42
@@ -3219,6 +3219,39 @@ reset_memory_regions ()
     }
 }
 
+static void lang_load_interpreter PARAMS ((CONST char *));
+
+static void
+lang_load_interpreter (interpreter)
+     CONST char *interpreter;
+{
+  if (interpreter != NULL)
+    {
+      lang_input_statement_type *interp = (lang_input_statement_type *)
+	stat_alloc (sizeof (lang_input_statement_type));
+
+      interp->header.next = NULL;
+      interp->header.type = lang_input_statement_enum;
+      interp->target = NULL;
+      interp->filename = interpreter;
+      interp->is_archive = false;
+      interp->real = true;
+      interp->local_sym_name = interpreter;
+      interp->just_syms_flag = false;
+      interp->search_dirs_flag = false;
+      interp->the_bfd = (bfd *) NULL;
+      interp->asymbols = (asymbol **) NULL;
+      interp->next_real_file = (lang_statement_union_type *) NULL;
+      interp->next = (lang_statement_union_type *) NULL;
+      interp->symbol_count = 0;
+      interp->dynamic = config.dynamic_link;
+      interp->whole_archive = whole_archive;
+      interp->loaded = false;
+
+      open_input_bfds ((lang_statement_union_type *) interp, false);
+    }
+}
+
 void
 lang_process ()
 {
@@ -3234,6 +3267,19 @@ lang_process ()
 
   /* Create a bfd for each input file */
   current_target = default_target;
+
+  /* FIXME: Should it go into a new emulation function,
+	    ldemul_before_open ()? For ELF,
+
+     1. Make sure we are creating a dynamic executable in the final
+	link.
+     2. If command_line.interpreter is NULL, get the default
+	interpreter name from the backend. We may need a new function
+	from each ELF backend to return the default interpreter name.
+     3. Call lang_load_interpreter () with the interpreter name.
+   */
+  lang_load_interpreter (command_line.interpreter); 
+
   open_input_bfds (statement_list.head, false);
 
   ldemul_after_open ();

Re: An ELF linker patch

[Ian Lance Taylor]

   From: hjl@lucon.org (H.J. Lu)
   Date: Thu, 30 Apr 1998 11:53:55 -0700 (PDT)

   This patch fixes the bug with

   # gcc -O -g -o sharedstatic main.c libfoo.so -Wl,-rpath,. -Wl,-Bstatic

   under glibc 2.1. The problem is there are some data symbols defined in
   both the dynamic linker as well as libc.a under glibc 2.1. When
   -Wl,-Bstatic is added at the end, the dynamic linker and libc.a are
   used for the final link. As the result, those data symbols are defined
   in the dynamic executable. But when it runs, the dynamic linker will
   be invoked by the kernel to load the dynamic executable. During the
   loading, the data symbol definitions in the dynamic linker are used.
   But after switching to the executable, the definitions in the executable
   are used. It doesn't work very well since the dynamic linker depends on
   those data symbols very much.

   This patch seems to fix the problem by loading the dynamic linker first
   before anything else such that the definitions in libc.a are not used
   if the dynamic linker presents.

It's not correct in general to link against the dynamic linker, so I
don't think this patch is correct.  Moreover, even if it were correct,
it would only work when using the --dynamic-linker option, so it is
fragile.  Moreover, it is clearly wrong when cross linking.

If you are trying to solve a problem specific to the glibc build
process, why not change the above line to explicitly link against the
dynamic linker?

If you are trying to solve a more general problem, then it seems that
there must be magic symbols in the dynamic linker.  Your bug report
lacks specific information, but I don't see how this could arise in
any other way.  If there are magic symbols in the dynamic linker, then
I would suggest that the dynamic linker handle them magically.

Perhaps if you provide some more specific information, like what the
actual bug is, I can suggest a different way to address the problem.

Ian

Re: An ELF linker patch

[Andreas Schwab]

H J Lu <hjl@lucon.org> writes:

|> This patch fixes the bug with

|> # gcc -O -g -o sharedstatic main.c libfoo.so -Wl,-rpath,. -Wl,-Bstatic

Are you sure that we really want to support that?

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: An ELF linker patch

[Ulrich Drepper]

Andreas Schwab <schwab@issan.informatik.uni-dortmund.de> writes:

> |> # gcc -O -g -o sharedstatic main.c libfoo.so -Wl,-rpath,. -Wl,-Bstatic
> 
> Are you sure that we really want to support that?

This and the question what might break for well-behaved programs by
adding these patches is what still keeps me from applying the patches.

IMO we shouldn't present the mxing of dynamic and static binaries as a
usable way.  Everybody should use dynamic binaries, only in very
special cases it might be desirable to rely on this feature.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: An ELF linker patch

[Thomas Bushnell, n/BSG]

   From: Ulrich Drepper <drepper@cygnus.com>
   Date: 04 May 1998 09:18:48 -0700

   IMO we shouldn't present the mxing of dynamic and static binaries as a
   usable way.  Everybody should use dynamic binaries, only in very
   special cases it might be desirable to rely on this feature.

I agree, but I think this means it should be a priority to have a
static-only version of NSS.

Re: An ELF linker patch

[Ulrich Drepper]

tb@MIT.EDU (Thomas Bushnell, n/BSG) writes:

> I agree, but I think this means it should be a priority to have a
> static-only version of NSS.

No, the use of NSS in static binaries should work perfectly.  What
could create problem is loading and unloading of shared objects and
this is what should never be done.

I really wonder why you come up with the idea of a static NSS.  This
is not possible.  NSS modules could be coming from a third-party
package (e.g., there is a LDAP NSS module).  You wouldn't be able to
use it.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------