(hppa-linux) simple testcase for binutils visibility problem
Hans-Peter Nilsson
hp@bitrange.com
Wed Nov 13 03:50:00 GMT 2002
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
More information about the Binutils
mailing list