Re: [Boost-users] [serialization] boost::serialization adds huge amounts of exports to resultant Windows PE file

Subject: Re: [Boost-users] [serialization] boost::serialization adds huge amounts of exports to resultant Windows PE file
From: Marsh Ray (marsh_at_[hidden])
Date: 2010-10-04 10:58:28

On 10/03/2010 01:09 AM, Robert Ramey wrote:
> Marsh Ray wrote:
>> On 10/02/2010 12:56 AM, Lars Viklund wrote:
>>> On Wed, Sep 29, 2010 at 06:48:55PM -0800, Robert Ramey wrote:
>>>> Chris Yuen wrote:
>>>>> Hey guys,
>>>>>
>>>>> I am using boost::serialization from 1.44.0. One thing that I
>>>>> noticed is that linking statically to the serialization libs will
>>>>> add several hundred exports in the final exe file that I get.
>>>>> Using `dumpbin /exports my_program.exe`
>>>>
>>>> These functions are not explicity called from the library.
>>>> But they ARE called as part of the serialization process.  Its
>>>> just that MSVC doesn't see them.  So when you compile
>>>> for release, The MSVC Linker strips them out and the
>>>> program won't work anymore.   In order to work around
>>>> this, these functions are explicitly exported.  This prevents
>>>> MSVC from stripping them out.  For more information
>>>> see force_include.hpp
>>
>> The problem with exporting is that it adds a semantic meaning which is
>> unwanted.
>
> I'm not seeing this.

Adding an entry to the export table says "separately linked code can 
call me via this exported name/ordinal". I don't think this is the 
meaning that was intended.

>> I think the /include linker option is supposed to do what you want:
>>
>> http://msdn.microsoft.com/en-US/library/2s3hwbhs%28v=VS.80%29.aspx
>> "Specifying a symbol with this option overrides the removal of that
>> symbol by /OPT:REF."
>>
>> You can even specify it in the source:
>>
>>      #pragma comment(linker, "/include:__mySymbol")
>>
>> http://msdn.microsoft.com/en-us/library/7f0aews7%28VS.80%29.aspx
>
> I don't see how one could pass a symbol generated by template to to
> a linker switch or to a pragma.

Yeah good point.

Perhaps template instantiation could generate a reference to the symbol 
from within some other object that does have a fixed name? I'm sure I've 
seen this done somewhere but don't recall exactly how.

Maybe something involving the template generating a static data member 
with a constructor that passes the object's address to some function the 
linker cannot eliminate, and there had to be at least one function 
actually called in that translation unit in order to prevent the linker 
from throwing it out entirely.

Not saying it's necessarily a great solution, but...

>>> These exported symbols are excellent for provoking bugs in software
>>> that makes assumptions about the maximum reasonable length a symbol
>>> should be able to have.
>
> I'm no seeing this either. I don't see how that this symbol information
> is accessible.  Even if it is, I don't see how it could be used.

It goes into the the PE32 "export table", usually by name. IIRC, the 
export table points to NUL-terminated strings with a length limitation 
in some obscure document somewhere. These export table names are visible 
without debug symbols and are to be compared case insensitively.

> Someone else has reported that msvc no longer strips these symbols
> but has been unable to test this.  I don't see how it's possible for
> the compiler/linker to know which unreferred to symbols can be
> stripped and which cannot be.

Generally, unless it's exported, or called or address taken by something 
which is not removed, then it will be removed by /OPT:REF.

> GCC has some attributes which
> one can attach to flag function which shouldn't be stripped so it's not
> a problem there.  The IBM compiler recently added attributes handle
> this as well.

That sounds like a better design for C++ than the linker option.

- Marsh