-
Julian Seward authored
Make the PEi386 linker able to handle symbols in .bss sections (almost) correctly: * "Anonymous" bss sections (where something like static int a[10] lives) are given a calloc'd block of memory to live in. * Publically visible bss-resident symbols, such as int a[10] are each given their own calloc'd block. The normal way of things is for identically-named symbols in different modules to be commoned up and allocated the largest stated size of any of the symbols. We don't do that -- if two different .o files each declared int a[10], you'll get two independent lumps of memory. Hence "almost" above. These calloc'd lumps (pseudo-bss spaces) are not added to the list of sections extracted for the benefit of the closure-vs-itbl pointer checks done by the garbage collector. I don't think that matters. These fixes need to be propagated to other formats too (viz, ELF). This fixes the problem reported by ??? in which, on Windows, writeFile "foo" "bar" in GHCi gives a segfault. This bug was so horrible to track down and fix that I have instituted range checking in the relocation processing machinery. The runtime linker checks all locations it is patching to ensure they are within a known segment before writing to them. Hopefully this will pick up any future problems. The performance impact of this, assessed by the time to start up GHCi, is unmeasureably small.
cb97b80d