In the GNU coreutils project, there was a discussion about a new test which uses a destructor in an *.so file loaded into program space via LD_PRELOAD:
http://lists.gnu.org/archive/html/coreutils/2012-02/msg00173.html
However, the destructor is not run on OpenSuSE (nor on SLES10.x btw.), but works fine on other systems (e.g. Redhat).
This is Jim's commit: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b29db6767612cf70e9...
Attached is the relevant C code which intercepts the system calls getxattr() and lgetxattr(). The number of calls is counted and should be stored in a file "x" by the destructor print_call_count():
void __attribute__ ((destructor)) print_call_count (void);
Compile / link it:
$ gcc -fPIC -O2 -c k.c $ ld -G k.o -o k.so
Run it:
$ LD_PRELOAD=./k.so ls --color=always -l .
Now, the file "x" should be created, but it isn't.
(How) are LD_PRELOADed destructors disabled on SuSE?
Ah, yes - I'm running this:
$ head -n 1 /etc/SuSE-release openSUSE 12.1 (x86_64) $ gcc --version | head -n 1 gcc (SUSE Linux) 4.6.2 $ uname -rvmspio Linux 3.1.9-1.4-desktop #1 SMP PREEMPT Fri Jan 27 08:55:10 UTC 2012 (efb5ff4) x86_64 x86_64 x86_64 GNU/Linux
Have a nice day, Berny
El 27/02/12 09:53, Bernhard Voelker escribió:
In the GNU coreutils project, there was a discussion about a new test which uses a destructor in an *.so file loaded into program space via LD_PRELOAD:
http://lists.gnu.org/archive/html/coreutils/2012-02/msg00173.html
However, the destructor is not run on OpenSuSE (nor on SLES10.x btw.), but works fine on other systems (e.g. Redhat).
This is Jim's commit: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b29db6767612cf70e9...
Attached is the relevant C code which intercepts the system calls getxattr() and lgetxattr(). The number of calls is counted and should be stored in a file "x" by the destructor print_call_count():
void __attribute__ ((destructor)) print_call_count (void);
Compile / link it:
$ gcc -fPIC -O2 -c k.c $ ld -G k.o -o k.so
Works for me , I am in factory though.
El 27/02/12 13:24, Cristian Rodríguez escribió:
El 27/02/12 09:53, Bernhard Voelker escribió:
In the GNU coreutils project, there was a discussion about a new test which uses a destructor in an *.so file loaded into program space via LD_PRELOAD:
http://lists.gnu.org/archive/html/coreutils/2012-02/msg00173.html
However, the destructor is not run on OpenSuSE (nor on SLES10.x btw.), but works fine on other systems (e.g. Redhat).
This is Jim's commit: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b29db6767612cf70e9...
Attached is the relevant C code which intercepts the system calls getxattr() and lgetxattr(). The number of calls is counted and should be stored in a file "x" by the destructor print_call_count():
void __attribute__ ((destructor)) print_call_count (void);
Compile / link it:
$ gcc -fPIC -O2 -c k.c $ ld -G k.o -o k.so
Works for me , I am in factory though.
# gcc -shared -rdynamic -march=native -Wall -fPIC $(rpm --eval %optflags) k.c -o k.so
LD_PRELOAD="./k.so" ls --color=always -l .
cat x --> 74
On 02/27/2012 05:50 PM, Cristian Rodríguez wrote:
El 27/02/12 13:24, Cristian Rodríguez escribió:
El 27/02/12 09:53, Bernhard Voelker escribió:
void __attribute__ ((destructor)) print_call_count (void);
Compile / link it:
$ gcc -fPIC -O2 -c k.c $ ld -G k.o -o k.so
Works for me , I am in factory though.
# gcc -shared -rdynamic -march=native -Wall -fPIC $(rpm --eval %optflags) k.c -o k.so
LD_PRELOAD="./k.so" ls --color=always -l .
cat x --> 74
Hmm, you compiled+linked in one step. This works here, too:
gcc -shared -fPIC -O2 k.c -o k.so
Can you confirm the failure when compiling + linking is done in 2 separate steps?
Thank you & have a nice day, Berny
El 27/02/12 16:10, Bernhard Voelker escribió:
On 02/27/2012 05:50 PM, Cristian Rodríguez wrote:
El 27/02/12 13:24, Cristian Rodríguez escribió:
El 27/02/12 09:53, Bernhard Voelker escribió:
void __attribute__ ((destructor)) print_call_count (void);
Compile / link it:
$ gcc -fPIC -O2 -c k.c $ ld -G k.o -o k.so
Works for me , I am in factory though.
# gcc -shared -rdynamic -march=native -Wall -fPIC $(rpm --eval %optflags) k.c -o k.so
LD_PRELOAD="./k.so" ls --color=always -l .
cat x --> 74
Hmm, you compiled+linked in one step. This works here, too:
gcc -shared -fPIC -O2 k.c -o k.so
Can you confirm the failure when compiling + linking is done in 2 separate steps?
Well, I expected that to fail so didnt bothered.. You know.. distributions have a crapload of broken makefiles that link with LD directly. it fails in subtle ways when you do so, when using GCC, it passes the right options to the linker so we avoid nasty surprises...
On 02/27/2012 08:10 PM, Bernhard Voelker wrote:
On 02/27/2012 05:50 PM, Cristian Rodríguez wrote:
El 27/02/12 13:24, Cristian Rodríguez escribió:
El 27/02/12 09:53, Bernhard Voelker escribió:
void __attribute__ ((destructor)) print_call_count (void);
Compile / link it:
$ gcc -fPIC -O2 -c k.c $ ld -G k.o -o k.so
Works for me , I am in factory though.
# gcc -shared -rdynamic -march=native -Wall -fPIC $(rpm --eval %optflags) k.c -o k.so
LD_PRELOAD="./k.so" ls --color=always -l .
cat x --> 74
Hmm, you compiled+linked in one step. This works here, too:
gcc -shared -fPIC -O2 k.c -o k.so
Can you confirm the failure when compiling + linking is done in 2 separate steps?
It's not two separate steps that's the issue - it's using gcc vs. ld directly vs gcc -shared.
Try: gcc -fPIC -O2 -c k.c gcc -shared k.o -o k.os
This works fine for me...
Andreas
On 02/27/2012 09:49 PM, Andreas Jaeger wrote:
On 02/27/2012 08:10 PM, Bernhard Voelker wrote:
On 02/27/2012 05:50 PM, Cristian Rodríguez wrote:
El 27/02/12 13:24, Cristian Rodríguez escribió:
El 27/02/12 09:53, Bernhard Voelker escribió:
void __attribute__ ((destructor)) print_call_count (void);
Compile / link it:
$ gcc -fPIC -O2 -c k.c $ ld -G k.o -o k.so
Works for me , I am in factory though.
# gcc -shared -rdynamic -march=native -Wall -fPIC $(rpm --eval %optflags) k.c -o k.so
LD_PRELOAD="./k.so" ls --color=always -l .
cat x --> 74
Hmm, you compiled+linked in one step. This works here, too:
gcc -shared -fPIC -O2 k.c -o k.so
Can you confirm the failure when compiling + linking is done in 2 separate steps?
It's not two separate steps that's the issue - it's using gcc vs. ld directly vs gcc -shared.
Try: gcc -fPIC -O2 -c k.c gcc -shared k.o -o k.os
This works fine for me...
Andreas
Thank you ... and Cristian.
I've already sent a patch to the coreutils list: http://lists.gnu.org/archive/html/coreutils/2012-02/msg00179.html
Have a nice day, Berny
note
Thank you ... and Cristian.
you are welcome .. ;)
You have to compile AND link with gcc, ideally using the same flags *all the time*
In this case it was fairly easy to spot the problem, however I have seen some very hard to track misbehavior or linking errors..those WILL make you loose hair :-) so.. watch out ! .
Cheers.
On 02/27/2012 05:50 PM, Cristian Rodríguez wrote:
El 27/02/12 13:24, Cristian Rodríguez escribió:
El 27/02/12 09:53, Bernhard Voelker escribió:
In the GNU coreutils project, there was a discussion about a new test which uses a destructor in an *.so file loaded into program space via LD_PRELOAD:
http://lists.gnu.org/archive/html/coreutils/2012-02/msg00173.html
However, the destructor is not run on OpenSuSE (nor on SLES10.x btw.), but works fine on other systems (e.g. Redhat).
This is Jim's commit: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b29db6767612cf70e9...
Attached is the relevant C code which intercepts the system calls getxattr() and lgetxattr(). The number of calls is counted and should be stored in a file "x" by the destructor print_call_count():
void __attribute__ ((destructor)) print_call_count (void);
Compile / link it:
$ gcc -fPIC -O2 -c k.c $ ld -G k.o -o k.so
Works for me , I am in factory though.
# gcc -shared -rdynamic -march=native -Wall -fPIC $(rpm --eval %optflags) k.c -o k.so
LD_PRELOAD="./k.so" ls --color=always -l .
cat x --> 74
That works fine on 12.1 for me as well.
ld -G is just not the right way to build a shared library, you should really use gcc -shared,
Andreas
-
Andreas Jaeger -
Bernhard Voelker -
Cristian Rodríguez