Linker questions

[Phyx]

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 <ezyang at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150820/c5913430/attachment.html>