This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/15000] Support setting the default symbol visibility for ELF
- From: "s_gccbugzilla at nedprod dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 5 May 2004 20:38:30 -0000
- Subject: [Bug other/15000] Support setting the default symbol visibility for ELF
- References: <20040418032536.15000.bryner@brianryner.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From s_gccbugzilla at nedprod dot com 2004-05-05 20:38 -------
> The old patch also works "inside outwards".
You're absolutely right. However I had hoped that because we get called at more
opportunities than the new patch I could find some method. However, at the end
of work last night I came to the realisation that the same method will be needed
by other, therefore the newer is to be preferred.
> One reason for that, I think, is that attributes can come at the end of a
> declaration, like this example from the documentation:
My reading of this actually is that GCC needs to know the sizeof() things before
it does much else. To know the size of a class requires parsing it from the most
nested class outwards. I don't think this can be changed.
> it would not be possible to know the outer class visibility when processing
> foo::bar.
Agreed.
> 1. Say that the visibility attribute can only be at the beginning of a
> class/struct declaration, and arrange to handle that attribute _before_ we
begin
> parsing class members. I don't think there is any existing mechanism for
> handling attributes at this stage, so we'd have to create something new.
>
> 2. Recursively reset DECL_VISIBILITY for members of inner classes once we
reach
> the end of a top-level class definition.
Out of these two, the second seems to me the less work and the least intrusive.
I tried the second last night, but there's a problem - the bit which parses and
applies the attributes lives in C land which of course knows nothing about C++
and so can't have the class stack available (which makes things much easier). I
tried an extern function, but I think they live in different binaries anyway so
no good.
This means the only realistic solution is for handle_visibility_attribute() to
see if it's being applied to a class/struct and if so, to traverse all children
nodes to see if they are class/struct and if and only if they haven't had a
visibility specified for them, overwrite that with the enclosing class
visibility. For this we'll need visibility_specified back in the decl structure
I think as I couldn't get C land to work with attributes in the TYPE_NAME(tree)
when within handle_visibility_attribute(). But then I am very much out of my
depth - I really am not sure of the mechanics underneath :(
BTW I have your pragma working fine, you can push and pop state from an internal
stack too. I'll make a patch based on your new one with everything except nested
class visibility setting and post it here, hopefully tonight.
Cheers,
Niall
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15000