[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lustre-discuss
Subject:    Re: [lustre-discuss] [lustre-devel]  more on lustre striping
From:       Oleg Drokin <oleg.drokin () intel ! com>
Date:       2016-06-23 21:50:29
Message-ID: 22ECFBA2-BD72-4751-8B92-E58D6FEAD9FF () intel ! com
[Download RAW message or body]

I think what you are missing is that __open that you need to intercept comes from \
libc, so it does not need to be bound from your file because your binary does not \
call it, glibc calls it AND if your LD_PRELOAD'ed library defines it you'll catch it.

The proper test would have been to write a LD_PRELOADable library that
defines __open and then run your test application with it.


On Jun 10, 2016, at 12:04 PM, John Bauer wrote:

> To confirm the point that you can not intercept the open called by fopen by using \
> LD_PRELOAD, I have written a simple test case.  Note that the runtime linker never \
> looks for open().  Only fopen() $ cat a.c
> #include <unistd.h>
> #include <stdlib.h>
> #include <fcntl.h>
> #include <stdio.h>
> 
> int
> main(int argc, char ** argv ){
> FILE *f = fopen("a", "r" ) ;
> fprintf(stderr,"f=%p\n",f);
> fclose(f);
> }
> $ file a
> a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses \
> shared libs), for GNU/Linux 2.6.32, \
> BuildID[sha1]=dfe043b4ec8cf19d5fd3fab524d7c72ed1453574, not stripped $ cat a.csh
> #!/bin/csh
> setenv LD_DEBUG all
> ./a >&! a.cpr
> $ ./a.csh
> $ grep -i open a.cpr
> 120584:     symbol=fopen;  lookup in file=./a [0]
> 120584:     symbol=fopen;  lookup in file=/lib64/libc.so.6 [0]
> 120584:     binding file ./a [0] to /lib64/libc.so.6 [0]: normal symbol `fopen' \
> [GLIBC_2.2.5] $
> 
> On 6/10/2016 7:29 AM, Ashley Pittman wrote:
> > On 22/05/16 02:56, John Bauer wrote:
> > > Oleg
> > > 
> > > I can intercept the fopen(), but that does me no good as I can't set the \
> > > O_LOV_DELAY_CREATE bit.  What I can not intercept is the open() downstream of \
> > > fopen().  If one examines the symbols in libc you will see there are no \
> > > unsatisfied externals relating to open, which means there is nothing for the \
> > > runtime linker to find concerning open's.  I will have a look at the Lustre 1.8 \
> > > source, but I seriously doubt that the open beneath fopen() was intercepted \
> > > with LD_PRELOAD.  I would love to find a way to do that.  I could throw away a \
> > > lot of code. Thanks,  John
> > 
> > Could you not intercept fopen() and implement it with calls to open() and \
> > fdopen() yourself which would give you full control over what you're looking for \
> > here? 
> > Ashley.
> 
> -- 
> I/O Doctors, LLC
> 507-766-0378
> 
> bauerj@iodoctors.com
> _______________________________________________
> lustre-devel mailing list
> lustre-devel@lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org

_______________________________________________
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org


[prev in list] [next in list] [prev in thread] [next in thread]