Compiler-generated implicit symbols and --gc-sections

[Mike]

On Monday, 6 January 2014 at 18:59:00 UTC, Iain Buclaw wrote:
> On 6 Jan 2014 13:45, "Dicebot" <public at dicebot.lv> wrote:
>>
>> On Friday, 3 January 2014 at 18:14:58 UTC, Mike wrote:
>>>
>>> I eventually tracked it down to the fact that I was compiling 
>>> with
> -ffunction-sections and -fdata-sections and linking with 
> --gc-sections and
> symbols like...
>>
>>
>> I never got --gc-sections to work reliably with D without 
>> going dirty,
> crashes were somewhat common for any non-trivial program. Don't 
> think this
> particular use case is tested by anyone at all, you are on your 
> own once
> you get here.
>
> Of course ! --gc-sections is just a dirty hack.  If you want 
> smaller
> binaries, then you are better off aiding the shared library 
> support. :)
>
> I don't ever recall any of the core maintainers ever endorsing 
> that switch
> anyway....

I agree that the --gc-sections method is hackish, but I wouldn't 
say it's dirty.  And, in absence of a better method, it is 
*essential* in the embedded world, and was likely added 
specifically to make the GNU toolchain a feasible alternative for 
the embedded market.  I doubt the Arduino, with its 32KB of flash 
memory, would have even been created without it.

The STM32 processors that I use have 16 ~ 1024KB of flash on 
them, and --gc-sections is essential to get some programs to fit. 
  Furthermore, it saves my employer 10s of thousands of dollars in 
hardware costs for mass produced devices.  With --gc-sections, 
these devices can be built with C/C++, libsup++, newlib, and 
libc++ quite effectively.  Without it, this would be impossible.

Shared library support just doesn't apply in this world.  Most of 
the devices I build are single-threaded, and much of code in the 
libraries is just never called, and hacking the library's source 
code with #defines to strip out stuff is a non-solution.

I'm interested in knowing why --gc-sections works well for C/C++ 
programs but not D, and I hope the compilers will eventually emit 
code that can support it.
It would be sad if D fragmented into D and embedded-D.  I don't 
think that would serve the D language well.

I'm liking D so far, and I'm very interested in seeing D become 
an alternative for the embedded world.  I'm willing to help in 
any way I can.