This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Your patch on 2001-01-26 is bad


On Tue, Feb 06, 2001 at 09:26:24PM -0800, Richard Henderson wrote:
> On Tue, Feb 06, 2001 at 08:38:22PM -0800, H . J . Lu wrote:
> > STV_PROTECTED has the global visibility. It is the dynamic
> > linker which handles it.
> 
> I don't believe you.  If correct, this visibility level
> is completely pointless.
> 
> As I understand things:
> 
>   STV_HIDDEN:	Resolve locally, and not included in the
> 		dynamic symbol table.
> 
>   STV_INTERNAL:	Same.  Technically target dependant, but the
> 		interpretation I remember being suggested is
> 		that this is an assertion that the object is
> 		never seen even indirectly outside the dso.
> 
>   STV_PROTECTED: Resolved locally, but included in the
> 		dynamic symbol table.

From outside, STV_PROTECTED is just like STV_DEFAULT. STV_PROTECTED is
only meaningful inside DSO.

> 
> That we _know_ this will be resolved locally implies that
> we can optimize things at link time.  Why bother leaving

When you do local binding for STV_PROTECTED, will funcntion address
work right both inside and outside of DSO where it is defined?

> this for the loader?

The problem comes when you have an outside reference to a protected
symbol in a DSO. If you do

# grep STV_PROTECTED *.?

in bfd, you will only see

elf.c:    case STV_PROTECTED: fprintf (file, " .protected"); break;

That shows STV_PROTECTED is partially implemented somewhere else. BTW,
I implemented STV_PROTECTED in glibc.

I know it is a tricky problem. I believe I am right.

-- 
H.J. Lu (hjl@valinux.com)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]