[PATCH] Limited export of dynamic syms (elf32)

[PATCH] Limited export of dynamic syms (elf32)

[Eirik Byrkjeflot Anonsen]

I have implemented a possibility for exporting only selected symbols
as dynamic symbols in the elf32 case.

Important gotcha:  I have not tested this on anything but elf32, so
I don't know if it breaks anything.

I've added an option '--retain-dynamic-symbols-file' which is completely
parallell to '--retain-symbols-file'.  If '-E' is given (export dynamic
symbols), '--retain-dynamic-symbols-file <filename>' will limit the
exported symbols to the symbols listed in the file <filename>.


For those who knows this part of the code, I'm sure my code is obvious.
It is a fairly straightforward copy of --retain-symbols-file.  I also
expect that it would be easy to add the support to non-elf32 builds.



Here is a quick description, including some gotchas:


bfd/elflink.h

I have added a function elf_export_symbol_filtered.  It is almost identical
to elf_export_symbol, but I need extra parameters, and I don't know the ld
code well enough to know if I'll get them automatically.  See the comment
at the top of the function.  I assume that I will always get the correct
parameter, in which case, this function could replace elf_export_symbol
instead.


I have also changed the call to do the export to the new function.
The old code is there too, in an "if (0)".  There is probably negligible
speed loss from using the filtered version in both cases, though
I haven't measured.



include/bfdlink.h

struct bfd_link_info: added the hash table of symbols to export.



ld/ldmain.c (and ldmain.h)

init the hash table of symbols to export.

Added a function to handle --retain_dynamic_symbols_file
(add_keepdynsyms_file), which is mostly a straightforward copy of
add_keepsyms_file.



ld/lexsup.c

Added the option (--retain_dynamic_symbols_file)


eirik
diff -ru src-2.11/bfd/elflink.h src-2.11-local/bfd/elflink.h
--- src-2.11/bfd/elflink.h	Tue Jan 23 11:45:53 2001
+++ src-2.11-local/bfd/elflink.h	Thu Aug 16 14:17:22 2001
@@ -28,6 +28,17 @@
   struct bfd_link_info *info;
 };
 
+
+/* This struct is used to pass the params to the
+ * elf_export_symbol_filtered function (through elf_hash_traverse)
+ */
+struct elf_export_symbol_filtered_params
+{
+	struct elf_info_failed *eif;
+	struct bfd_hash_table *keep_hash;
+};
+
+
 static boolean elf_link_add_object_symbols
   PARAMS ((bfd *, struct bfd_link_info *));
 static boolean elf_link_add_archive_symbols
@@ -38,6 +49,8 @@
 	   boolean *, boolean *, boolean *, boolean));
 static boolean elf_export_symbol
   PARAMS ((struct elf_link_hash_entry *, PTR));
+static boolean elf_export_symbol_filtered
+  PARAMS ((struct elf_link_hash_entry *, PTR));
 static boolean elf_fix_symbol_flags
   PARAMS ((struct elf_link_hash_entry *, struct elf_info_failed *));
 static boolean elf_adjust_dynamic_symbol
@@ -2960,8 +2973,17 @@
 
 	  eif.failed = false;
 	  eif.info = info;
-	  elf_link_hash_traverse (elf_hash_table (info), elf_export_symbol,
-			          (PTR) &eif);
+	  if (0) /* Always do the filtered version */
+	  {
+	    elf_link_hash_traverse (elf_hash_table (info), elf_export_symbol,
+			            (PTR) &eif);
+	  } else {
+	    struct elf_export_symbol_filtered_params params;
+	    params.eif=&eif;
+	    params.keep_hash=info->keep_dynsyms_hash;
+	    elf_link_hash_traverse (elf_hash_table (info), elf_export_symbol_filtered,
+			            (PTR) &params);
+	  };
 	  if (eif.failed)
 	    return false;
 	}
@@ -3694,6 +3717,32 @@
 
   return true;
 }
