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

[Randolph Chung <randolph at tausq dot org>]

> > 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) :-)

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?
it has nothing to do with gcc-3.2 vs 3.3 or whatever.

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...

does that mean:
1) the current code is correct?

2) we should remove the check against bfd_und_section in the following 
code:

#define tc_frob_symbol(sym,punt) \
  { \
    if ((S_GET_SEGMENT (sym) == &bfd_und_section && ! symbol_used_p (sym)) \
        || (S_GET_SEGMENT (sym) == &bfd_abs_section \
            && ! S_IS_EXTERNAL (sym)) \
        || strcmp (S_GET_NAME (sym), "$global$") == 0 \
        || strcmp (S_GET_NAME (sym), "$PIC_pcrel$0") == 0) \
      punt = 1; \
  }

3) fix it some other way?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/