Re: glibc 2.1 and gabi

Re: glibc 2.1 and gabi

[Nick Clifton]

Hi H.J.

: > Do we need a switch, or can this be determined "magically" by
: > examining the input files ?
: 
: No. It is a runtime thing. The same binaries run fine under glibc 2.2.

Oh, OK.


: Well, it is kind of misleading since glibc 2.1 does support dynamic
: tags. It just doesn't support the unknown tags in certain range.
: 
: --enable-new-dynamic-tags
: --no-enable-new-dynamic-tags
: 
: is better.

That is OK with me.

Cheers
	Nick

Re: glibc 2.1 and gabi

[H . J . Lu]

On Thu, Jul 20, 2000 at 12:26:57PM -0700, Nick Clifton wrote:
> : Well, it is kind of misleading since glibc 2.1 does support dynamic
> : tags. It just doesn't support the unknown tags in certain range.
> : 
> : --enable-new-dynamic-tags
> : --no-enable-new-dynamic-tags
> : 
> : is better.
> 
> That is OK with me.

How about just

--disable-new-dynamic-tags
--enable-new-dynamic-tags



H.J.

Re: glibc 2.1 and gabi

[Andrew Cagney]

"H . J . Lu" wrote:
> 
> On Thu, Jul 20, 2000 at 12:26:57PM -0700, Nick Clifton wrote:
> > : Well, it is kind of misleading since glibc 2.1 does support dynamic
> > : tags. It just doesn't support the unknown tags in certain range.
> > :
> > : --enable-new-dynamic-tags
> > : --no-enable-new-dynamic-tags
> > :
> > : is better.
> >
> > That is OK with me.
> 
> How about just
> 
> --disable-new-dynamic-tags
> --enable-new-dynamic-tags

Um, do you really want to call something ``new''.  Similar to the
comment I just posted to GCC-patches, it will be old soon enough.

	Andrew

Re: glibc 2.1 and gabi

[H . J . Lu]

On Mon, Jul 24, 2000 at 01:18:19PM +1000, Andrew Cagney wrote:
> > How about just
> > 
> > --disable-new-dynamic-tags
> > --enable-new-dynamic-tags
> 
> Um, do you really want to call something ``new''.  Similar to the
> comment I just posted to GCC-patches, it will be old soon enough.

I don't mind too much about a different choice. You have to ask Nick.
But that means we have to change glibc since it has used it already.
If we make the change now, I hope it won't be too bad.


H.J.

Re: glibc 2.1 and gabi

[Nick Clifton]

Hi H.J., Hi Andrew,

: > > --disable-new-dynamic-tags
: > > --enable-new-dynamic-tags
: > 
: > Um, do you really want to call something ``new''.  Similar to the
: > comment I just posted to GCC-patches, it will be old soon enough.
: 
: I don't mind too much about a different choice. You have to ask Nick.
: But that means we have to change glibc since it has used it already.
: If we make the change now, I hope it won't be too bad.

It is not important enough to be worth changing now, so lets leave
things as they are.

I do agree with Andrew's point though, so in the future lets see if we
can try to avoid using 'new' in situations like this.

Cheers
	Nick

Re: glibc 2.1 and gabi

[Nick Clifton]

Hi H.J.

: 2000-07-20  H.J. Lu  <hjl@gnu.org>
: 
: 	* elflink.h (NAME(bfd_elf,size_dynamic_sections)): Set
: 	DT_RUNPATH and DT_FLAGS only if info->new_dtags is true.
: 
: 	* bfdlink.h (bfd_link_info): Add new_dtags.
: 
: 	* ld/ld.texinfo: Add documentation for --disable-new-dtags and
: 	--enable-new-dtags.
: 
: 	* ldmain.c (main): Initialize link_info.new_dtags to false.
: 
: 	* emultempl/elf32.em (gld_${EMULATION_NAME}_parse_args): Add
: 	--disable-new-dtags and --enable-new-dtags.
: 	(gld_${EMULATION_NAME}_list_options): Likewise.

Approved.

Cheers
	Nick

Re: glibc 2.1 and gabi

[H . J . Lu]

On Thu, Jul 20, 2000 at 02:12:04PM -0700, Nick Clifton wrote:
> 
> Approved.
> 
> Cheers
> 	Nick

