| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
RTLD_NOW apparently causes some problems, according to previous
mailing-list discussion
http://www.haskell.org/pipermail/cvs-ghc/2007-September/038570.html
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2301: Control-C now causes the new exception (AsyncException
UserInterrupt) to be raised in the main thread. The signal handler
is set up by GHC.TopHandler.runMainIO, and can be overriden in the
usual way by installing a new signal handler. The advantage is that
now all programs will get a chance to clean up on ^C.
When UserInterrupt is caught by the topmost handler, we now exit the
program via kill(getpid(),SIGINT), which tells the parent process that
we exited as a result of ^C, so the parent can take appropriate action
(it might want to exit too, for example).
One subtlety is that we have to use a weak reference to the ThreadId
for the main thread, so that the signal handler doesn't prevent the
main thread from being subject to deadlock detection.
1619: we now ignore SIGPIPE by default. Although POSIX says that a
SIGPIPE should terminate the process by default, I wonder if this
decision was made because many C applications failed to check the exit
code from write(). In Haskell a failed write due to a closed pipe
will generate an exception anyway, so the main difference is that we
now get a useful error message instead of silent program termination.
See #1619 for more discussion.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