+
+
+/* This routine is used to conditionally export all defined symbols into
+ * the dynamic symbol table.  It is called via elf_link_hash_traverse.
+ *
+ * This routine differs from elf_export_symbol in that it looks through
+ * a hash of symbols and only exports those that are found in that hash.
+ *
+ * The main reason for making a new function out of it, is to make sure
+ * that I get the right bfd_link_info.  If I can trust that eif->info (in
+ * elf_export_symbol) is the correct bfd_link_info, I could use that instead.
+ */
+static boolean
+elf_export_symbol_filtered(h, data)
+     struct elf_link_hash_entry *h;
+     PTR data;
+{
+  struct elf_export_symbol_filtered_params *params=(struct elf_export_symbol_filtered_params*) data;
+  if (params->keep_hash==NULL ||
+      bfd_hash_lookup (params->keep_hash, h->root.root.string, false, false) != NULL
+	  )
+    return elf_export_symbol(h, params->eif);
+  else
+    return true;
+};
+
 \f
 /* Look through the symbols which are defined in other shared
    libraries and referenced here.  Update the list of version
diff -ru src-2.11/include/bfdlink.h src-2.11-local/include/bfdlink.h
--- src-2.11/include/bfdlink.h	Tue Dec 12 20:53:02 2000
+++ src-2.11-local/include/bfdlink.h	Thu Aug 16 14:21:28 2001
@@ -268,6 +268,11 @@
 
   /* May be used to set DT_FLAGS_1 for ELF. */
   bfd_vma flags_1;
+
+  /* Hash table of dynamic symbols to export.  If NULL, export everything.
+   * Only has any effect if dynamic symbols are exported at all.
+   */
+  struct bfd_hash_table *keep_dynsyms_hash;
 };
 
 /* This structures holds a set of callback functions.  These are
diff -ru src-2.11/ld/ldmain.c src-2.11-local/ld/ldmain.c
--- src-2.11/ld/ldmain.c	Tue Dec 12 20:53:00 2000
+++ src-2.11-local/ld/ldmain.c	Thu Aug 16 14:23:03 2001
@@ -242,6 +242,7 @@
   link_info.new_dtags = false;
   link_info.flags = (bfd_vma) 0;
   link_info.flags_1 = (bfd_vma) 0;
+  link_info.keep_dynsyms_hash = NULL;
 
   ldfile_add_arch ("");
 
@@ -713,6 +714,70 @@
 
   link_info.strip = strip_some;
 }
+
+
+/* Handle the --retain-dynamic-symbols option.
+ * This is mostly a copy of add_keepsyms_file
+ */
+void
+add_keepdynsyms_file(filename)
+  const char * filename;
+{
+  FILE *file;
+  char *buf;
+  size_t bufsize;
+  int c;
+
+  file = fopen (filename, "r");
+  if (file == (FILE *) NULL)
+    {
+      bfd_set_error (bfd_error_system_call);
+      einfo ("%X%P: %s: %E\n", filename);
+      return;
+    }
+
+  if (link_info.keep_dynsyms_hash == NULL)
+  {
+    link_info.keep_dynsyms_hash = ((struct bfd_hash_table *)
+			   xmalloc (sizeof (struct bfd_hash_table)));
+    if (! bfd_hash_table_init (link_info.keep_dynsyms_hash, bfd_hash_newfunc))
+      einfo (_("%P%F: bfd_hash_table_init failed: %E\n"));
+  };
+
+  bufsize = 100;
+  buf = (char *) xmalloc (bufsize);
+
+  c = getc (file);
+  while (c != EOF)
+    {
+      while (isspace (c))
+	c = getc (file);
+
+      if (c != EOF)
+	{
+	  size_t len = 0;
+
+	  while (! isspace (c) && c != EOF)
+	    {
+	      buf[len] = c;
+	      ++len;
+	      if (len >= bufsize)
+		{
+		  bufsize *= 2;
+		  buf = xrealloc (buf, bufsize);
+		}
+	      c = getc (file);
+	    }
+
+	  buf[len] = '\0';
+
+	  if (bfd_hash_lookup (link_info.keep_dynsyms_hash, buf, true, true)
+	      == (struct bfd_hash_entry *) NULL)
+	    einfo (_("%P%F: bfd_hash_lookup for insertion failed: %E\n"));
+	}
+    }
+
+};
 \f
 /* Callbacks from the BFD linker routines.  */
 
diff -ru src-2.11/ld/ldmain.h src-2.11-local/ld/ldmain.h
--- src-2.11/ld/ldmain.h	Mon May  3 07:29:07 1999
+++ src-2.11-local/ld/ldmain.h	Thu Aug 16 14:17:23 2001
@@ -36,5 +36,6 @@
 extern void add_ysym PARAMS ((const char *));
 extern void add_wrap PARAMS ((const char *));
 extern void add_keepsyms_file PARAMS ((const char *filename));
+extern void add_keepdynsyms_file PARAMS ((const char *filename));
 
 #endif
