The new module discovery scheme requires the following section order:
.minfo_beg
.minfo
.minfo_end
This works for non-PIC code because the segments have the same attributes.
However, if -relocation-model=pic is passed to ldc2 then the .minfo section
becomes writeable and the sequence of sections is changed.
The quick fix is to mark the data always as writeable. Then all sections are
always writeable.
I think a better solution would be to base this in the used relocation model.
But this information is currently only available in the driver.
This fixes the failure in test case runnable/eh2.d
This commit fundamentally changes the way symbol emission in
LDC works: Previously, whenever a declaration was used in some
way, the compiler would check whether it actually needs to be
defined in the currently processed module, based only on the
symbol itself. This lack of contextual information proved to
be a major problem in correctly handling emission of templates
(see e.g. #454).
Now, the DtoResolve…() family of functions and similar only
ever declare the symbols, and definition is handled by doing
a single pass over Module::members for the root module. This
is the same strategy that DMD uses as well, which should
also reduce the maintainance burden down the road (which is
important as during the last few releases, there was pretty
much always a symbol emission related problem slowing us
down).
Our old approach might have been a bit better tuned w.r.t.
avoiding emission of unneeded template instances, but 2.064
will bring improvements here (DMD: FuncDeclaration::toObjFile).
Barring such issues, the change shoud also marginally improve
compile times because of declarations no longer being emitted
when they are not needed.
In the future, we should also consider refactoring the code
so that it no longer directly accesses Dsymbol::ir but uses
wrapper functions that ensure that the appropriate
DtoResolve…() function has been called.
GitHub: Fixes#454.
We can't simply use the C calling convention, as the D(MD)
ABI is callee-pop, and this is hardcoded in naked functions
with stack parameters.
The \1 "trick" is normally used to avoid prefixes added by
LLVM; on the 3.2 release, a patch is needed to make it work
for the @<n> stdcall suffixes as well.
1. Main include corresponding to .cpp file, if any.
2. DMD and LDC includes.
3. LLVM includes.
4. System includes.
Also updated a few include guards to match the default format.
A lot of system specific knowledge is already present in LLVM. This is used to populate several fields in global.params instead of hard coded values in main(). Ensures that the frontend and LLVM have always the same values.
This simplifies the code in module.cpp a bit. But it is also the base to implement a pragma to place an arbitrary function in llvm.global_ctors and llvm.global_dtors.
The string representation of the data layout is retrieved from the TargetData class (in main) and passed via global.params.dataLayout to the module. Since the gTargetData is also a global variable it makes no sense to pass this information using another global variable.