Done.

H.J.

Re: glibc 2.1 and gabi

[Nick Clifton]

Hi H.J.

: How about just
: 
: --disable-new-dynamic-tags
: --enable-new-dynamic-tags

Sure :-)

Cheers
	Nick

Re: glibc 2.1 and gabi

[H . J . Lu]

On Thu, Jul 20, 2000 at 01:17:51PM -0700, Nick Clifton wrote:
> Hi H.J.
> 
> : How about just
> : 
> : --disable-new-dynamic-tags
> : --enable-new-dynamic-tags
> 
> Sure :-)
> 

Here is the patch. I changed them to

--disable-new-dtags
--enable-new-dtags


H.J.
---
2000-07-20  H.J. Lu  <hjl@gnu.org>

	* elflink.h (NAME(bfd_elf,size_dynamic_sections)): Set
	DT_RUNPATH and DT_FLAGS only if info->new_dtags is true.

	* bfdlink.h (bfd_link_info): Add new_dtags.

	* ld/ld.texinfo: Add documentation for --disable-new-dtags and
	--enable-new-dtags.

	* ldmain.c (main): Initialize link_info.new_dtags to false.

	* emultempl/elf32.em (gld_${EMULATION_NAME}_parse_args): Add
	--disable-new-dtags and --enable-new-dtags.
	(gld_${EMULATION_NAME}_list_options): Likewise.

Index: bfd/elflink.h
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v
retrieving revision 1.35
diff -u -p -r1.35 elflink.h
--- bfd/elflink.h	2000/07/20 03:58:11	1.35
+++ bfd/elflink.h	2000/07/20 20:37:48
@@ -2848,7 +2848,8 @@ NAME(bfd_elf,size_dynamic_sections) (out
 				     true, true);
 	  if (indx == (bfd_size_type) -1
 	      || ! elf_add_dynamic_entry (info, DT_RPATH, indx)
-	      || ! elf_add_dynamic_entry (info, DT_RUNPATH, indx))
+	      || (info->new_dtags
+		  && ! elf_add_dynamic_entry (info, DT_RUNPATH, indx)))
 	    return false;
 	}
 
@@ -3137,7 +3138,7 @@ NAME(bfd_elf,size_dynamic_sections) (out
 	  elf_tdata (output_bfd)->cverdefs = cdefs;
 	}
 