diff -ru src-2.11/ld/lexsup.c src-2.11-local/ld/lexsup.c
--- src-2.11/ld/lexsup.c	Sun Jan 14 04:36:34 2001
+++ src-2.11-local/ld/lexsup.c	Thu Aug 16 14:17:23 2001
@@ -89,7 +89,8 @@
 #define OPTION_OFORMAT			(OPTION_NO_WHOLE_ARCHIVE + 1)
 #define OPTION_RELAX			(OPTION_OFORMAT + 1)
 #define OPTION_RETAIN_SYMBOLS_FILE	(OPTION_RELAX + 1)
-#define OPTION_RPATH			(OPTION_RETAIN_SYMBOLS_FILE + 1)
+#define OPTION_RETAIN_DYNAMIC_SYMBOLS_FILE  (OPTION_RETAIN_SYMBOLS_FILE + 1)
+#define OPTION_RPATH			(OPTION_RETAIN_DYNAMIC_SYMBOLS_FILE + 1)
 #define OPTION_RPATH_LINK		(OPTION_RPATH + 1)
 #define OPTION_SHARED			(OPTION_RPATH_LINK + 1)
 #define OPTION_SONAME			(OPTION_SHARED + 1)
@@ -330,6 +331,9 @@
   { {"retain-symbols-file", required_argument, NULL,
        OPTION_RETAIN_SYMBOLS_FILE},
       '\0', N_("FILE"), N_("Keep only symbols listed in FILE"), TWO_DASHES },
+  { {"retain-dynamic-symbols-file", required_argument, NULL,
+       OPTION_RETAIN_DYNAMIC_SYMBOLS_FILE},
+      '\0', N_("FILE"), N_("Keep only dynamic symbols listed in FILE"), TWO_DASHES },
   { {"rpath", required_argument, NULL, OPTION_RPATH},
       '\0', N_("PATH"), N_("Set runtime shared library search path"), ONE_DASH },
   { {"rpath-link", required_argument, NULL, OPTION_RPATH_LINK},
@@ -863,6 +867,11 @@
 	  break;
 	case OPTION_RETAIN_SYMBOLS_FILE:
 	  add_keepsyms_file (optarg);
+	  break;
+	case OPTION_RETAIN_DYNAMIC_SYMBOLS_FILE:
+	  add_keepdynsyms_file (optarg);
+	  /* Implied --export-dynamic */
+	  command_line.export_dynamic=true;
 	  break;
 	case 'S':
 	  link_info.strip = strip_debugger;

Re: [PATCH] Limited export of dynamic syms (elf32)

[Andreas Jaeger]

Eirik Byrkjeflot Anonsen <eirik@opera.com> writes:

> I have implemented a possibility for exporting only selected symbols
> as dynamic symbols in the elf32 case.

Is this for shared libs or for applications?  What is the advantage of
this over symbol versioning?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: [PATCH] Limited export of dynamic syms (elf32)

[Eirik Byrkjeflot Anonsen]

Andreas Jaeger wrote:
> 
> Eirik Byrkjeflot Anonsen <eirik@opera.com> writes:
> 
> > I have implemented a possibility for exporting only selected symbols
> > as dynamic symbols in the elf32 case.
> 
> Is this for shared libs or for applications?  What is the advantage of
> this over symbol versioning?
> 
> Andreas


I believe it works for both.  The reason for implementing it was
to make Opera/Linux not export internal symbols that could expose
parts of the program that we don't want exposed (like the registration
code...).  Another reason is the possibility of a shared library loaded
by Opera (like a plug-in) accidentally calling internal functions of
Opera.  And finally, we saved roughly 1.5 Mb (IIRC) on the final
executable size.

Given a shared library with only a few functions that
are supposed to be called, all three of these concerns are quite valid.
With the addition that the library could accidentally override a symbol
in another library due to having the same name.

Incidentally, I forgot to mention this in the last mail, but I don't
subscribe to the list, so thanks for mailing me directly.

eirik

Re: [PATCH] Limited export of dynamic syms (elf32)

[Andreas Jaeger]

Eirik Byrkjeflot Anonsen <eirik@opera.com> writes:

