Compiler-generated implicit symbols and --gc-sections

[Joakim]

On Tuesday, 7 January 2014 at 02:17:46 UTC, Mike wrote:
> 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.

I ran into this recently when compiling for Android/x86, as the 
Android NDK linker calls --gc-sections by default.  I was able to 
reproduce the segfault with dmd compiling a linux/x86 executable 
with the --gc-sections flag added to the linker command, when 
compiling sieve.d from the samples.  I think sieve.d was working 
fine when I removed the recent patches for shared library support 
on linux, in sections_linux.d, so this incompatibility might be 
related to the shared library work.  I'm not sure if you're even 
using that work though, so maybe that's just one of the ways that 
gc-sections trips up.