Compiling glibc-2.3.2 (-2.3.3?) snapshot 20031115 with gcc-3.4 snapshot 20031119
Daniel Jacobowitz
drow@mvista.com
Tue Dec 2 20:21:00 GMT 2003
On Tue, Dec 02, 2003 at 12:15:13PM -0800, Matt Austern wrote:
> On Dec 2, 2003, at 7:37 AM, Jakub Jelinek wrote:
>
> >On Tue, Dec 02, 2003 at 09:35:51AM -0800, Matt Austern wrote:
> >>As you might have noticed from following the discussion on the
> >>gcc list, the main reason I haven't fixed this yet is that we haven't
> >>yet reached an agreement about what the semantics of the
> >>visibility attribute should be when you've got multiple declarations
> >>of the same symbol.
> >>
> >>What assumptions does the glibc source make about this, and how
> >>tightly wedded are you to those assumptions?
> >
> >glibc assumes that if there is a decl without visibility attribute
> >and decl with visibility attribute, that the visibility specified
> >in the visibility attribute is used.
> >
> >Say:
> >int foo (void) __attribute__((visibility ("hidden")));
> >int bar (void);
> >...
> >int foo (void) { return 1; }
> >int __attribute__((visibility ("hidden"))) bar (void) { return 2; }
> >
> >then both foo and bar are hidden.
>
> OK! The next question, then: do you assume that explicitly
> providing a default visibility, and not providing a visibility at
> all, are different? That is, would you expect
> int foo (void) __attribute__((visibility ("hidden")));
> int foo (void) __attribute__((visibility ("default"))) { return 137;
> }
> to behave differently than
> int foo (void) __attribute__((visibility ("hidden")));
> int foo (void) { return 137; }?
>
> (I hope the answer is no, and that default is just default. I know
> how to make the compiler treat the two kinds of default differently,
> but it'll be a little more expensive and convoluted.)
But... wouldn't this be necessary if there was a switch to change the
"default" visibility of compiler-generated symbols? Something which
has been both requested and proposed in the past.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
More information about the Gcc
mailing list