Symbol versioning and C-FFI

--===============1762930015==
Content-Type: multipart/alternative; boundary=047d7bb70b2e25673c04f5e32574

--047d7bb70b2e25673c04f5e32574
Content-Type: text/plain; charset=ISO-8859-1

I just tracked down an interesting bug.

I'd suggested to @robdaemon that he could build things on OS X in 64 bit to
test some stuff out.

He did and reported that the compiler crashes on startup when built that
way. That's certainly interesting!

The cause of this ended up being that dirent-name in the system library was
using a constant offset for d_name into the dirent struct of 21. This is
the correct value on a 64 bit OS X system if you're working from C as
that's the right offset for a dirent struct using 64 bit inodes.

Unfortunately, since we aren't doing an #include of <dirent.h>, we don't
pick up the versioned / aliased symbols for readdir() and other functions
that would return the dirent struct that uses 64 bit inodes. Instead, we
get back the old dirent struct where the d_name offset is only 8, not 21!
 If we'd included <dirent.h>, we would've been redirected to using
readdir$INODE64() and all would've been well.

We can't include dirent.h as a fix as this won't work for the LLVM backend.
 We don't want to just go and hardcode things to call readdir$INODE64() and
friends on OS X as this won't solve things for other platforms. Indeed, on
Linux, we may not be calling the correct code path either as it isn't clear
to me how readdir() / readdir64() and friends get aliased without digging
into stuff.

I suspect that the right fix is to compile some C stubs that wrap these
functions and make sure that they're calling into the right libc APIs.  We
need these at least for:


   - opendir
   - readdir
   - readdir_r (not used)
   - telldir (not used)
   - fstat (used from C, so no problem)
   - fstatfs (not used)
   - lstat
   - stat
   - statfs (not used)

I don't know what the situation will end up looking like on Linux or where
else this might be an issue.

 - Bruce

--047d7bb70b2e25673c04f5e32574
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I just tracked down an interesting bug.<div><br></div><div=
>I&#39;d suggested to @robdaemon that he could build things on OS X in 64 b=
it to test some stuff out.</div><div><br></div><div>He did and reported tha=
t the compiler crashes on startup when built that way. That&#39;s certainly=
 interesting!</div>
<div><br></div><div>The cause of this ended up being that dirent-name in th=
e system library was using a constant offset for d_name into the dirent str=
uct of 21. This is the correct value on a 64 bit OS X system if you&#39;re =
working from C as that&#39;s the right offset for a dirent struct using 64 =
bit inodes.</div>
<div><br></div><div>Unfortunately, since we aren&#39;t doing an #include of=
 &lt;dirent.h&gt;, we don&#39;t pick up the versioned / aliased symbols for=
 readdir() and other functions that would return the dirent struct that use=
s 64 bit inodes. Instead, we get back the old dirent struct where the d_nam=
e offset is only 8, not 21! =A0If we&#39;d included &lt;dirent.h&gt;, we wo=
uld&#39;ve been redirected to using readdir$INODE64() and all would&#39;ve =
been well.</div>
<div><br></div><div>We can&#39;t include dirent.h as a fix as this won&#39;=
t work for the LLVM backend. =A0We don&#39;t want to just go and hardcode t=
hings to call readdir$INODE64() and friends on OS X as this won&#39;t solve=
 things for other platforms. Indeed, on Linux, we may not be calling the co=
rrect code path either as it isn&#39;t clear to me how readdir() / readdir6=
4() and friends get aliased without digging into stuff.</div>
<div><br></div><div>I suspect that the right fix is to compile some C stubs=
 that wrap these functions and make sure that they&#39;re calling into the =
right libc APIs. =A0We need these at least for:</div><div><br></div><div>
<ul><li>opendir<br></li><li>readdir<br></li><li>readdir_r (not used)<br></l=
i><li>telldir (not used)<br></li><li>fstat (used from C, so no problem)<br>=
</li><li>fstatfs (not used)<br></li><li>lstat<br></li><li>stat<br></li>
<li>statfs (not used)<br></li></ul></div><div><div>I don&#39;t know what th=
e situation will end up looking like on Linux or where else this might be a=
n issue.</div><div><br></div><div>=A0- Bruce</div><div><br></div></div></di=
v>

--047d7bb70b2e25673c04f5e32574--

--===============1762930015==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers

--===============1762930015==--