Hi Edward, Thanks for the information, it really helped make it more clear to me what's going on.
I would ideally like to get these validate errors on Windows down to 0 (without marking them as expected fail). So I will probably make a ticket for this. Cheers, Tamar On Thu, Aug 20, 2015 at 1:28 AM, Edward Z. Yang <ezy...@mit.edu> wrote: > Excerpts from lonetiger's message of 2015-08-11 12:43:34 -0700: > > 1) Has to do with checkProddableBlock and #10672 and #10563 > > > > static void checkProddableBlock (ObjectCode *oc, void *addr, size_t size > ) > > { > > ProddableBlock* pb; > > > > for (pb = oc->proddables; pb != NULL; pb = pb->next) { > > char* s = (char*)(pb->start); > > char* e = s + pb->size; > > char* a = (char*)addr; > > if (a >= s && (a+size) <= e) return; > > } > > barf("checkProddableBlock: invalid fixup in runtime linker: %p", > addr); > > } > > > > From what I have found, these errors seem to happen because > oc->proddables is initially NULL, > > the for loop is skipped. From what I can tell, this function is checking > if there's a "proddable" > > that fits within the supplied address and size. So if there is no > proddables to begin with, should this > > check just not be skipped and the callee of this call not use this > ObjectCode instead of erroring out? > > Relocating objects consists of iterating over a list of "relocations", > which essentially says, "please modify the word of memory at addr to > point to the actual location of some symbol." > > The essential effect is that GHC is going to scribble over some memory > that the object told it to. So it's a /really really/ idea to make sure > that we aren't scribbling over something random, like some GHC > structures. checkProddableBlock ensures that the memory location to > be relocated ACTUALLY resides in the object code we are loading. > > If we put it this way, it's pretty obvious what the bug has to be: > we are processing a relocation for some code that we didn't actually > make a proddable block for. This can happen if we didn't understand > the section. > > I've updated #10672 and #10563 accordingly. > > > 2) The second question is about static int ocGetNames_PEi386 ( > ObjectCode* oc ) > > I am getting a test failure because it is claiming that .eh_frame > section is misaligned. > > This comes from this code: > > > > if (kind != SECTIONKIND_OTHER && end >= start) { > > if ((((size_t)(start)) % 4) != 0) { > > errorBelch("Misaligned section %s: %p", (char*)secname, > start); > > stgFree(secname); > > return 0; > > } > > > > Where start is defined as: > > > > start = ((UChar*)(oc->image)) + sectab_i->PointerToRawData; > > and oc->image is a memory location received by > allocateImageAndTrampolines. > > > > In the case of my test failure it is because the .eh_frame section seems > to begin at 0x30F > > since oc->image will always be 4 aligned (so it doesn't really matter in > the check) it gives that error because PointerToRawData isn't aligned by 4. > > > > So my question is would it not be better just to check the alignment > flag in the PE section header instead of checking the load address (which > is always going to aligned to 4?) and The file pointer to > > the first page of the section within the COFF file to determine the > alignment? Like objdump and dumpbin do? > > > > e.g. > > > > 9 .eh_frame 00000038 00000000 00000000 0000030f 2**2 > > CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA > > > > Is the output from objdump which correctly determines the alignment from > the section. From what I understand from the PE specification > > the on disk address doesn't have to be aligned by 4: > > > > "For object files, the value *should* be aligned on a 4-byte boundary > for best performance." > > > > I'm wondering if we are incorrectly erroring out here, instead of using > the section and making sure we pad it to the alignment boundary. > > It should be fine to make the code more flexible to accept arbitrary > alignments. However, I would expect you would have to make some code > to make this work. > > If you are interested in doing this, make sure you add tests to the test > suite which specifically construct objects with sections which are not > 4-byte aligned. Please also feel free to open a bug to track this work. > > Thanks, > Edward >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs