This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: (hppa-linux) simple testcase for binutils visibility problem
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Randolph Chung <randolph at tausq dot org>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 13 Nov 2002 06:50:00 -0500 (EST)
- Subject: 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