| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Submitted by: Markus Pfeiffer <markus.pfeiffer@morphism.de> on cvs-ghc
|
| |
|
|
| |
This fixes unresolved symbols error when dynamically linking base.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Slightly modified version of a patch from Ben Collins <bcollins@ubuntu.com>
who did the final debugging that showed the segfault was being caused the
memory protection mechanism.
Due to the requirement of "jump islands" to handle 24 bit relative jump
offsets, GHCi on PowerPC did not use mmap to load object files like the
other architectures. Instead, it allocated memory using malloc and fread
to load the object code. However there is a quirk in the GNU libc malloc
implementation. For memory regions over certain size (dynamic and
configurable), malloc will use mmap to obtain the required memory instead
of sbrk and malloc's call to mmap sets the memory readable and writable,
but not executable. That means when GHCi loads code into a memory region
that was mmapped instead of malloc-ed and tries to execute it we get a
segfault.
This solution drops the malloc/fread object loading in favour of using
mmap and then puts the jump island for each object code module at the
end of the mmaped region for that object.
This patch may also be a solution on other ELF based powerpc systems
but does not work on darwin-powerpc.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Patch by Samuel Thibault.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659530.
|
| | |
|
| |
|
|
|
| |
It uses native 64-bit instructions instead of these, despite having
32-bit pointers.
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
| |
We get these in a full build on Win64
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We now detect if we are given a value that is out of range for a
32bit relocation, and fail with an error.
Added a load more symbols to rtsSyms.
|
| |
|
|
|
|
|
|
|
|
| |
Without this, we ended up using
(gdb) info symbol 0x7ff756a10ac
msvcrt!free in section .text of C:\Windows\system32\msvcrt.dll
for free, rather than
(gdb) info symbol 0x2584128
free in section .text of C:\m64\ghci2\q/../inplace/bin/ghc-stage2.exe
but we were trying to put the address into a 32bit relocation.
|
| |
|
|
|
|
|
|
|
| |
It doesn't suffice for checkProddableBlock to just check whether the
largest possible write could be made at the address we are writing,
as if we are making a smaller write then checkProddableBlock may
conservatively think we will write off the end of the block.
Thus we now tell checkProddableBlock how many bytes we will write.
|
| |
|
|
| |
This reverts commit 29cd6f435f2afb332ad8faf39f5e920ff9c38d9a.
|
| |
|
|
| |
This reverts commit 02cf6d6f71b5772aa4ddf1b70c192a802886e2c2.
|
| |
|
|
| |
This reverts commit 27e585bda6ae8ab68f58abdcb9e06806414a6636.
|
| |
|
|
| |
This reverts commit 05b55c670c7fe3fc01827ca02aafb6926c0b69cb.
|
| |
|
|
| |
This reverts commit 0042c478f1169ddd9392fb39de7d0aed865a272e.
|
| |
|
|
| |
This reverts commit e89ef70475fa5e9cf17af01b1b5d7fced0d2e13c.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
| |
Mostly this meant getting pointer<->int conversions to use the right
sizes. lnat is now size_t, rather than unsigned long, as that seems a
better match for how it's used.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for ELF objects on ARM to the runtime linker. While the list of
relocation types in the "ELF for the ARM Architecture" specification spans four
pages, we thankfully only see a handful of these in the wild. Thus, at the
moment we only support the following .rel relocation types,
* R_ARM_ABS32
* R_ARM_TARGET1
* R_ARM_REL32
* R_ARM_CALL
* R_ARM_JUMP24
* R_ARM_MOVT_ABS
* R_ARM_MOVW_ABS_NC
* R_ARM_THM_CALL
* R_ARM_THM_JUMP24
* R_ARM_THM_MOVT_ABS
* R_ARM_THM_MOVW_ABS_NC
* R_ARM_THM_JUMP8
* R_ARM_THM_JUMP11
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>
|
| |
|
|
|
| |
We may need to do this differently once we get as far as building the
RTS in the dyn ways.
|
| | |
|
| |
|
|
|
| |
I haven't been able to test whether this works or not due to #5754,
but at least it doesn't appear to break anything.
|
| | |
|
| |
|
|
|
|
|
|
| |
The primitive array types, such as 'ByteArray#', have kind #, but are represented by pointers. They are boxed, but unpointed types (i.e., they cannot be 'undefined').
The two categories of array types —[Mutable]Array# and [Mutable]ByteArray#— are containers for unboxed (and unpointed) as well as for boxed and pointed types. So far, we lacked support for containers for boxed, unpointed types (i.e., containers for the primitive arrays themselves). This is what the new primtypes provide.
Containers for boxed, unpointed types are crucial for the efficient implementation of scattered nested arrays, which are central to the new DPH backend library dph-lifted-vseg. Without such containers, we cannot eliminate all unboxing from the inner loops of traversals processing scattered nested arrays.
|
| |
|
|
|
| |
At present the number of capabilities can only be *increased*, not
decreased. The latter presents a few more challenges!
|
| | |
|
| |
|
|
| |
Spotted by gdb's malloc debugger while I was looking for something else.
|
| | |
|