-      if (info->flags)
+      if (info->new_dtags && info->flags)
 	{
 	  if (! elf_add_dynamic_entry (info, DT_FLAGS, info->flags))
 	    return false;
Index: include/bfdlink.h
===================================================================
RCS file: /work/cvs/gnu/binutils/include/bfdlink.h,v
retrieving revision 1.8
diff -u -p -r1.8 bfdlink.h
--- include/bfdlink.h	2000/07/20 03:58:20	1.8
+++ include/bfdlink.h	2000/07/20 19:57:10
@@ -247,6 +247,9 @@ struct bfd_link_info
      unloaded.  */
   const char *fini_function;
 
+  /* true if the new ELF dynamic tags are enabled. */ 
+  boolean new_dtags;
+
   /* May be used to set DT_FLAGS for ELF. */
   bfd_vma flags;
 
Index: ld/ld.texinfo
===================================================================
RCS file: /work/cvs/gnu/binutils/ld/ld.texinfo,v
retrieving revision 1.5
diff -u -p -r1.5 ld.texinfo
--- ld/ld.texinfo	2000/07/20 04:07:46	1.5
+++ ld/ld.texinfo	2000/07/20 20:52:15
@@ -1368,6 +1368,17 @@ you should not put the definition of @co
 file as @code{__wrap_malloc}; if you do, the assembler may resolve the
 call before the linker has a chance to wrap it to @code{malloc}.
 
+@kindex --enable-new-dtags
+@kindex --disable-new-dtags
+@item --enable-new-dtags
+@itemx --disable-new-dtags
+This linker can create the new dynamic tags in ELF. But the older ELF
+systems may not understand them. If you specify
+@code{--enable-new-dtags}, the dynamic tags will be created as needed.
+If you specify @code{--disable-new-dtags}, no new dynamic tags will be
+created. By default, the new dynamic tags are not created. Note that
+those options are only available for ELF systems.
+
 @end table
 
 @subsection Options specific to i386 PE targets
Index: ld/ldmain.c
===================================================================
RCS file: /work/cvs/gnu/binutils/ld/ldmain.c,v
retrieving revision 1.14
diff -u -p -r1.14 ldmain.c
--- ld/ldmain.c	2000/07/20 04:07:46	1.14
+++ ld/ldmain.c	2000/07/20 19:57:23
@@ -238,6 +238,7 @@ main (argc, argv)
      and _fini symbols.  We are compatible.  */
   link_info.init_function = "_init";
   link_info.fini_function = "_fini";
+  link_info.new_dtags = false;
   link_info.flags = (bfd_vma) 0;
   link_info.flags_1 = (bfd_vma) 0;
 
Index: ld/emultempl/elf32.em
===================================================================
RCS file: /work/cvs/gnu/binutils/ld/emultempl/elf32.em,v
retrieving revision 1.20
diff -u -p -r1.20 elf32.em
--- ld/emultempl/elf32.em	2000/07/20 18:47:49	1.20
+++ ld/emultempl/elf32.em	2000/07/20 20:34:43
@@ -1219,6 +1219,9 @@ cat >>e${EMULATION_NAME}.c <<EOF
 
 #include "getopt.h"
 
+#define OPTION_DISABLE_NEW_DTAGS	(400)
+#define OPTION_ENABLE_NEW_DTAGS		(OPTION_DISABLE_NEW_DTAGS + 1)
+
 static struct option longopts[] =
 {
 EOF
@@ -1226,7 +1229,8 @@ fi
 
 if test x"$GENERATE_SHLIB_SCRIPT" = xyes; then
 cat >>e${EMULATION_NAME}.c <<EOF
-  {NULL, required_argument, NULL, 'z'},
+  {"disable-new-dtags", no_argument, NULL, OPTION_DISABLE_NEW_DTAGS},
+  {"enable-new-dtags", no_argument, NULL, OPTION_ENABLE_NEW_DTAGS},
 EOF
 fi
 
@@ -1266,11 +1270,20 @@ gld_${EMULATION_NAME}_parse_args (argc, 
 	xexit (1);
       optind =  prevoptind;
       return 0;
+
 EOF
 fi
 
 if test x"$GENERATE_SHLIB_SCRIPT" = xyes; then
 cat >>e${EMULATION_NAME}.c <<EOF
+    case OPTION_DISABLE_NEW_DTAGS:
+      link_info.new_dtags = false;
+      break;
+
+    case OPTION_ENABLE_NEW_DTAGS:
+      link_info.new_dtags = true;
+      break;
+
     case 'z':
       if (strcmp (optarg, "initfirst") == 0)
 	link_info.flags_1 |= (bfd_vma) DF_1_INITFIRST;
@@ -1297,7 +1310,7 @@ cat >>e${EMULATION_NAME}.c <<EOF
 	  link_info.flags_1 |= (bfd_vma) DF_1_ORIGIN;
 	}
       /* What about the other Solaris -z options? FIXME.  */
-    break;
+      break;
 EOF
 fi
 
@@ -1323,6 +1336,8 @@ fi
 
 if test x"$GENERATE_SHLIB_SCRIPT" = xyes; then
 cat >>e${EMULATION_NAME}.c <<EOF
+  fprintf (file, _("  --disable-new-dtags\tDisable new dynamic tags\n"));
+  fprintf (file, _("  --enable-new-dtags\tEnable new dynamic tags\n"));
   fprintf (file, _("  -z initfirst\t\tMark DSO to be initialized first at rutime\n"));
   fprintf (file, _("  -z interpose\t\tMark object to interpose all DSOs but execuable\n"));
   fprintf (file, _("  -z loadfltr\t\tMark object requiring immediate process\n"));

Re: glibc 2.1 and gabi

[Nick Clifton]

Hi H.J.

: I added support for the new DT tags from the new gABI. However, glibc
: 2.1 doesn't support them. I got
: 
: BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed!
: 
: on DT_RUNPATH and DT_FLAGS when -Bsymbolic and -rpath are used. I
: checked Solaris 2.7. Solaris ld.so doesn't complain DT_RUNPATH nor
: DT_FLAGS which it doesn't know. I tend to think it is a glibc 2.1 bug.
: But I don't want to break glibc 2.1. I'd like to add a new option
: to ld to turn on the support for the new DT tags. Any suggestions?
: I am thinking of "-z gabi" for lack of imagination :-). 

Do we need a switch, or can this be determined "magically" by
examining the input files ?

If we need a switch, then I would suggest:

  --enable-dynamic-tags

and:

  --no-enable-dynamic-tags

which presumably would be the default.

Cheers
	Nick

Re: glibc 2.1 and gabi

[H . J . Lu]

On Thu, Jul 20, 2000 at 12:06:37PM -0700, Nick Clifton wrote:
> Hi H.J.
> 
> : I added support for the new DT tags from the new gABI. However, glibc
> : 2.1 doesn't support them. I got
> : 
> : BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed!
> : 
> : on DT_RUNPATH and DT_FLAGS when -Bsymbolic and -rpath are used. I
> : checked Solaris 2.7. Solaris ld.so doesn't complain DT_RUNPATH nor
> : DT_FLAGS which it doesn't know. I tend to think it is a glibc 2.1 bug.
> : But I don't want to break glibc 2.1. I'd like to add a new option
> : to ld to turn on the support for the new DT tags. Any suggestions?
> : I am thinking of "-z gabi" for lack of imagination :-). 
> 
> Do we need a switch, or can this be determined "magically" by
> examining the input files ?

