<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Jul 12, 2012 at 7:07 PM, Tristan Ravitch <span dir="ltr"><<a href="mailto:travitch@cs.wisc.edu" target="_blank">travitch@cs.wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Thu, Jul 12, 2012 at 06:29:41PM +0300, Michael Snoyman wrote:<br>
> I've come up with a minimal example that demonstrates this problem. The<br>
> crux of the matter is the following C code:<br>
><br>
> #include <sys/types.h><br>
> #include <sys/stat.h><br>
> #include <unistd.h><br>
> #include <stdio.h><br>
><br>
> typedef int stat_func(const char*, struct stat*);<br>
><br>
> stat_func *foo = &stat;<br>
><br>
> void stat_test(void)<br>
> {<br>
> struct stat buf;<br>
><br>
> printf("About to stat-test.c\n");<br>
> foo("stat-test.c", &buf);<br>
> printf("Done\n");<br>
> }<br>
><br>
> As you can see, all of the include statements are present as necessary. The<br>
> code compiles just fine with -Wall -Werror. And when you compile the<br>
> Haskell code as well, everything works just fine. But if you follow these<br>
> steps, you can reproduce the error I saw:<br>
><br>
> * Unpack the attached tarball<br>
> * `cabal install` in that folder<br>
> * `runghc main.hs` from the `exe` folder<br>
><br>
> On my system at least, I get:<br>
><br>
> main.hs:<br>
> /home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o:<br>
> unknown symbol `stat'<br>
> main.hs: main.hs: unable to load package `stat-test-0.1.0.0'<br>
><br>
> One thing I noticed is that I needed to use a function pointer to trigger<br>
> the bug. When I called `stat` directly the in stat_test function, gcc<br>
> automatically inlined the call, so that the disassessmbled code just showed<br>
> a `moveq` (i.e., it's making the system call directly). But using a<br>
> function pointer, we're avoiding the inlining. I believe this is why this<br>
> issue only came up with the sqlite3 upgrade: previous versions did not use<br>
> a function pointer, but rather hard-coded in how to make a stat call.<br>
><br>
> Does this expose any other possibilities?<br>
><br>
> Michael<br>
<br>
</div></div>Are you trying this on a 32 bit system? And when you compiled that C<br>
program, did you try to add<br>
<br>
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE<br>
<br>
to the compile command? When I define those the resulting object file<br>
from your example correctly references stat64 instead of stat.<br>
</blockquote></div><br><div>I'm compiling on a 64 bit system. If I add those definitions, the program uses stat64 instead, but the only difference is that runghc now prints:</div><div><br></div><div><div> main.hs: /home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o: unknown symbol `stat64'</div>
<div> main.hs: main.hs: unable to load package `stat-test-0.1.0.0'</div></div><div><br></div><div>In other words, it's not the symbol that the object file is referencing (stat vs stat64) that's the problem: runghc is not able to resolve either one.</div>
<div><br></div><div>Michael</div></div>