#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
Reporter: mboes | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8.3
Component: GHCi | Version: 6.8.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86_64 (amd64)
Os: FreeBSD |
---------------------+------------------------------------------------------
Comment (by mboes):
Debug output of
{{{
./stage2/ghc-inplace --interactive +RTS -Dl 2>&1 | tee log
}}}
is at [http://code.haskell.org/~mboes/log.bz2] (log too big for attachment
on trac).
Note that FreeBSD, just like OpenBSD, does not define MAP_32BIT and
MAP_ANONYMOUS. I see in Linker.c the following #define:
{{{
#if defined(x86_64_HOST_ARCH) && defined(MAP_32BIT)
#define EXTRA_MAP_FLAGS MAP_32BIT
#else
#define EXTRA_MAP_FLAGS 0
#endif
}}}
But then I see an attempt to resolve symbols allocated in high memory
using a bounce sequence:
{{{
// On x86_64, 32-bit relocations are often used, which requires that
// we can resolve a symbol to a 32-bit offset. However, shared
// libraries are placed outside the 2Gb area, which leaves us with a
// problem when we need to give a 32-bit offset to a symbol in a
// shared library.
//
// For a function symbol, we can allocate a bounce sequence inside the
// 2Gb area and resolve the symbol to this. The bounce sequence is
// simply a long jump instruction to the real location of the symbol.
//
// For data references, we're screwed.
//
...
static void*
x86_64_high_symbol( char *lbl, void *addr )
{
x86_64_bounce *bounce;
if ( x86_64_bounce_buffer == NULL ||
x86_64_bb_next_off >= X86_64_BB_SIZE ) {
x86_64_bounce_buffer =
mmap(NULL, X86_64_BB_SIZE * sizeof(x86_64_bounce),
PROT_EXEC|PROT_READ|PROT_WRITE,
MAP_PRIVATE|EXTRA_MAP_FLAGS|MAP_ANONYMOUS, -1, 0);
if (x86_64_bounce_buffer == MAP_FAILED) {
barf("x86_64_high_symbol: mmap failed");
}
x86_64_bb_next_off = 0;
}
...
}}}
Since there is no MAP_32BIT on FreeBSD it would seem the above bounce
sequence can get arbitrarily allocated in high memory. Could this be the
problem? I'm way out of my depth here, so please forgive the daftness of
this question, but on my system there are no 32bit libraries at all, only
64bit ones. Hence, could we do away with 32bit relocations entirely?
Hope this helps,
Mathieu
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