No. It is a runtime thing. The same binaries run fine under glibc 2.2.

> 
> If we need a switch, then I would suggest:
> 
>   --enable-dynamic-tags
> 
> and:
> 
>   --no-enable-dynamic-tags
> 
> which presumably would be the default.
> 

Well, it is kind of misleading since glibc 2.1 does support dynamic
tags. It just doesn't support the unknown tags in certain range.

--enable-new-dynamic-tags
--no-enable-new-dynamic-tags

is better.


H.J.

glibc 2.1 and gabi

[H . J . Lu]

Hi,

I added support for the new DT tags from the new gABI. However, glibc
2.1 doesn't support them. I got

BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed!

on DT_RUNPATH and DT_FLAGS when -Bsymbolic and -rpath are used. I
checked Solaris 2.7. Solaris ld.so doesn't complain DT_RUNPATH nor
DT_FLAGS which it doesn't know. I tend to think it is a glibc 2.1 bug.
But I don't want to break glibc 2.1. I'd like to add a new option
to ld to turn on the support for the new DT tags. Any suggestions?
I am thinking of "-z gabi" for lack of imagination :-). 

Thanks.


H.J.

Re: glibc 2.1 and gabi

[Geoff Keating]

> Date: Thu, 20 Jul 2000 11:42:29 -0700
> From: "H . J . Lu" <hjl@lucon.org>

> Hi,
> 
> I added support for the new DT tags from the new gABI. However, glibc
> 2.1 doesn't support them. I got
> 
> BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed!
> 
> on DT_RUNPATH and DT_FLAGS when -Bsymbolic and -rpath are used. I
> checked Solaris 2.7. Solaris ld.so doesn't complain DT_RUNPATH nor
> DT_FLAGS which it doesn't know. I tend to think it is a glibc 2.1 bug.
> But I don't want to break glibc 2.1. I'd like to add a new option
> to ld to turn on the support for the new DT tags. Any suggestions?
> I am thinking of "-z gabi" for lack of imagination :-). 

I don't understand your problem.  You're creating an executable that
uses new features of ELF which were not implemented in glibc 2.1.
glibc 2.1 complains that it doesn't understand this executable.  The
obvious fix is to make glibc 2.2 understand the executable, then use
glibc 2.2.  Why do you want to do something different?

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: glibc 2.1 and gabi

[H . J . Lu]

