Libstdc++ as DLL on windows, alternative approach [was Re: cygwin patch review]

[Dave Korn]

Dave Korn wrote:
> Benjamin Kosnik wrote:
>> From older mail thread:

>> No. There is already visibility markup on libstdc++ headers for this.
>> You can just put the attribute visibility bits on namespace std, and be
>> done with it.
>>
>> Here, from include/bits/c++config.h:
>>
>> # define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X
>> _GLIBCXX_VISIBILITY_ATTR(default)
> 
>   Ok, so as we discussed before, this doesn't currently work.  However it does
> sound like the right thing to do, so I've spun a new version of the patch that
> applies dllimport to the namespace.  We could commit this and then open a PR
> about dllimport not working on namespaces.  It's much smaller and cleaner than
> the version that adds markup everywhere, but I doubt I'll be able to fix the
> dllimport-vs-namespace bug in time for 4.5.  That's not the end of the world;
> getting dllimport right is a good optimisation, but we can live with the
> compromise of auto-import for now.


  I've done a little bit of scoping out what it would take to enable
dllimport/dllexport attributes on namespaces, and I think it looks roughly
something like the attached crude (contains debug printf and commented-out
bits) WIP patch.

  There are some small tweaks to the C++ parser and core attribute handler to
allow the attributes to be attached to namespace_decl nodes (probably more
than needed in fact, I think rather than passing in a tree* pointer to
handle_namespace_attrs in cp/name-lookup.c I just want to gcc_assert that
cplus_decl_attributes doesn't return a changed pointer; it shouldn't anyway,
it's only meant to do so for types, not decls), and then in the backend we
process class definitions and other decls using the adjust_class_at_definition
and encode_section_info flags, walking our way up the namespace/class context
hierarchy and looking for the attributes.

  I'm going to put this through bootstrap and test, and then do some more
manual testing.  I'm not sure whether it handles everything correctly w.r.t.
templates and odd corner cases of nested contexts and would be glad of any
guidance anyone can offer about the algorithm for walking up out of the nested
scopes looking for dll{im,ex}port attributes.

  Another open question is whether for the sake of this usage (tagging dll
attributes on namespaces) it wouldn't make sense to add nodllimport and
nodllexport tags, which would serve to block off portions of the hierarchy
(i.e. if the scope tree climb ascends past a node tagged with one of these
first, it stops early).  This would go in the places where ELF platforms use
hidden visibility attributes.

  Anyway, FYI and FTR, this is what I'm trying at the moment.  Doesn't look
like there's anything we could do solely in the backend to try and make it
suitable for stage 3, which I had kinda hoped, but the attributes just get
discarded in the parser without the core compiler mods; shame.

    cheers,
      DaveK


-------------- next part --------------
A non-text attachment was scrubbed...
Name: dllimport-namespace-wip.diff
Type: text/x-c
Size: 11729 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20091119/091b3707/attachment.bin>