Switch Mac OS X to indirect entry information.
compiler/systems/t_bsd.pas, TLinkerBSD:
+ implement InitSysInitUnitName
compiler/system.pas:
* systems_internal_sysinit: add Darwin systems
compiler/hlcgobj.pas, thlcgobj:
* gen_proc_symbol_end: for Darwin systems don't directly call PascalMain for libraries, but FPC_LIBMAIN instead
rtl/darwin:
+ add sysinit.pas unit which contains the executable and library entry points for Darwin
rtl/darwin/Makefile.fpc:
* add sysinit unit
rtl/bsd/sysosh.inc:
+ add a Darwin specific TPlatformEntryInformation (could probably be used for all Unix systems...)
rtl/bsd/system.pp:
* define FPC_HAS_INDIRECT_MAIN_INFORMATION for Darwin systems once we're no longer bootstrapping with 2.6.x
+ add EntryInformation variable (this could maybe moved to system.inc...)
+ add new procedure SysEntry that is called from the entrypoint and which sets up necessary information required by other parts of the RTL
* the old FPC_SYSTEMMAIN is still in place for bootstrapping
rtl/inc/systemh.inc, TEntryInformation:
* PascalMain is cdecl on non-Windows systems (ToDo: really?)
rtl/inc/system.inc:
* initialstklen is provided by the indirect entry information, so no external here
........
Fix bootstrapping.
rtl/darwin/sysinit.pas:
* enable the code only when no longer bootstrapping with 2.6.x
........
Fix bootstrapping.
rtl/objpas/objpas.pp:
* define FPC_HAS_INDIRECT_MAIN_INFORMATION for Darwin only while not bootstrapping with 2.6.x
........
rtl/darwin/sysinit.pas:
* reference PASCALMAIN correctly (I wonder how this even worked previously :/ )
git-svn-id: trunk@33949 -
systems.pas:
+ add new constant systems_indirect_var_imports to denote all targets that /require/ indirect references for cross-unit variables accesses
git-svn-id: trunk@33284 -
Add a new target flag which determines whether the target supports dynamic packages or not.
systems.pas:
+ new flag tf_supports_packages
pmodules.pas, proc_package:
* error out when flag tf_supports_packages is not set for the current target
msg/errore.msg:
+ error message for when tf_supports_packages is missing and a package file is compiled
........
git-svn-id: trunk@32978 -
caller side, as this is an AArch64 ABI requirement (unrelated to Darwin).
Fixes webtbs/tw3523 compiled with optimisations on Linux/AArch64
git-svn-id: trunk@32102 -
for all non-ppc(32/64) Darwin platforms
o pass the macosx-version-min/iphoneos-version-min to clang as an assembler,
so that it properly sets this information starting with Xcode 7 (solves
errors when targeting the iOS simulator, and warnings about object files
being compiled for a different OS X version when targeting (Mac) OS X)
o the old assembler is still selectable via -Aas-darwin (required with
Xcode 3.1.x and older)
o since the first Xcode version that shipped with Clang is Xcode 3.2, which
is available for Mac OS X 10.6, most users should not encounter any issues
with the new default (in fact, it fixes some tests for x86 because Clang
supports some instructions that "as" doesn't). Clang does not support
Stabs however, so -gs does require the use of -Aas-darwin
git-svn-id: trunk@31830 -
library. This resolves a problem with parallel building of a i8086 cross
compiler, due to a race condition in wlib, when running several instances of
wlib in the same directory. The problem is in the way wlib creates a temp file
in the current directory using non-atomic operations and with a high
probability of a name collision. Using separate input and output files avoids
this temp file creation by wlib.
git-svn-id: trunk@30277 -
as the AIX abi (especially on ppc64)
o replaced (for now) all checks for the AIX abi with a check for either the
AIX or Darwin abi
o changed the ABI of Darwin/ppc, Darwin/ppc64 and Mac OS/ppc to
abi_powerpc_darwin
git-svn-id: trunk@30202 -
be copied on the caller instead of callee side
o mark Darwin/Aarch64 as such a target (any AArch64 target will be like
that normally, as its ABI specifies this behaviour)
o don't mark by-reference value parameters on such targets as
vo_has_local_copy, since a) they don't have one (the copy is on the
caller side), and b) this ensures that all code handling such
parameters automatically knows that they are still by reference
after the init code has run
o when making the copies on the caller side, don't increase the
reference count for managed types except for variants, just like
is done when making the copies on the callee side. This is because
the reference count increasing code on the callee side only runs
for non-assembler functions, and we cannot know 100% certain on the
caller side whether the called function is assembler or not (e.g. in
case of externally declared functions)
o maybe over time we can reuse the Pascal code in
tcallparanode.copy_value_by_ref_para to replace the equivalent code
in hlcgobj and ncgutil also on the caller side for other targets
git-svn-id: trunk@29870 -
o blocks are implemented as a variation of procedure variables
o declaration of a block variable: "test: procedure(c: char) is block;"
(C equivalent: (void)(^test)(char c) )
o the compiler automatically converts procedures/functions whose address
is passed to a block parameter or assigned to a block variable into
a "block". This consists of
1) generating a block descriptor (containing the size of the "block
literal" (see below) and the signature of the invocation function
encoded as an Objective-C selector)
2) generating a wrapper function around the original funcion (with C
calling convention), that has an extra first hidden parameter
(marked as vo_is_parentfp in the compiler) whose type is a pointer
to the describing "block literal"
3) generating the "block literal", which contains a pointer to an
external variable indicating whether this block captures context or
not, some flags (see compiler/blockutl.get_block_literal_flags for
info), a pointer to the wrapper function and a pointer to the
descriptor. In the future, it will also contain captured variables.
o right now, only global procedures/functions can be converted to blocks
(because they don't require state capturing). The next steps are (Object
Pascal) methods (not Objective-C methods, because Objective-C method
procvars don't exist) and finally nested functions
o on Mac OS X, the functionality will only work on Mac OS X 10.7 and later,
because we have to use the so-called "ABI.2010.3.16" to ensure that
our blocks aren't called as variadic functions by the runtime (which
came out after the Mac OS X 10.6 release)
o while the currently implemented functionality does not require any
library support at all, there's no use enabling it on other platforms
because unless it has been confirmed to work with a blocks runtime,
there's no point in using blocks (they're just somewhat bulky procvars
right now). Enabling it on other platforms (in combination with the
GNUStep Objective-C run time), should simply be a matter of adding
the right {$linklib xxx} statement to rtl/inc/blockrtl.pp file, adding
that file to Makefile.fpc for that platform and adding that platform
to the compiler/systems.systems_blocks_supported set
git-svn-id: branches/blocks@28232 -