This week's experiment build gdc with tls disabled.

[Johannes Pfau]

Am Thu, 19 Dec 2013 18:59:42 +0100
schrieb "David Nadlinger" <code at klickverbot.at>:

> Yes, this was the idea.
> 
> > We can then access the bracket-symbols from a 
> > module-constructor (or a
> > c-like .ctor constructor) in the library? So we'd have to add
> > drtbegin.o / drtend.o files to every d library or executable.
> 
> That is pretty much how it is done in DMD and LDC as well. The 
> only difference is that instead of modifying the linker scripts 
> to accommodate this, we emit the ModuleInfo references to custom 
> sections. The GNU toolchain (and we are in highly system-specific 
> territory here anyway) never changes the order of custom 
> sections, which you can also verify using 
> __attribute__((section("...))) in GCC. Thus, if you emit your 
> relevant symbols into three sections like this,
> 
> a.o
> ---
> _minfo_beg: moduleInfoBeginTag
> _minfo: moduleInfoForA
> _minfo_end: moduleInfoEndTag
> 
> b.o
> ---
> _minfo_beg: moduleInfoBeginTag
> _minfo: moduleInfoForB
> _minfo_end: moduleInfoEndTag
> 
> the linked result will be
> 
> _minfo_beg: moduleInfoBeginTag
> _minfo: moduleInfoForA moduleInfoForB
> _minfo_end: moduleInfoEndTag
> 
> and you can just use [moduleInfoBeginTag, moduleInfoEndTag) to 
> get a list of all available ModuleInfos.
> 
> 
> Of course, once shared libraries come into play, you have to 
> consider quite a few subtleties regarding symbol visibility and 
> so on.

Yes, I got that part. Begin/End symbols should be private to the library
and accessed from a constructor function in that library which then
passes the addresses of these symbols to the _d_dso_registry function.

(And for TLS if we had these symbols tey would also be 'private' to
different threads, so we'd have to register them at thread startup for
every dso but AFAICS the currect DMD code basically does that already)

However, I'd prefer to pass an additional object file to ld which
contains this constructor instead of placing this code into every
object file, but that's probably just a personal preference.

> Also, due to a bug in LLVM, LDC can't emit weak symbols 
> with custom section names, so we end up with multiple copies of 
> the begin/end symbols and the C .ctor/.dtor table entries.
> 
> But in general, this works quite well, and is certainly much more 
> portable than requiring changes to the linker script.
> 
> David

Sounds like that could work. But as the module section is a custom
section anyway we wouldn't have to replace/modify the default linker
script - we can pass a custom script to ld which just handles the
".minfo" section. That should be just as portable as relying on the
"don't reorder sections" behavior: Works everywhere where GNU Binutils
LD/GOLD are used. (Emitting 3 sections is a clever trick, but it feels
like a hack imho. I'm also not sure if we can control the order in
which sections are emitted in GCC)

Even if we don't want to go that route I'll try to write a proof of
concept this weekend as I really want to know now whether this will
work.


It seems like getting the TLS section is the more interesting part. We
can't emit sections around the TLS section so IIRC the current dmd
implementation therefore relies on the runtime linker and libc specific
interfaces?

I think asking the binutils maintainers to add __tdata_begin,
__tdata_end, __tbss_begin and __tbss_end markers to the tdata and tbss
sections would be a nice long-term solution, or is there some issue
with that?

If the maintainers don't want to add these extra symbols for every
library we might ask for special treatment of dso_start.o/dso_end.o
files, similar to what they do for crtbegin.o/crtend.o for C++.


I'm wondering though if ld actually reorders symbols in a section by
default? I know there are some --sort-section options, but does it sort
by default? IIRC we used to use TLS bracketing in GDC and Iain said
there were some issues. But if we placed the begin/end markers into
extra object files and supplied them as first/last file to the linker,
wouldn't that work for now?