On Tuesday, 8 July 2014 at 20:39:34 UTC, Walter Bright wrote:
This is all great news, congratulations!
Thanks. There was quite a bit of staring at obscure backtraces
and object file dumps involved. The most persistent issue was
what revealed itself to be a nasty race condition in
core.thread.Fiber due to the way GCC and LLVM implement the ELF
general-dynamic TLS model only after I had spent almost two days
looking for it in the wrong place (quite fittingly, this now is
issue #666 on our GitHub tracker). Strangely enough, I really
enjoy these kinds of challenges from time to time, though.
On the gc-sections front, Martin had gotten it to work for DMD
on Linux but then had to back it out because it failed with the
ld.gold linker.
If it works for ldc with ld.gold, can you please help explain
what went wrong for dmd?
As far as I can tell at this point, LDC works equally well with
both ld.bfd and ld.gold. Martin and I were discussing some of the
specifics at the main --gc-sections ticket already [1], but it
boils down to the fact that I chose to implement the ModuleInfo
reference pinning in a much less beautiful, but more commonplace
way.
Specifically, I didn't even try to utilize R_arch_NONE
relocations to fake the section dependencies, as this would have
required dropping down to the machine code emission layer of
LLVM. Sticking with a solution that is representable in LLVM IR
meant that we can continue to use the LLVM-provided command line
tools when investigating issues in the optimization/machine code
generation pipeline. As a side-effect, there isn't anything
special about the emitted code, making it less much probable to
hit a weird edge case in one of the linkers. The current solution
is ugly, though, and leads to some tens of bytes of extra junk
per module linked, so we might eventually replace it with
something more sophisticated.
David
[1] https://issues.dlang.org/show_bug.cgi?id=879
