summaryrefslogtreecommitdiff
path: root/compiler/ghci/ByteCodeFFI.lhs
Commit message (Collapse)AuthorAgeFilesLines
* Remove unused ghci/ByteCodeFFI.lhsIan Lynagh2011-05-251-28/+0
|
* avoid Foreign.unsafePerformIORoss Paterson2010-09-091-1/+1
|
* Fix to new executable allocation code (fixed print002 etc.)Simon Marlow2008-09-221-16/+1
| | | | | | | | | | The problem here is caused by the fact that info tables include a relative offset to the string naming the constructor. Executable memory now resides at two places in the address space: one for writing and one for executing. In the info tables generated by GHCi, we were calculating the offset relative to the writable instance, rather than the executable instance, which meant that the GHCi debugger couldn't find the names for constructors it found in the heap.
* On Linux use libffi for allocating executable memory (fixed #738)Simon Marlow2008-09-191-3/+5
|
* Import libffi-3.0.4, and use it to provide FFI support in GHCiSimon Marlow2008-04-081-848/+1
| | | | | | | | | | | | | | | | | | | | This replaces the hand-rolled architecture-specific FFI support in GHCi with the standard libffi as used in GCJ, Python and other projects. I've bundled the complete libffi-3.0.4 tarball in the source tree in the same way as we do for GMP, the difference being that we always build and install our own libffi regardless of whether there's one on the system (it's small, and we don't want dependency/versioning headaches). In particular this means that unregisterised builds will now have a fully working GHCi including FFI out of the box, provided libffi supports the platform. There is also code in the RTS to use libffi in place of rts/Adjustor.c, but it is currently not enabled if we already have support in Adjustor.c for the current platform. We need to assess the performance impact before using libffi here too (in GHCi we don't care too much about performance).
* attempt to fix #2098 (PPC pepple please test & fix)Simon Marlow2008-02-181-18/+22
|
* FIX BUILD on x86_64Simon Marlow2008-02-061-7/+7
|
* Support for using libffi to implement FFI calls in GHCi (#631)Simon Marlow2008-02-041-45/+63
| | | | | | | | | | | | This means that an unregisterised build on a platform not directly supported by GHC can now have full FFI support using libffi. Also in this commit: - use PrimRep rather than CgRep to describe FFI args in the byte code generator. No functional changes, but PrimRep is more correct. - change TyCon.sizeofPrimRep to primRepSizeW, which is more useful
* Avoid Haddock bug #1821simonpj@microsoft.com2007-11-021-1/+1
|
* Fix CodingStyle#Warnings URLsIan Lynagh2007-09-041-1/+1
|
* Use OPTIONS rather than OPTIONS_GHC for pragmasIan Lynagh2007-09-031-2/+2
| | | | | | | Older GHCs can't parse OPTIONS_GHC. This also changes the URL referenced for the -w options from WorkingConventions#Warnings to CodingStyle#Warnings for the compiler modules.
* Add {-# OPTIONS_GHC -w #-} and some blurb to all compiler modulesIan Lynagh2007-09-011-0/+7
|
* x86_64: fix a few bugs in the >8 floating point args caseSimon Marlow2007-06-261-22/+38
|
* Handle LongArg's in the FFI on x86Ian Lynagh2006-12-221-1/+1
|
* MERGE: Fix Windows DEP violations (bug #885)Simon Marlow2006-12-121-5/+16
| | | | Original patch by brianlsmith@gmail.com
* More import tidying and fixing the stage 2 buildSimon Marlow2006-10-111-9/+9
|
* remove a traceSimon Marlow2006-04-111-2/+2
|
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+832
Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.
View Lorry Controller Status