https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150
--- Comment #4 from Iain Buclaw <ibuclaw at gdcproject dot org> --- (In reply to r...@cebitec.uni-bielefeld.de from comment #3) > > --- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> --- > > Thanks, I will write up a small documentation of how the sections modules > > interacts with runtime - along with compiler support. > > Great, thanks. My current goal is to get anything to compile and link > in order to check if the runtime is any good on Solaris. > To give you an initial idea, of what sections is used for, I'll repost what I said to someone else when I started looking at OSX port. * ModuleInfo - All runtime module information are written out to a custom section. For statically linked applications, this section is scanned for module constructors, destructors, unittests, etc... * DSO support - builds on top of minfo with a _d_dso_registry() function that's called once when the dso is loaded, and once on unloading, passing the start and end address of this custom section, so the runtime can keep track of where all minfo are at runtime. * TLS - all static data is thread local by default, and the garbage collector needs to know where TLS data segment is located in all DSOs so that live memory isn't accidentally released. Emulated TLS makes this interesting. * Global data - same as TLS, but requires no special handling other than registering all rw data segments as GC roots. I might as well put this and then some as documentation in the sources.