On Thu, Jul 20, 2000 at 01:22:31PM -0700, Geoff Keating wrote:
> > Date: Thu, 20 Jul 2000 11:42:29 -0700
> > From: "H . J . Lu" <hjl@lucon.org>
> 
> > Hi,
> > 
> > I added support for the new DT tags from the new gABI. However, glibc
> > 2.1 doesn't support them. I got
> > 
> > BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed!
> > 
> > on DT_RUNPATH and DT_FLAGS when -Bsymbolic and -rpath are used. I
> > checked Solaris 2.7. Solaris ld.so doesn't complain DT_RUNPATH nor
> > DT_FLAGS which it doesn't know. I tend to think it is a glibc 2.1 bug.
> > But I don't want to break glibc 2.1. I'd like to add a new option
> > to ld to turn on the support for the new DT tags. Any suggestions?
> > I am thinking of "-z gabi" for lack of imagination :-). 
> 
> I don't understand your problem.  You're creating an executable that
> uses new features of ELF which were not implemented in glibc 2.1.
> glibc 2.1 complains that it doesn't understand this executable.  The
> obvious fix is to make glibc 2.2 understand the executable, then use
> glibc 2.2.  Why do you want to do something different?

glibc 2.2 is ok. The problem is the existing glibc 2.1 systems. The
binaries created by the new linker under glibc 2.1 may not run due
to those new dtags. I just sent in a new patch which turns off the
new dtag by default so that the linker can create the working binaries
under glibc 2.1.


H.J.

Re: glibc 2.1 and gabi

[Geoff Keating]

> Date: Thu, 20 Jul 2000 13:57:29 -0700
> From: "H . J . Lu" <hjl@lucon.org>
> Cc: libc-hacker@sourceware.cygnus.com, binutils@sourceware.cygnus.com,
>         ian@zembu.com, nick@lucon.org

> glibc 2.2 is ok. The problem is the existing glibc 2.1 systems. The
> binaries created by the new linker under glibc 2.1 may not run due
> to those new dtags. I just sent in a new patch which turns off the
> new dtag by default so that the linker can create the working binaries
> under glibc 2.1.

OK.  That makes sense.

Ideally, you would want to only add the new tags when they make a
difference to how the executable should be treated.  I don't know what
the new tags do so I don't know if this is possible.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: glibc 2.1 and gabi

[H . J . Lu]

On Thu, Jul 20, 2000 at 03:46:40PM -0700, Geoff Keating wrote:
> 
> > glibc 2.2 is ok. The problem is the existing glibc 2.1 systems. The
> > binaries created by the new linker under glibc 2.1 may not run due
> > to those new dtags. I just sent in a new patch which turns off the
> > new dtag by default so that the linker can create the working binaries
> > under glibc 2.1.
> 
> OK.  That makes sense.
> 
> Ideally, you would want to only add the new tags when they make a
> difference to how the executable should be treated.  I don't know what
> the new tags do so I don't know if this is possible.

For the most parts, the new tags replace the old ones with a little
twist. They come from the new gABI.


H.J.

Re: glibc 2.1 and gabi

[Geoff Keating]

> Date: Thu, 20 Jul 2000 15:52:45 -0700
> From: "H . J . Lu" <hjl@lucon.org>
> Cc: libc-hacker@sourceware.cygnus.com, binutils@sourceware.cygnus.com,
>         ian@zembu.com

> For the most parts, the new tags replace the old ones with a little
> twist. They come from the new gABI.

I guess the question I'm really asking is "when do I need to switch on
these tags?  and why can't the linker do it for me?".

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: glibc 2.1 and gabi

[H . J . Lu]

On Thu, Jul 20, 2000 at 04:12:05PM -0700, Geoff Keating wrote:
> > Date: Thu, 20 Jul 2000 15:52:45 -0700
> > From: "H . J . Lu" <hjl@lucon.org>
> > Cc: libc-hacker@sourceware.cygnus.com, binutils@sourceware.cygnus.com,
> >         ian@zembu.com
> 
> > For the most parts, the new tags replace the old ones with a little
> > twist. They come from the new gABI.
> 
> I guess the question I'm really asking is "when do I need to switch on
> these tags?  and why can't the linker do it for me?".

You can use it when you are certain your C library supports it. Glibc
2.2 is ok. The linker may not know what the runtime linker will do
when it sees a known dtag. As more and more new features are added to
those new dtags, glibc may need them to work correctly. 


H.J.

Re: glibc 2.1 and gabi

[Geoff Keating]

