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]
Other format: [Raw text]

Re: (hppa-linux) simple testcase for binutils visibility problem


On Tue, 12 Nov 2002, Randolph Chung wrote:
> > > Alan, pardon the naive question, but why is it a 'reasonable' thing to
> > > do? it seems to me that you should be able to declare the visibility of
> > > an undefined symbol in one object, and link it with the definition of
> > > the symbol in another and have the visibility information 'merged' when
> > > the objects are linked together.
> >
> > Which is in fact what gcc-3.2.x does and gcc-3.3 will do.  See
> > gcc/mklibgcc.in, search for .hidden.
>
> errr....
>
> i think you are talking about something different (or I'm just very
> confused) :-)

Possibly the latter.  Or maybe I am.  Maybe I have no ideas what
I'm talking about. ;-)  Maybe you think I said you're wrong; I
didn't.

> on hppa, if you have a non-local .hidden (or protected, etc) symbol, the
> assembler will silently throw the symbol away. this is a bug isn't it?

Yes.

> it has nothing to do with gcc-3.2 vs 3.3 or whatever.

Yes it does, because gcc-3.2 depends on the symbol being kept;
it assembles a file containing just e.g.
 .hidden _Unwind_Resume
then "ld -r":ing it with the object defining that symbol.  The
same construct is in gcc-3.3 CVS but I'm not sure it's depended
on there.  (It seems so.)

> As Alan pointed out, tc-hppa.h defines tc_frob_symbol to discard all
> non-referenced local symbols (which is quite different from the other
> architectures i've tested). But Alan went on to say "but it seems a
> reasonable thing to do." I'm not sure what that means...

Because it's not used (in a reloc or whatever) or defined, it
may seem reasonable.

> does that mean:
> 3) fix it some other way?

In tc_frob_symbol, look at the symbol visibility and throw it
only if it's unused *and* has default visibility.  Perhaps.

You didn't look at gcc/mklibgcc.in, right? ;-)

brgds, H-P


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