Linker questions

lonetiger at gmail.com lonetiger at gmail.com
Fri Aug 14 03:31:18 UTC 2015


Hi Richard,

Thanks for the reply, I completely forgot that most people were probably on holidays ☺

I’ll try the irc channel as well.

Cheers,
Tamar



From: Richard Eisenberg
Sent: Friday, August 14, 2015 04:46
To: lonetiger at gmail.com
Cc: GHC
Subject: Re: Linker questions


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, lonetiger at gmail.com 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
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150814/9ac70ea7/attachment-0001.html>


More information about the ghc-devs mailing list