> Andreas Jaeger wrote:
> > 
>> Eirik Byrkjeflot Anonsen <eirik@opera.com> writes:
>> 
>> > I have implemented a possibility for exporting only selected symbols
>> > as dynamic symbols in the elf32 case.
>> 
>> Is this for shared libs or for applications?  What is the advantage of
>> this over symbol versioning?
>> 
>> Andreas
>
>
> I believe it works for both.  The reason for implementing it was
> to make Opera/Linux not export internal symbols that could expose
> parts of the program that we don't want exposed (like the registration
> code...).  Another reason is the possibility of a shared library loaded
> by Opera (like a plug-in) accidentally calling internal functions of
> Opera.  And finally, we saved roughly 1.5 Mb (IIRC) on the final
> executable size.
>
> Given a shared library with only a few functions that
> are supposed to be called, all three of these concerns are quite valid.
> With the addition that the library could accidentally override a symbol
> in another library due to having the same name.

For shared libraries we have this functionality with symbol versioning
already.  You can define a map file containing e.g. (this is from
glibc's librt):

GLIBC_2.1 {
  global:
    aio_cancel; aio_cancel64; aio_error; aio_error64; aio_fsync; aio_fsync64;
    aio_init; aio_read; aio_read64; aio_return; aio_return64; aio_suspend;
    aio_suspend64; aio_write; aio_write64; lio_listio; lio_listio64;
  local:
    *;
};

And the library will only export the named interfaces, everything else
is not exported.  I don't see a difference between this and your extension.

I'm not sure whether this works for executables also - but IMO it
would make more sense to extend if it it not works than to introduce
something new.  

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: [PATCH] Limited export of dynamic syms (elf32)

[H . J . Lu]

On Thu, Aug 16, 2001 at 06:14:04PM +0200, Eirik Byrkjeflot Anonsen wrote:
> I have implemented a possibility for exporting only selected symbols
> as dynamic symbols in the elf32 case.
> 
> Important gotcha:  I have not tested this on anything but elf32, so
> I don't know if it breaks anything.
> 

Why do you want to reinvent the wheel? You can use the ELF symbol
versioning on DSOs as well as executables.


H.J.

Re: [PATCH] Limited export of dynamic syms (elf32)

[H . J . Lu]

On Thu, Aug 16, 2001 at 07:04:26PM +0200, Andreas Jaeger wrote:
> 
> I'm not sure whether this works for executables also - but IMO it
> would make more sense to extend if it it not works than to introduce
> something new.  

Yes, symbol versioning works on executables. But you have to get
binutils from CVS or use my Linux binutils. It is in binutils
2.11.90.0.19 or above.



H.J.

Re: [PATCH] Limited export of dynamic syms (elf32)

[Eirik Byrkjeflot Anonsen]

"H . J . Lu" wrote:
> 
> On Thu, Aug 16, 2001 at 07:04:26PM +0200, Andreas Jaeger wrote:
> >
> > I'm not sure whether this works for executables also - but IMO it
> > would make more sense to extend if it it not works than to introduce
> > something new.
> 
> Yes, symbol versioning works on executables. But you have to get
> binutils from CVS or use my Linux binutils. It is in binutils
> 2.11.90.0.19 or above.
> 
> H.J.


Well, in that case, ignore the patch :)

I implemented it because I could not figure out how to avoid
exporting all symbols from an executable with binutils
2.9.5.0.37 (debian stable).  I can maintain that version
internally in Opera until we all got working symbol versioning
(with executables) on all platforms.

Incidentally, I'm not sure that it is obvious that symbol versioning
actually can be used to "unexport" symbols.  I overlooked it completely
when looking for a way to do it.  And I was trying to find that
functionality in the info pages for ld and gcc.  Now that I know what
to look for, I can find it.

eirik

Re: [PATCH] Limited export of dynamic syms (elf32)

[H . J . Lu]

On Fri, Aug 17, 2001 at 08:26:57AM +0200, Eirik Byrkjeflot Anonsen wrote:
> I implemented it because I could not figure out how to avoid
> exporting all symbols from an executable with binutils
> 2.9.5.0.37 (debian stable).  I can maintain that version
> internally in Opera until we all got working symbol versioning
> (with executables) on all platforms.
> 
> Incidentally, I'm not sure that it is obvious that symbol versioning
> actually can be used to "unexport" symbols.  I overlooked it completely

I think you may use symbol versioning to "unexport" symbols on all ELF
targets even if ld.so on those targets don't support symbol versioning.
But I never tried it.


H.J.

Re: [PATCH] Limited export of dynamic syms (elf32)

[Eirik Byrkjeflot Anonsen]

