DT_SYMBOLIC and -Bsymbolic

DT_SYMBOLIC and -Bsymbolic

[H.J. Lu]

Hi,

Do the current binutils snapshots and the Linux ELF dynamic
linker support DT_SYMBOLIC? It should be easy to add -Bsymbolic
to ld. The Linux ELF dynamic linker just needs to check the
presence of DT_SYMBOLIC in the shared library to control the
symbol binding. It is specified in the ELF doc, ELF.doc.tar.gz,
on tsx-11 and sunsite in the linux gcc directory


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: DT_SYMBOLIC and -Bsymbolic

[Eric Youngdale]

On Jun 19,  9:58am, H.J. Lu wrote:
> Subject: DT_SYMBOLIC and -Bsymbolic
> Hi,
>
> Do the current binutils snapshots and the Linux ELF dynamic
> linker support DT_SYMBOLIC? It should be easy to add -Bsymbolic
> to ld. The Linux ELF dynamic linker just needs to check the
> presence of DT_SYMBOLIC in the shared library to control the
> symbol binding. It is specified in the ELF doc, ELF.doc.tar.gz,
> on tsx-11 and sunsite in the linux gcc directory

	I doubt that this is handled at all - I never added support for it,
so unless Ian did it, there is probably nothing.  The good news is that it
would not be that hard to add.

-Eric


-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: DT_SYMBOLIC and -Bsymbolic

[H.J. Lu]

> 
> On Jun 19,  9:58am, H.J. Lu wrote:
> > Subject: DT_SYMBOLIC and -Bsymbolic
> > Hi,
> >
> > Do the current binutils snapshots and the Linux ELF dynamic
> > linker support DT_SYMBOLIC? It should be easy to add -Bsymbolic
> > to ld. The Linux ELF dynamic linker just needs to check the
> > presence of DT_SYMBOLIC in the shared library to control the
> > symbol binding. It is specified in the ELF doc, ELF.doc.tar.gz,
> > on tsx-11 and sunsite in the linux gcc directory
> 
> 	I doubt that this is handled at all - I never added support for it,
> so unless Ian did it, there is probably nothing.  The good news is that it
> would not be that hard to add.

That is what I thought. While I am on it, let me ask one more
question :-(. Is DT_TEXTREL supported? Or should it be?


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: DT_SYMBOLIC and -Bsymbolic

[Eric Youngdale]

On Jun 19, 10:58am, H.J. Lu wrote:
> That is what I thought. While I am on it, let me ask one more
> question :-(. Is DT_TEXTREL supported? Or should it be?


	Yes.  This one should only occur if you attempt to create
a shared library from non-PIC code, as the .text section will then
need to have relocations applied.  The DT_TEXTREL tells the dynamic
loader that it needs to mprotect the .text section to make it writable
before applying relocations, and once we are through, we need to set
them back again.

	The dynamic loader should be doing this correctly -
someone did accidentally make a shared library from non-PIC code
as I recall.  They were complaining that dynamic linking was broken
(not surprising), but it worked otherwise, which would tend to suggest
that the linker is inserting DT_TEXTREL and the dynamic loader is
doing the right thing with it.

	I am trying to grab the latest binutils sources -  I will take
a look at DT_SYMBOLIC.

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: DT_SYMBOLIC and -Bsymbolic

[Eric Youngdale]

On Jun 19, 10:58am, H.J. Lu wrote:
> Subject: Re: DT_SYMBOLIC and -Bsymbolic
> >
> > On Jun 19,  9:58am, H.J. Lu wrote:
> > > Subject: DT_SYMBOLIC and -Bsymbolic
> > > Hi,
> > >
> > > Do the current binutils snapshots and the Linux ELF dynamic
> > > linker support DT_SYMBOLIC? It should be easy to add -Bsymbolic
> > > to ld. The Linux ELF dynamic linker just needs to check the
> > > presence of DT_SYMBOLIC in the shared library to control the
> > > symbol binding. It is specified in the ELF doc, ELF.doc.tar.gz,
> > > on tsx-11 and sunsite in the linux gcc directory

	OK, I have patches to add this.  I basically assumed that all
that we needed to do was to translate -Bsymbolic on the link line into
DT_SYBMOLIC in the .dynamic section, and nothing more than that.  I tested
it with a small example, and it seemed to work.

-Eric




-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: DT_SYMBOLIC and -Bsymbolic

[Eric Youngdale]

	Hmm, I was looking at the man page for Solaris - my implementation
of
-Bsymbolic does not quite match what they suggest.  I was thinking that this
would be something that we could implement at runtime through patches to the
dynamic loader, but my guess is that we need to modify the real linker
behavior for this to work correctly.

-Eric


-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: DT_SYMBOLIC and -Bsymbolic

[H.J. Lu]

> 
> 
> 	Hmm, I was looking at the man page for Solaris - my implementation
> of
> -Bsymbolic does not quite match what they suggest.  I was thinking that this
> 

I think your change to ld is in the right directory. We just need
to make ld issue some warnings for unresolved references when
-Bsymbolic is used. Your change just works as under Solaris when
the messages are turned off.

> would be something that we could implement at runtime through patches to the
> dynamic loader, but my guess is that we need to modify the real linker
> behavior for this to work correctly.
> 

We do need to patch the dynamic linker to support DT_SYMBOLIC.


H.J.

Re: DT_SYMBOLIC and -Bsymbolic

[Eric Youngdale]

	OK, I think the enclosed patch is more along the lines of what is
required.  The general idea is that we bypass the PLT when -Bsymbolic is
in effect, and in addition the GOT slots have a different type of relocation
(R_*_RELATIVE instead of R_*_GLOB_DAT).  I updated both the Sparc and i386
backends (others would be easy, if other backends supported shared libs).

	From what I can tell the advantages of using this are that you
get slightly better performance at runtime since you do not go through the
PLT for every function call.  In addition, there is less startup overhead
since there are no PLT slots to be initialized.  The GOT slots still exist,
but the R_*_RELOCATION relocations do not have a symbol, so you do not
have to search any of the symbol tables to perform these relocations, and
there would be yet another very slight performance increase.

	The Solaris linker does put a DT_SYMBOLIC entry in the .dynamic
section, but I am not sure what it is used for.  It is possible that it
would be used in cases where you attempt to link non-PIC code into a
shared library, since you would still be emitting relocations to the
output file in this case.  Thus patches to the dynamic loader should still
be required.

	The drawbacks to using this flag are that the library is less
sharable.  In other words, the user cannot redefine functions in the
library and expect that their redefinition will work for calls to the
function from within the library.

	I vaguely recall a few months ago seeing a discussion between some
of the members of the ABI+ committee (who are charged with updating the
SVr4 ABI, and merging differences between Solaris and Unixware).  Apparently
some (but not all) SVr4 vendors are using -Bsymbolic with libc - apparently
for performance reasons.

	FWIW, I would recommend against ever using this switch except in
certain specific cases - people need to know exactly what they are doing
when they turn this one on, and they need to know the ramifications.

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."