#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.9
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86_64 (amd64)
Os: FreeBSD |
---------------------+------------------------------------------------------
Comment (by simonmar):
Replying to [comment:7 mboes]:
> Good news: I have a working ghci loading base and giving me a prompt!
This is done by adding MAP_FIXED to the EXTRA_MAP_FLAGS and giving a hint
address, both in loadObj() and in x64_64_high_symbol(). Of course, ghci
segfaults the minute you try to link in more packages, because new
objects will overwrite the old ones in memory at the fixed address.
>
> The upshot is that forcing 32-bit clean mmap()'s is the only issue
needing solving for ghci on FreeBSD/amd64. All the bugs I used to see with
6.6.1 (eg. race conditions with writing characters to the screen) are now
gone. The trick to solve this issue is to calculate a valid place in
memory to mmap() objects in, large enough for the whole object, that does
not conflict with anything else living in memory. Simon, any suggestions
as to the best way to do that?
>
> At the moment I'm loading the object at the 1Gb boundary, and looking
around on the web that's the way that Xorg project are working around
their need for a MAP_32BIT flag on NetBSD. It's an ugly hack, but I don't
see any other way of dealing with a lack of MAP_32BIT. We could increment
the load address by oc->fileSize + <space for jump islands> at each object
load, so that all objects are somewhere above the 1Gb mark. Then create
jump islands for each loaded object directly after it in memory. However,
if we're loading so much in memory at fixed locations we'd have to be very
sure that nothing else is allocated above the 1Gb mark before the linking.
How feasible is this?
This is encouraging. It looks like the solution is going to be dependent
on the layout of memory on FreeBSD and hence might be fragile to future
changes in that area, but it's better than nothing.
You want to look at the memory map of the running process to figure out
where the best place to allocate memory is. On Linux the memory map is
available in `/proc/<pid>/maps` for process `<pid>`.
Note that `MBlock.c` also allocates memory using `mmap`, you probably want
to check that it isn't accidentally grabbing some of the sub-2Gb memory
which would cause problems for the linker.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
