Boost logo

Boost :

Subject: Re: [boost] [Boost.DLL] Formal Review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-10-07 13:31:52

On 7 Oct 2014 at 16:58, Antony Polukhin wrote:

> > <...>
> > Prints:
> >
> > 18$$magic$$_fprinterILZN21$$magic$$_adl_barrier18export_me_functionE7v
> > ariantIis5void_S2_S2_ES3_EE
> > 18$$magic$$_vprinterILZN21$$magic$$_adl_barrier18export_me_variableEEE
> >
> > Exported:
> >
> > __ZN3foo11adl_barrier18export_me_functionE7variantIis5void_S2_S2_ES3_
> > __ZN3foo11adl_barrier18export_me_variableE
> >
> > ... which looks bang on. Simply replace the 8fprinter with 3foo and
> > remove the $$magic$$_.
> >
> Still looks like something error-prone.

Not for the Itanium ABI which is very well understood and publicly
documented. You can write a simple [1] Itanium type mangler using
pure C++ metaprogramming, it's trivial in fact.

The MSVC ABI is considerably harder. This is why I am advocating
getting the compiler to do the mangling for you, then you transform
its result according to some simple heuristics.

[1]: By simple I mean only types with no repetition compression.

> Actually, user could always get the list of mangled symbols using the
> boost::dll::library_info class methods on a compiled binary. So instead of
> using mangling voodoo macro and explicitly declaring exports in import
> module, user can find all the export_me_* mangled names and import them
> using any of the interfaces. Something close can be found in this example:

Oh sure. But I think what we'd all love is for some long overdue type
safety when binding symbols at runtime in C++. Otherwise out of step
binaries make segfaults, security holes and buffer overruns instead
of link failures.

> ... some dream of a nicest solution:
> Add attribute [[abi_name "new_abi_name"]], remove all the *_alias methods
> and member function, remove _ALIAS macro. Now user is free to do following
> things:
> // in plugin:
> namespace foo {
> namespace adl_barrier {
> [[abi_name "export_me_function_1"]]
> BOOST_SYMBOL_EXPORT boost::variant<int, short> export_me_function(
> boost::variant<int, short>, boost::variant<int, short>)
> {
> return 0;
> }
> [[abi_name "export_me_variable_1"]]
> BOOST_SYMBOL_EXPORT boost::variant<int, short> export_me_variable;
> } // namespace adl_barrier
> }
> // in importer:
> dll::shared_library lib(lib_path);
> typedef boost::variant<int, short> vis_t;
> auto f = lib.get<vis_t(vis_t, vis_t)>("export_me_function_1");
> auto v = lib.get<vis_t>("export_me_variable_1");
> Code from above looks nice, but requires abi_name attribute that was not
> even proposed to C++ standardization and until now existed only in my head.

Personally speaking, if a proper Componentisation ABI is considered
still too hard for us, I'd simply standardise on the Itanium ABI.

Your DLL library could provide a portable method for auto generating
aliases with the Itanium ABI. As I mentioned, it is fairly trivial to
write some metaprogramming which will output an Itanium mangling for
some input type. You just then need to regex in the fully qualified
name of the item, and finally run a pass collapsing repetition (a
regex matcher will suffiice). Itanium is very logical, no surprises.
I keep a quick cheat sheet document on symbol mangling at
alling_conventions.pdf, you may find it useful. The official isn't bad


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at