"H . J . Lu" wrote:
> 
> On Fri, Aug 17, 2001 at 08:26:57AM +0200, Eirik Byrkjeflot Anonsen wrote:
> > I implemented it because I could not figure out how to avoid
> > exporting all symbols from an executable with binutils
> > 2.9.5.0.37 (debian stable).  I can maintain that version
> > internally in Opera until we all got working symbol versioning
> > (with executables) on all platforms.
> >
> > Incidentally, I'm not sure that it is obvious that symbol versioning
> > actually can be used to "unexport" symbols.  I overlooked it completely
> 
> I think you may use symbol versioning to "unexport" symbols on all ELF
> targets even if ld.so on those targets don't support symbol versioning.
> But I never tried it.
> 
> H.J.


I've tested it on a shared library with ld 2.9.5, and the symbols bound
to "local:" seems to disappear from the dynamic symbol table.  I'll
have to do some more testing to be absolutely sure, but it looks
promising.

Maybe it would be a good idea to add
@cindex limiting export of dynamic symbols
or something like that to the @node VERSION in ld.texinfo.
That might make it possible to discover that the ability is there.

Or maybe there should be a "How to do special tasks" section that could
contain descriptions of these things.  I don't know what other more or
less obscure tasks would qualify for this section, though.

eirik

Re: [PATCH] Limited export of dynamic syms (elf32)

[Andreas Jaeger]

Eirik Byrkjeflot Anonsen <eirik@opera.com> writes:

> "H . J . Lu" wrote:
> > 
>> On Fri, Aug 17, 2001 at 08:26:57AM +0200, Eirik Byrkjeflot Anonsen wrote:
>> > I implemented it because I could not figure out how to avoid
>> > exporting all symbols from an executable with binutils
>> > 2.9.5.0.37 (debian stable).  I can maintain that version
>> > internally in Opera until we all got working symbol versioning
>> > (with executables) on all platforms.
>> >
>> > Incidentally, I'm not sure that it is obvious that symbol versioning
>> > actually can be used to "unexport" symbols.  I overlooked it completely
>> 
>> I think you may use symbol versioning to "unexport" symbols on all ELF
>> targets even if ld.so on those targets don't support symbol versioning.
>> But I never tried it.
>> 
>> H.J.
>
>
> I've tested it on a shared library with ld 2.9.5, and the symbols bound

As HJ mentioned in an earlier message:
} Yes, symbol versioning works on executables. But you have to get
} binutils from CVS or use my Linux binutils. It is in binutils
} 2.11.90.0.19 or above.

Please try a newer version of binutils if you look at at the
executables part also.  

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: [PATCH] Limited export of dynamic syms (elf32)

[Eirik Byrkjeflot Anonsen]

Andreas Jaeger wrote:
> 
> Eirik Byrkjeflot Anonsen <eirik@opera.com> writes:
> 
> > "H . J . Lu" wrote:
> > >
> >> On Fri, Aug 17, 2001 at 08:26:57AM +0200, Eirik Byrkjeflot Anonsen wrote:
> >> > I implemented it because I could not figure out how to avoid
> >> > exporting all symbols from an executable with binutils
> >> > 2.9.5.0.37 (debian stable).  I can maintain that version
> >> > internally in Opera until we all got working symbol versioning
> >> > (with executables) on all platforms.
> >> >
> >> > Incidentally, I'm not sure that it is obvious that symbol versioning
> >> > actually can be used to "unexport" symbols.  I overlooked it completely
> >>
> >> I think you may use symbol versioning to "unexport" symbols on all ELF
> >> targets even if ld.so on those targets don't support symbol versioning.
> >> But I never tried it.
> >>
> >> H.J.
> >
> >
> > I've tested it on a shared library with ld 2.9.5, and the symbols bound
> 
> As HJ mentioned in an earlier message:
> } Yes, symbol versioning works on executables. But you have to get
> } binutils from CVS or use my Linux binutils. It is in binutils
> } 2.11.90.0.19 or above.
> 
> Please try a newer version of binutils if you look at at the
> executables part also.
> 
> Andreas

I will, but I expect it will work.  After all, there isn't that much
of a difference between the dynamic symbol sections of a shared elf
library and an elf executable :)

And even if it should turn out not to work, I now know where to try
to fix that problem.

Thanks for your help (all of it, both of you)!

eirik

Re: [PATCH] Limited export of dynamic syms (elf32)

[H . J . Lu]

