Re: [boost] [Boost.DLL] Formal Review request

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:
> http://apolukhin.github.io/Boost.DLL/boost_dll/tutorial.html#boost_dll.tutorial.querying_libraries_for_symbols

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 
https://github.com/ned14/NiallsCPP11Utilities/blob/master/demanglers/c
alling_conventions.pdf, you may find it useful. The official  
http://mentorembedded.github.io/cxx-abi/abi.html#mangling isn't bad 
either.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/