<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Oleg</p>
<p>I have written a simple test case that addresses your
suggestions. My simple test program now calls __open() and the
LD_PRELOAD'd shared object, libopen.so, exports __open(). The
attached tar file creates a directory stdio. cd into it and <b><font
face="Courier New, Courier, monospace">make clean all</font></b>.
Then run <b>./stdio.csh</b>. You will see that the program's
call to __open() is intercepted, as evidenced by the fprintf()
from the preloaded __open(). But the open() call made by fopen()
is still not reported by the preloaded function. I am thoroughly
convinced fopen()'s call to open(), by whatever name it is using
for open(), can not be intercepted. The most compelling evidence
is the output from the run-time loader when LD_DEBUG=all is set.
If I remove the call to __open() from the test program, the only
function with open in its name that the run-time loader reports
searching for is fopen(). The call that fopen() makes to open()
is probably satisfied when libc is built.</p>
<p>Per Andreas's suggestion, I have tried to build a debug version
of glibc, but I think this is a bit outside my wheelhouse. It
always turns into some type of struggle to get glibc to build
correctly for the system I am on. I am seeking assistance on that
front from admins on the system I am using. This URL is an
interesting read,
<a class="moz-txt-link-freetext" href="http://blog.hostilefork.com/where-printf-rubber-meets-road/">http://blog.hostilefork.com/where-printf-rubber-meets-road/</a> . It
covers the write() call from fprintf(), but I assume open() would
have the same issues. If I understand this correctly, the write()
call from fprintf() boils down to a syscall at compile time. It
doesn't even bother will calling write(). glibc skips the step of
calling write() and goes straight to syscall() when calling
write() from inside of glibc.<br>
</p>
<p>Thanks again.<br>
</p>
<p>John<br>
</p>
<br>
<div class="moz-cite-prefix">On 6/23/2016 4:50 PM, Oleg Drokin
wrote:<br>
</div>
<blockquote
cite="mid:22ECFBA2-BD72-4751-8B92-E58D6FEAD9FF@intel.com"
type="cite">
<pre wrap="">#include <unistd.h>
<span class="moz-txt-citetags">> </span>#include <stdlib.h>
<span class="moz-txt-citetags">> </span>#include <fcntl.h>
<span class="moz-txt-citetags">> </span>#include <stdio.h>
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>int
<span class="moz-txt-citetags">> </span>main(int argc, char ** argv ){
<span class="moz-txt-citetags">> </span> FILE *f = fopen("a", "r" ) ;
<span class="moz-txt-citetags">> </span> fprintf(stderr,"f=%p\n",f);
<span class="moz-txt-citetags">> </span> fclose(f);
<span class="moz-txt-citetags">> </span>}</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
I/O Doctors, LLC
507-766-0378
<a class="moz-txt-link-abbreviated" href="mailto:bauerj@iodoctors.com">bauerj@iodoctors.com</a></pre>
</body>
</html>