based on patches by Colin Western, mantis #38483)
o requires that the program/library is compiled with -Xg (or that
dsymutil is run on it after compiling), and that the .dSYM bundle
is in the same directory as the program/library
o always use the "dl" unit in exeinfo for Darwin, as that's needed for
dynamic library support, and this does not cause an extra dependency
since on Darwin we always use libc
o cleaned up the exeinfo unit for Darwin, and sped it up by using mmap
instead of small reads
o fixed unit dependencies for exeinfo, lineinfo and lnfodwarf in Darwin
RTL Makefile
* use the process address info from the original exe even when reading
the debug information from an external file
- removed outdated ifdef'd darwin code from dl.pp (no longer needed now
that processaddress gets set correctly in exeinfo for that platform)
git-svn-id: trunk@49140 -
sorting algorithms. A default QuickSort implementation is provided by the
unit. Other units can be added, to provide other sorting algorithms (e.g.
HeapSort, MergeSort, IntroSort, etc.)
* TList and TFPList updated to use the current default sorting algorithm defined
in SortBase for their .Sort method.
git-svn-id: trunk@41167 -
Adjust non-Windows resources to work with indirect main information as well.
rtl/inc/systemh.inc, TEntryInformation:
+ new cross platform field ResLocation which stores the pointer to the resources
rtl/inc/intres.inc:
* change the type of ResHeader from PResHdr to PPResHdr (and adjust code that uses it accordingly; Note: the first dereferencing is assumed to be always valid!)
* adjust declaration of ResHeader depending on whether indirect main information is used or not
rtl/darwin/sysinit.pas & rtl/linux/si_impl.inc:
* pass the location of the resources through SysInitEntryInformation
rtl/bsd/system.pp & rtl/linux/system.pp:
+ new public variable FPCResLocation which is setup by SysEntry
rtl/win32/sysinit.inc:
* initialize ResLocation of SysInitEntryInformation as Nil
rtl/win32/system.pp:
* initialize ResLocation of EntryInformation as Nil
........
For systems that support both internal and external resources (in this case only Darwin ones) we need to generate the FPC_RESLOCATION symbol always, because the SysInit unit is resource type agnostic.
ngenutil.pas, tnodeutils:
* InsertResourceInfo: generate FPC_RESLOCATION symbol pointing to 0 in case the program is compiled on Darwin with resources set to external ones (-We)
git-svn-id: trunk@33952 -
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 -
* also made lnfodwrf dependent on lineinfo for all platforms,
because both units implicitly depend on the exeinfo unit
and if both are compiled at the same time they can fall
over each other while writing its .ppu or .s file
git-svn-id: trunk@33039 -
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 -