On Mon, Aug 20, 2001 at 10:20:01AM +0200, Eirik Byrkjeflot Anonsen wrote:
> 
> I've tested it on a shared library with ld 2.9.5, and the symbols bound
> to "local:" seems to disappear from the dynamic symbol table.  I'll
> have to do some more testing to be absolutely sure, but it looks
> promising.

Please don't use ld 2.9.5 as a reference linker. All kinds of bugs have
been fixed since 2.9.5.

> 
> Maybe it would be a good idea to add
> @cindex limiting export of dynamic symbols
> or something like that to the @node VERSION in ld.texinfo.
> That might make it possible to discover that the ability is there.

I added some doc for that. Please check out the current binutils. All
the features of symbol versioning are documented there.


H.J.

Re: [PATCH] Limited export of dynamic syms (elf32)

[Eirik Byrkjeflot Anonsen]

"H . J . Lu" wrote:
> 
> On Mon, Aug 20, 2001 at 10:20:01AM +0200, Eirik Byrkjeflot Anonsen wrote:
> >
> > I've tested it on a shared library with ld 2.9.5, and the symbols bound
> > to "local:" seems to disappear from the dynamic symbol table.  I'll
> > have to do some more testing to be absolutely sure, but it looks
> > promising.
> 
> Please don't use ld 2.9.5 as a reference linker. All kinds of bugs have
> been fixed since 2.9.5.
> 
> >
> > Maybe it would be a good idea to add
> > @cindex limiting export of dynamic symbols
> > or something like that to the @node VERSION in ld.texinfo.
> > That might make it possible to discover that the ability is there.
> 
> I added some doc for that. Please check out the current binutils. All
> the features of symbol versioning are documented there.
> 
> H.J.


I have had a short look at it, and I still don't see how someone
wondering how to limit the export of dynamic symbols is supposed
to discover how to do this.  While I'm still thinking that adding
something to the index to that effect is a good idea, I've also
got a different suggestion:

When I'm looking for material on exporting dynamic symbols, I
easily find the option -E/--export-dynamic, which states that
it will cause all symbols to be exported.  How about adding
a short statement here, e.g.:
"It is possible to export only a subset of the symbols by binding
to local scope using symbol versioning.  @xref{VERSION}."

eirik

Re: [PATCH] Limited export of dynamic syms (elf32)

[H . J . Lu]

On Tue, Aug 21, 2001 at 02:47:27PM +0200, Eirik Byrkjeflot Anonsen wrote:
> 
> I have had a short look at it, and I still don't see how someone
> wondering how to limit the export of dynamic symbols is supposed
> to discover how to do this.  While I'm still thinking that adding
> something to the index to that effect is a good idea, I've also
> got a different suggestion:
> 
> When I'm looking for material on exporting dynamic symbols, I
> easily find the option -E/--export-dynamic, which states that
> it will cause all symbols to be exported.  How about adding
> a short statement here, e.g.:
> "It is possible to export only a subset of the symbols by binding
> to local scope using symbol versioning.  @xref{VERSION}."

The current version has

`-E'
`--export-dynamic'
...
     You can also use the version script to control what symbols should
     be added to the dynamic symbol table if the output format supports
     it.  See the description of `--version-script' in *Note VERSION::.

It has a different wording.


H.J.

Re: [PATCH] Limited export of dynamic syms (elf32)

[Eirik Byrkjeflot Anonsen]

"H . J . Lu" wrote:
> 
> On Tue, Aug 21, 2001 at 02:47:27PM +0200, Eirik Byrkjeflot Anonsen wrote:
> >
> > I have had a short look at it, and I still don't see how someone
> > wondering how to limit the export of dynamic symbols is supposed
> > to discover how to do this.  While I'm still thinking that adding
> > something to the index to that effect is a good idea, I've also
> > got a different suggestion:
> >
> > When I'm looking for material on exporting dynamic symbols, I
> > easily find the option -E/--export-dynamic, which states that
> > it will cause all symbols to be exported.  How about adding
> > a short statement here, e.g.:
> > "It is possible to export only a subset of the symbols by binding
> > to local scope using symbol versioning.  @xref{VERSION}."
> 
> The current version has
> 
> `-E'
> `--export-dynamic'
> ...
>      You can also use the version script to control what symbols should
>      be added to the dynamic symbol table if the output format supports
>      it.  See the description of `--version-script' in *Note VERSION::.
> 
> It has a different wording.
> 
> H.J.

Oops, you're right.  My mistake.  I used the wrong option for info, so
I read the wrong version...

This is beautiful.  I'm completely happy :)

eirik