Hi Tamar, I haven't a clue about any of this. But I didn't want your detailed email to go without any response. Perhaps agitate a bit on #ghc at freenode to get some attention? Also, be aware that many people are on holiday right now, and so responses may be slower than at other times.
Sorry I can't be more helpful, but I definitely appreciate your looking into this! Richard On Aug 11, 2015, at 3:43 PM, [email protected] wrote: > Hi *, > > I had a few questions about the linker I was hoping someone can help me with, > I'm pretty new to it so any insights would be appreciated. > > 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? > > 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. > > Regards, > Tamar > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
