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" <pub...@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.
