* Re: glibc 2.1 and gabi
@ 2000-07-20 14:12 Nick Clifton
2000-07-20 15:00 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Nick Clifton @ 2000-07-20 14:12 UTC (permalink / raw)
To: hjl; +Cc: binutils, ian
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 14:12 glibc 2.1 and gabi Nick Clifton
@ 2000-07-20 15:00 ` H . J . Lu
0 siblings, 0 replies; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 15:00 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils, ian
On Thu, Jul 20, 2000 at 02:12:04PM -0700, Nick Clifton wrote:
>
> Approved.
>
> Cheers
> Nick
Done.
H.J.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
@ 2000-07-24 10:52 Nick Clifton
0 siblings, 0 replies; 25+ messages in thread
From: Nick Clifton @ 2000-07-24 10:52 UTC (permalink / raw)
To: hjl; +Cc: ac131313, binutils
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-23 20:18 ` Andrew Cagney
@ 2000-07-23 21:01 ` H . J . Lu
0 siblings, 0 replies; 25+ messages in thread
From: H . J . Lu @ 2000-07-23 21:01 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Nick Clifton, binutils
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 12:41 ` H . J . Lu
@ 2000-07-23 20:18 ` Andrew Cagney
2000-07-23 21:01 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Andrew Cagney @ 2000-07-23 20:18 UTC (permalink / raw)
To: H . J . Lu; +Cc: Nick Clifton, binutils
"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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-21 9:01 ` H . J . Lu
@ 2000-07-21 9:07 ` H . J . Lu
0 siblings, 0 replies; 25+ messages in thread
From: H . J . Lu @ 2000-07-21 9:07 UTC (permalink / raw)
To: Mark Kettenis; +Cc: geoffk, libc-hacker, binutils, ian
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-21 0:19 ` Mark Kettenis
@ 2000-07-21 9:01 ` H . J . Lu
2000-07-21 9:07 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: H . J . Lu @ 2000-07-21 9:01 UTC (permalink / raw)
To: Mark Kettenis; +Cc: geoffk, libc-hacker, binutils, ian
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 23:22 ` H . J . Lu
@ 2000-07-21 0:19 ` Mark Kettenis
2000-07-21 9:01 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Mark Kettenis @ 2000-07-21 0:19 UTC (permalink / raw)
To: hjl; +Cc: geoffk, libc-hacker, binutils, ian
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 23:13 ` Geoff Keating
@ 2000-07-20 23:22 ` H . J . Lu
2000-07-21 0:19 ` Mark Kettenis
0 siblings, 1 reply; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 23:22 UTC (permalink / raw)
To: Geoff Keating; +Cc: libc-hacker, binutils, ian
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 21:15 ` H . J . Lu
@ 2000-07-20 23:13 ` Geoff Keating
2000-07-20 23:22 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Geoff Keating @ 2000-07-20 23:13 UTC (permalink / raw)
To: hjl; +Cc: libc-hacker, binutils, ian
> 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>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 20:28 ` Geoff Keating
@ 2000-07-20 21:15 ` H . J . Lu
2000-07-20 23:13 ` Geoff Keating
0 siblings, 1 reply; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 21:15 UTC (permalink / raw)
To: Geoff Keating; +Cc: libc-hacker, binutils, ian
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 17:10 ` H . J . Lu
@ 2000-07-20 20:28 ` Geoff Keating
2000-07-20 21:15 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Geoff Keating @ 2000-07-20 20:28 UTC (permalink / raw)
To: hjl; +Cc: libc-hacker, binutils, ian
> 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>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 16:12 ` Geoff Keating
@ 2000-07-20 17:10 ` H . J . Lu
2000-07-20 20:28 ` Geoff Keating
0 siblings, 1 reply; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 17:10 UTC (permalink / raw)
To: Geoff Keating; +Cc: libc-hacker, binutils, ian
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 15:52 ` H . J . Lu
@ 2000-07-20 16:12 ` Geoff Keating
2000-07-20 17:10 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Geoff Keating @ 2000-07-20 16:12 UTC (permalink / raw)
To: hjl; +Cc: libc-hacker, binutils, ian
> 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>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 15:47 ` Geoff Keating
@ 2000-07-20 15:52 ` H . J . Lu
2000-07-20 16:12 ` Geoff Keating
0 siblings, 1 reply; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 15:52 UTC (permalink / raw)
To: Geoff Keating; +Cc: libc-hacker, binutils, ian
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 13:57 ` H . J . Lu
@ 2000-07-20 15:47 ` Geoff Keating
2000-07-20 15:52 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Geoff Keating @ 2000-07-20 15:47 UTC (permalink / raw)
To: hjl; +Cc: libc-hacker, binutils, ian, nick
> 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>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 13:23 ` Geoff Keating
@ 2000-07-20 13:57 ` H . J . Lu
2000-07-20 15:47 ` Geoff Keating
0 siblings, 1 reply; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 13:57 UTC (permalink / raw)
To: Geoff Keating; +Cc: libc-hacker, binutils, ian, nick
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 13:17 Nick Clifton
@ 2000-07-20 13:55 ` H . J . Lu
0 siblings, 0 replies; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 13:55 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils, ian
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"));
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 11:42 H . J . Lu
@ 2000-07-20 13:23 ` Geoff Keating
2000-07-20 13:57 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Geoff Keating @ 2000-07-20 13:23 UTC (permalink / raw)
To: hjl; +Cc: libc-hacker, binutils, ian, nick
> 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>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
@ 2000-07-20 13:17 Nick Clifton
2000-07-20 13:55 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Nick Clifton @ 2000-07-20 13:17 UTC (permalink / raw)
To: hjl; +Cc: binutils, ian
Hi H.J.
: How about just
:
: --disable-new-dynamic-tags
: --enable-new-dynamic-tags
Sure :-)
Cheers
Nick
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 12:26 Nick Clifton
@ 2000-07-20 12:41 ` H . J . Lu
2000-07-23 20:18 ` Andrew Cagney
0 siblings, 1 reply; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 12:41 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils, ian
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
@ 2000-07-20 12:26 Nick Clifton
2000-07-20 12:41 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Nick Clifton @ 2000-07-20 12:26 UTC (permalink / raw)
To: hjl; +Cc: binutils, ian
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
2000-07-20 12:06 Nick Clifton
@ 2000-07-20 12:12 ` H . J . Lu
0 siblings, 0 replies; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 12:12 UTC (permalink / raw)
To: Nick Clifton; +Cc: libc-hacker, binutils, ian, nick
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: glibc 2.1 and gabi
@ 2000-07-20 12:06 Nick Clifton
2000-07-20 12:12 ` H . J . Lu
0 siblings, 1 reply; 25+ messages in thread
From: Nick Clifton @ 2000-07-20 12:06 UTC (permalink / raw)
To: hjl; +Cc: libc-hacker, binutils, ian, nick
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* glibc 2.1 and gabi
@ 2000-07-20 11:42 H . J . Lu
2000-07-20 13:23 ` Geoff Keating
0 siblings, 1 reply; 25+ messages in thread
From: H . J . Lu @ 2000-07-20 11:42 UTC (permalink / raw)
To: GNU C Library, binutils, Ian Lance Taylor, nick
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2000-07-24 10:52 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-20 14:12 glibc 2.1 and gabi Nick Clifton
2000-07-20 15:00 ` H . J . Lu
-- strict thread matches above, loose matches on Subject: below --
2000-07-24 10:52 Nick Clifton
2000-07-20 13:17 Nick Clifton
2000-07-20 13:55 ` H . J . Lu
2000-07-20 12:26 Nick Clifton
2000-07-20 12:41 ` H . J . Lu
2000-07-23 20:18 ` Andrew Cagney
2000-07-23 21:01 ` H . J . Lu
2000-07-20 12:06 Nick Clifton
2000-07-20 12:12 ` H . J . Lu
2000-07-20 11:42 H . J . Lu
2000-07-20 13:23 ` Geoff Keating
2000-07-20 13:57 ` H . J . Lu
2000-07-20 15:47 ` Geoff Keating
2000-07-20 15:52 ` H . J . Lu
2000-07-20 16:12 ` Geoff Keating
2000-07-20 17:10 ` H . J . Lu
2000-07-20 20:28 ` Geoff Keating
2000-07-20 21:15 ` H . J . Lu
2000-07-20 23:13 ` Geoff Keating
2000-07-20 23:22 ` H . J . Lu
2000-07-21 0:19 ` Mark Kettenis
2000-07-21 9:01 ` H . J . Lu
2000-07-21 9:07 ` H . J . Lu
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).