Re: Linker questions
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 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 0038 030f 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
Re: Linker questions
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 0038 030f 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
RE: Linker questions
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: loneti...@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, loneti...@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 0038 030f 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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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, loneti...@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 0038 030f 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@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Linker questions
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 0038 030f 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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
