Re: [PATCH,C,C++] Fix PR43601 massive object file size bloat. [was Re: dllexport and inline]

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 22/01/2011 03:05, Jason Merrill wrote:
> On 01/20/2011 11:39 PM, Dave Korn wrote:
>>> /* Test that inline functions declared "dllexport" appear in object
>>>     files, even if they are not called.
>>>
>>>     This behavior is required by the ARM C++ ABI:
>>>
>>>       Exporting a function that can be inlined should force the
>>>       creation and export of an out-of-line copy of it.
>>>
>>>     and should presumably also apply.
>>>
>>>     Visual Studio 2005 also honors that rule.  */
>>
>> .... but the implementation is I think overkill.  ABI compliance only
>> requires
>> the dllexported function to end up in the final linked DLL, it doesn't
>> necessarily require us to achieve that by the particular mechanism of
>> emitting
>> the function in every intermediate object file, and indeed VS avoids this
>> problem by emitting their inlines once only, in the pch file (effectively
>> they're in stdafx.obj).
> 
> But we don't have an object file for the PCH, so how else would you
> suggest we achieve the compatible result?

  It would need users to adjust their makefiles, I admit, but I think my
suggestion ought to work:

>> using -fno-keep-inline-dllexport during
>> most of the compilation and then compiling a single object file without it,
>> that #includes all the headers with inline dllexported functions, so that all
>> their definitions end up in a single object file.

  That should allow GNU toolchain users to make their builds work on the same
principle, unless I'm missing something.  (Plus, it has the benefit of still
working even when PCH aren't in use.)  It's just that MS have hidden the
details of the technique behind their implementation by having magic filenames
beginning "stdafx".

> Has this bug been reported to binutils?  

  I don't know if it really is a bug in binutils yet or not; we're feeding ld
about a gig of object code (most of which is redundant, yes) and it has only
about a gig and a half of unfragmented memory space to assemble it all in -
how much memory should it need for such a task?  That's why I would like to
accept that generating this much redundant object code is a weakness
(carefully chosen word there; not wrong or incorrect, just problematic in
practice) in the first place and deal accordingly.

> Is anyone looking at improving linker performance on this sort of code?

  Not yet, but I promise I will - although probably not until after 4.6 is out
the door.  I'm aware that we can probably make at least some difference to the
memory usage there, but I don't want to just blindly tell people that they
need to use --no-keep-memory; we ought to be able to compile wx on a 32-bit
system without special measures.

> The patch is OK as a temporary measure until the linker can be fixed.

  Thanks.  Will leave it about 24hrs or so in case anyone has anything further
to add (also, the Cygwin native bootstrap I promised has completed and tests
are now running without any regressions so far but this will give them time to
complete), and will also look at making the linker more industrial-grade if
possible.

    cheers,
      DaveK