| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has several advantages:
- -fvia-C is consistent with -fasm with respect to FFI declarations:
both bind to the ABI, not the API.
- foreign calls can now be inlined freely across module boundaries, since
a header file is not required when compiling the call.
- bootstrapping via C will be more reliable, because this difference
in behavour between the two backends has been removed.
There is one disadvantage:
- we get no checking by the C compiler that the FFI declaration
is correct.
So now, the c-includes field in a .cabal file is always ignored by
GHC, as are header files specified in an FFI declaration. This was
previously the case only for -fasm compilations, now it is also the
case for -fvia-C too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
File locking (of the Haskell 98 variety) was previously done using a
static table with linear search, which had two problems: the array had
a fixed size and was sometimes too small (#1109), and performance of
lockFile/unlockFile was suboptimal due to the linear search.
Also the algorithm failed to count readers as required by Haskell 98
(#629).
Now it's done using a hash table (provided by the RTS). Furthermore I
avoided the extra fstat() for every open file by passing the dev_t and
ino_t into lockFile. This and the improvements to the locking
algorithm result in a healthy 20% or so performance increase for
opening/closing files (see openFile008 test).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
x86_64_high_symbol()
This is Wolfgang Thaller's patch sent to cvs-ghc recently, with extra
commentary by me. It turns out that this patch is not just a cleanup,
it is also necessary for GHCi to work on x86_64 with shared libraries,
because previously lookupSymbol() was creating jump-table entries for
all symbols looked up that resolved outside 2Gb, whereas Wolfgang's
version only generates jump-table entries for 32-bit symbol references
in object code that we load.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously MVars were always on the mutable list of the old
generation, which meant every MVar was visited during every minor GC.
With lots of MVars hanging around, this gets expensive. We addressed
this problem for MUT_VARs (aka IORefs) a while ago, the solution is to
use a traditional GC write-barrier when the object is modified. This
patch does the same thing for MVars.
TVars are still done the old way, they could probably benefit from the
same treatment too.
|
| | |
|
| | |
|
| |
|
|
|
| |
addDLL returns const char*, not just a char*.
Fix compiler warning
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
On OS X 10.4 and newer, we have to use dlsym because the old NS* interface has
been deprecated. The patch checks for HAVE_DLFCN_H instead of switching on
the OS version.
There is one additional quirk: although OS X prefixes global symbols with an
underscore, dlsym expects its argument NOT to have a leading underscore. As a
hack, we simply strip it off in lookupSymbol. Something a bit more elaborate
might be cleaner.
|
| |
|
|
| |
Also noticed a few others from RtsAPI were missing, so I added them all
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
instead of &<sym>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
When -fbreak-on-exception is set, an exception will cause GHCi to
suspend the current computation and return to the prompt, where the
history of the current evaluation can be inspected (if we are in
:trace). This isn't on by default, because the behaviour could be
confusing: for example, ^C will cause a breakpoint. It can be very
useful for finding the cause of a "head []" or a "fromJust Nothing",
though.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the result of Bernie Pope's internship work at MSR Cambridge,
with some subsequent improvements by me. The main plan was to
(a) Reduce the overhead for breakpoints, so we could enable
the feature by default without incurrent a significant penalty
(b) Scatter more breakpoint sites throughout the code
Currently we can set a breakpoint on almost any subexpression, and the
overhead is around 1.5x slower than normal GHCi. I hope to be able to
get this down further and/or allow breakpoints to be turned off.
This patch also fixes up :print following the recent changes to
constructor info tables. (most of the :print tests now pass)
We now support single-stepping, which just enables all breakpoints.
:step <expr> executes <expr> with single-stepping turned on
:step single-steps from the current breakpoint
The mechanism is quite different to the previous implementation. We
share code with the HPC (haskell program coverage) implementation now.
The coverage pass annotates source code with "tick" locations which
are tracked by the coverage tool. In GHCi, each "tick" becomes a
potential breakpoint location.
Previously breakpoints were compiled into code that magically invoked
a nested instance of GHCi. Now, a breakpoint causes the current
thread to block and control is returned to GHCi.
See the wiki page for more details and the current ToDo list:
http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger
|
| |
|
|
| |
Initial support for loading x86_64 Mach-O files
|
| |
|
|
|
|
| |
... so that GHCi doesn't complain about duplicate symbols when two C modules define the same static variable.
MERGE TO STABLE.
|
| |
|
|
|
|
|
| |
The __i686.get_pc_thunk symbols generated by gcc's PIC code generator are weak definitions that appear in every object file, so we need to deal with them.
MERGE TO STABLE.
|
| | |
|
| |
|
|
|
| |
We recently discovered that they aren't a win any more, and just cost
code size.
|
| |
|
|
|
|
|
| |
This patch adds data constructor names into their info tables.
This is useful in the ghci debugger. It replaces the old scheme which
was based on tracking data con names in the linker.
|
| | |
|
| |
|
|
|
|
| |
David Kirkman and Peter Tanski noticed that a line had been removed during
a patch merge which meant that oc->image pointed to the wrong place and
ultimately caused an error from realloc.
|
| |
|
|
|
|
| |
Specifically, this disables the special support in the RTS for looking up the datacon name corresponding to an address.
Correspondingly, the debugging commads in GHCi will not be available, and neither will the '-fdebugging' flag
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch extends the RTS linker and the dynamic linker so that it is possible to find out the datacon of a closure in heap at runtime:
- The RTS linker now carries a hashtable 'Address->Symbol' for data constructors
- The Persistent Linker State in the dynamic linker is extended in a similar way.
Finally, these two sources of information are consulted by:
> Linker.recoverDataCon :: a -> TcM Name
|
| | |
|
| |
|
|
| |
Original patch by brianlsmith@gmail.com
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
StableRoots opened new possibilities in the world
of plugins with their ability to link partially
applied closures against object code.
Exporting '(fn pluginwideState)' severely reduced
the complexity of HIDE's plugin system. The previous
system of global variables was both fragile and hard
to scale.
Good bye, StableRoots. We sure had some fun.
|
| |
|
|
| |
Apparently, the original fix never really worked due to typos and oversights.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In preparation for parallel GC, split up the monolithic GC.c file into
smaller parts. Also in this patch (and difficult to separate,
unfortunatley):
- Don't include Stable.h in Rts.h, instead just include it where
necessary.
- consistently use STATIC_INLINE in source files, and INLINE_HEADER
in header files. STATIC_INLINE is now turned off when DEBUG is on,
to make debugging easier.
- The GC no longer takes the get_roots function as an argument.
We weren't making use of this generalisation.
|
| | |
|