> Date: Thu, 20 Jul 2000 17:09:46 -0700
> From: "H . J . Lu" <hjl@lucon.org>
> Cc: libc-hacker@sourceware.cygnus.com, binutils@sourceware.cygnus.com,
>         ian@zembu.com
> Content-Disposition: inline
> User-Agent: Mutt/1.2.2i
> 
> On Thu, Jul 20, 2000 at 04:12:05PM -0700, Geoff Keating wrote:
> > > Date: Thu, 20 Jul 2000 15:52:45 -0700
> > > From: "H . J . Lu" <hjl@lucon.org>
> > > Cc: libc-hacker@sourceware.cygnus.com, binutils@sourceware.cygnus.com,
> > >         ian@zembu.com
> > 
> > > For the most parts, the new tags replace the old ones with a little
> > > twist. They come from the new gABI.
> > 
> > I guess the question I'm really asking is "when do I need to switch on
> > these tags?  and why can't the linker do it for me?".
> 
> You can use it when you are certain your C library supports it. Glibc
> 2.2 is ok. The linker may not know what the runtime linker will do
> when it sees a known dtag. As more and more new features are added to
> those new dtags, glibc may need them to work correctly. 

I know I _can_ use it, but when do I _have_ to use it?  What would go
wrong if the linker never emitted any of these tags?

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: glibc 2.1 and gabi

[H . J . Lu]

On Thu, Jul 20, 2000 at 08:27:31PM -0700, Geoff Keating wrote:
> > 2.2 is ok. The linker may not know what the runtime linker will do
> > when it sees a known dtag. As more and more new features are added to
> > those new dtags, glibc may need them to work correctly. 
> 
> I know I _can_ use it, but when do I _have_ to use it?  What would go
> wrong if the linker never emitted any of these tags?
> 

The reason I added the support is Ulrich wanted DF_1_NODELETE for
libpthread.so. Without it, libpthread.so loaded in via dlopen may
get unloaded by dlclose which will cause problems. Basically, those
new dtags give DSO developers new flexibility and control over DSOs.
You can take a look at

http://docs.sun.com:80/ab2/coll.45.13/LLM/@Ab2PageView/21165?Ab2Lang=C&Ab2Enc=iso-8859-1

to see what you can use. But you will need support from ld.so for any
new features. Ulrich just added the support for DF_1_NODELETE and
DF_1_NOOPEN to glibc 2.2. You can use them on DSOs. I can see
DF_1_INTERPOSE, DF_1_LOADFLTR and DF_1_NODEFLIB be useful to me
in some cases.


H.J.

Re: glibc 2.1 and gabi

[Geoff Keating]

> Date: Thu, 20 Jul 2000 21:14:54 -0700
> From: "H . J . Lu" <hjl@lucon.org>

> On Thu, Jul 20, 2000 at 08:27:31PM -0700, Geoff Keating wrote:
> > I know I _can_ use it, but when do I _have_ to use it?  What would go
> > wrong if the linker never emitted any of these tags?

> The reason I added the support is Ulrich wanted DF_1_NODELETE for
> libpthread.so.
...

So shouldn't we only use the new tags if the user specifies -z
nodelete (or whatever it is)?  That way, it'll all work even on old
glibc versions, unless the user tries to use the new features when
it'll only work on newer glibc versions.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: glibc 2.1 and gabi

[H . J . Lu]

On Thu, Jul 20, 2000 at 11:21:12PM -0700, Geoff Keating wrote:
> > Date: Thu, 20 Jul 2000 21:14:54 -0700
> > From: "H . J . Lu" <hjl@lucon.org>
> 
> > On Thu, Jul 20, 2000 at 08:27:31PM -0700, Geoff Keating wrote:
> > > I know I _can_ use it, but when do I _have_ to use it?  What would go
> > > wrong if the linker never emitted any of these tags?
> 
> > The reason I added the support is Ulrich wanted DF_1_NODELETE for
> > libpthread.so.
> ...
> 
> So shouldn't we only use the new tags if the user specifies -z
> nodelete (or whatever it is)?

Yes, that is how it works. The new dtags will be generated only
by either -z xxxxx or --enable-new-dtags.


H.J.

Re: glibc 2.1 and gabi

