For the adventurous: News from the LDC/Linux front

David Nadlinger via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 8 14:32:04 PDT 2014


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


More information about the Digitalmars-d mailing list