[Mark Kettenis]

   Date: Thu, 20 Jul 2000 23:22:18 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Thu, Jul 20, 2000 at 11:21:12PM -0700, Geoff Keating wrote:
   > > Date: Thu, 20 Jul 2000 21:14:54 -0700
   > > From: "H . J . Lu" <hjl@lucon.org>
   > 
   > > On Thu, Jul 20, 2000 at 08:27:31PM -0700, Geoff Keating wrote:
   > > > I know I _can_ use it, but when do I _have_ to use it?  What would go
   > > > wrong if the linker never emitted any of these tags?
   > 
   > > The reason I added the support is Ulrich wanted DF_1_NODELETE for
   > > libpthread.so.
   > ...
   > 
   > So shouldn't we only use the new tags if the user specifies -z
   > nodelete (or whatever it is)?

   Yes, that is how it works. The new dtags will be generated only
   by either -z xxxxx or --enable-new-dtags.

Q: But why do you need --enable-new-dtags at all?

A: Because HJ sneaked in some patches that do more than just setting a
flag such as DF_1_NODELETE as a response for the user specifying a -z
nodelete.


2000-07-19  H.J. Lu  <hjl@gnu.org>

        * elf32-arm.h (elf32_arm_size_dynamic_sections): Also set
        DF_TEXTREL if DT_TEXTREL is set.
        * bfd/elflink.h (NAME(bfd_elf,size_dynamic_sections)): Also
        set DF_SYMBOLIC for symbolic link. Also set DT_RUNPATH if
        DT_RPATH is set.
        Set the DT_FLAGS and DT_FLAGS_1 entries if necessary.

Especially the DT_RUNPATH change is important.  This means that where
previously -rpath did only set DT_RPATH, it now also sets DT_RUNPATH.
As I understand it DT_RUNPATH is supposed to replace DT_RPATH in the
new ELF specs, but with slightly different semantics (at least on some
platfroms).  This makes me wonder whether setting both is really such
an idea.  I think that changes such as these deserve some deserve some
more discussion on the binutils list before they are made.  HJ, could
you please try to cooperate a bit more and give other people who
depend on the ELF linker a chance to comment on this kind of changes?

Mark

Re: glibc 2.1 and gabi

[H . J . Lu]

On Fri, Jul 21, 2000 at 09:18:57AM +0200, Mark Kettenis wrote:
> 
> Especially the DT_RUNPATH change is important.  This means that where
> previously -rpath did only set DT_RPATH, it now also sets DT_RUNPATH.
> As I understand it DT_RUNPATH is supposed to replace DT_RPATH in the
> new ELF specs, but with slightly different semantics (at least on some
> platfroms).  This makes me wonder whether setting both is really such

I don't think it should do any harm. You only enable it with
--enanle-new-dtags. The ld.so should check DT_RUNPATH first and
then DT_RPATH. It will skip DT_RPATH if DT_RUNPATH is found. If it
doesn't know DT_RUNPATH at all, it should just ignore it.

> an idea.  I think that changes such as these deserve some deserve some
> more discussion on the binutils list before they are made.  HJ, could

That is in the new gABI. We should fix ld.so if it is broken. Of
course, we can express our concerns to the gABI people.

> you please try to cooperate a bit more and give other people who
> depend on the ELF linker a chance to comment on this kind of changes?

I am listening. It is not casted in stone. We can make changes if
warranted.


H.J.

Re: glibc 2.1 and gabi

[H . J . Lu]

On Fri, Jul 21, 2000 at 09:01:25AM -0700, H . J . Lu wrote:
> > previously -rpath did only set DT_RPATH, it now also sets DT_RUNPATH.
> > As I understand it DT_RUNPATH is supposed to replace DT_RPATH in the
> > new ELF specs, but with slightly different semantics (at least on some
> > platfroms).  This makes me wonder whether setting both is really such
> 
> I don't think it should do any harm. You only enable it with
> --enanle-new-dtags. The ld.so should check DT_RUNPATH first and
> then DT_RPATH. It will skip DT_RPATH if DT_RUNPATH is found. If it
> doesn't know DT_RUNPATH at all, it should just ignore it.
> 

FYI, from the new gABI:

-----
A fourth search facility, the dynamic array tag DT_RPATH, has been
moved to level 2 in the ABI. It provides a colon-separated list of
directories to search. Directories specified by DT_RPATH are searched
before directories specified by LD_LIBRARY_PATH. 

If both DT_RPATH and DT_RUNPATH entries appear in a single object's
dynamic array, the dynamic linker processes only the DT_RUNPATH entry. 
----


H.J.