All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: dlopen, gcc -l and LD_PRELOAD
@ 2013-03-20 16:00 Thibault, Daniel
  0 siblings, 0 replies; 9+ messages in thread
From: Thibault, Daniel @ 2013-03-20 16:00 UTC (permalink / raw)
  To: lttng-dev; +Cc: Painchaud, Frederic, Couture, Mario

> Message: 1
> Date: Tue, 19 Mar 2013 11:51:29 -0400
>
> >> I don't see this warning and error here. Which release are you using?
>>
> >    lttng-modules 2.1.1+ (74b9312, 2013-02-27)
> >    lttng-tools 2.1.1+ (e58727c, 2013-03-01)
> >    lttng-ust 2.1.1+ (009769c, 2013-03-05)
> >    userspace-rcu 0.7.6+ (108a92e, 2013-02-22)
> >
>
> I can confirm I'm able to reproduce the problem with these versions.
>
> >    (All are moderately dated by now, but none of the later commit 
> > comments seem pertinent)
>
> This revision fixed the "undefined symbol: tracepoint_dlopen" problem:
> https://bugs.lttng.org/projects/lttng-ust/repository/revisions/558b9d86247004f8e9bbaf8c982f3b2b182093d1

   Doh!  It had to be the revision right after the one I was using.

   Meanwhile I've been playing with some very simple examples of .so use, and found that the behaviour of LD_PRELOAD is incompletely documented.  For instance, if I run:

LD_LIBRARY_PATH=. ./sometest

   Where sometest is a simple application which uses a libwhatever.so built in the same directory, it works.  But:

LD_PRELOAD=./libwhatever.so ./sometest

   Fails with "No such file or directory".  LD_PRELOAD and LD_LIBRARY_PATH are NOT interchangeable.  The nitty-gritty (thanks to LD_DEBUG=libs) is as follows (my apologies if this is old-hat to fellow lttngeeks, but it was certainly new to me):

   Upon launching a process, the dynamic loader searches for the executable's requested libraries in the following ordered list of places, stopping as soon as a match is found:

. the rpath directory (or colon-separated directories) encoded in the executable, if any, but only if runpath is not also set (e.g. gcc -Wl,-rpath,'$ORIGIN/rpath' etc.) (instead of using the linker -rpath option, you can set LD_RUN_PATH before calling the linker);
. the (colon-separated) directories listed in the environment variable LD_LIBRARY_PATH, if any;
. the runpath directory (or colon-separated directories) encoded in the executable, if any (e.g. gcc -Wl,-rpath,'$ORIGIN/rpath',--enable-new-dtags etc.; although it is possible to modify the binary so rpath and runpath are different, gcc sets both values to the same string);
. the directories listed or included in /etc/ld.so.conf, if any;
. the trusted directory /lib; and finally
. the trusted directory /usr/lib.

   If the executable was linked with the -z nodeflib option ("no def lib"), then ld.so will not look in the last three locations for the requested shared library (that is to say, the search stops with the third bullet above).  The Linux /etc/ld.so.conf typically uses an explicit include instruction to add the collection of .conf files in the /etc/ld.so.conf.d directory.  The /etc/ld.so.conf.d files themselves are sorted alphabetically.  (I skip over /etc/ld.so.cache and the important role of the ldconfig command).  The found library is initialised, and then the dynamic loader checks in the following locations for the requested library:

. the libraries (not directories) listed in the environment variable LD_PRELOAD, if any (absolute or relative paths; LD_PRELOAD accepts colon- and/or space-separated entries); and
. the libraries (not directories) listed in the system file /etc/ld.so.preload, if any.

  If LD_PRELOAD or /etc/ld.so.preload supply a replacement library, the latter is initialised and its members pre-empt those from the previously found library.  Preloading thus serves to substitute replacements for some of the "normal" library methods.  Because full dynamicity (i.e. using dlopen to fetch the library) does not involve the dynamic loader, preloading does *not* work against it.  Also, if the requested library is not found in the "normal" places (rpath, LD_LIBRARY_PATH, runpath, /etc/ld.so.conf, /lib, /usr/lib) the dynamic loader issues an error ("cannot open shared object file: No such file or directory") and does *not* look into LD_PRELOAD and /etc/ld.so.preload.

   There are additional subtleties involving set-user-ID/set-group-ID binaries, but this is otherwise as complete as I can make it.

   The above should explain the trouble I've been having with lttng-ust's doc/examples/easy-ust and tests/demo.

Daniel U. Thibault
R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
Cyber sécurité pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
Protection des systèmes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
2459 route de la Bravoure
Québec, QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada / Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: dlopen, gcc -l and LD_PRELOAD
@ 2013-03-20 16:52 Thibault, Daniel
  0 siblings, 0 replies; 9+ messages in thread
From: Thibault, Daniel @ 2013-03-20 16:52 UTC (permalink / raw)
  To: Christian Babeux; +Cc: lttng-dev, Couture, Mario, Painchaud, Frederic

-----Message d'origine-----
Message: 6
Date: Wed, 20 Mar 2013 12:38:59 -0400

>    Meanwhile I've been playing with some very simple examples of .so use, and found that the behaviour of LD_PRELOAD is incompletely documented.  For instance, if I run:

Take a look at "man 8 ld.so". It should answer most of the questions you have about the dynamic linker libraries lookup mechanism.

>    The above should explain the trouble I've been having with lttng-ust's doc/examples/easy-ust and tests/demo.

Glad to see that you solved your issue!
------------------------------

   That's what I meant by incompletely documented.  The ld.so man pages don't mention rpath/runpath in the description, do not explain the LD_PRELOAD caveats, do not mention the nodeflib executable tag, and don't detail how the ld.so.conf inclusions are sorted.  The online version (http://man7.org/linux/man-pages/man8/ld.so.8.html) is much better (though still lacking a bit) and certainly more up to date (February 2013 vs. Ubuntu's May 2007 version!).

Daniel U. Thibault
R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
Cyber sécurité pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
Protection des systèmes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
2459 route de la Bravoure
Québec, QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada / Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: dlopen, gcc -l and LD_PRELOAD
       [not found] <48CF5AC71E61DB46B70D0F388054EFFD028AB5@VAL-E-01.valcartier.drdc-rddc.gc.ca>
@ 2013-03-20 16:38 ` Christian Babeux
  0 siblings, 0 replies; 9+ messages in thread
From: Christian Babeux @ 2013-03-20 16:38 UTC (permalink / raw)
  To: Thibault, Daniel; +Cc: lttng-dev, Couture, Mario, Painchaud, Frederic

Hi Daniel,

>    Meanwhile I've been playing with some very simple examples of .so use, and found that the behaviour of LD_PRELOAD is incompletely documented.  For instance, if I run:

Take a look at "man 8 ld.so". It should answer most of the questions
you have about the dynamic linker libraries lookup mechanism.

>    The above should explain the trouble I've been having with lttng-ust's doc/examples/easy-ust and tests/demo.

Glad to see that you solved your issue!

Thanks,

Christian

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: dlopen, gcc -l and LD_PRELOAD
       [not found]         ` <48CF5AC71E61DB46B70D0F388054EFFD028844@VAL-E-01.valcartier.drdc-rddc.gc.ca>
@ 2013-03-19 15:51           ` Jérémie Galarneau
  0 siblings, 0 replies; 9+ messages in thread
From: Jérémie Galarneau @ 2013-03-19 15:51 UTC (permalink / raw)
  To: Thibault, Daniel; +Cc: lttng-dev, Couture, Mario, Painchaud, Frederic

On Tue, Mar 19, 2013 at 10:03 AM, Thibault, Daniel
<Daniel.Thibault@drdc-rddc.gc.ca> wrote:
>> "I noticed that commit ID b834deadbfa8a78ae1d00440fd91c41dfd351eba changed README to remove a note suggesting that dlopen() not be used.  It looks like the same change should be made to doc/man/lttng-ust.3, which still suggests that you not use dlopen()."
>>
>> Just a reminder that it does appear to have been intended that that note be removed, so it should probably be disregarded.
>
>> You may want to have a look at the comment at
>> lttng-ust/include/lttng/tracepoint.h:229 which explains how this is accomplished. Basically, the tracepoint provider symbols are initialised and the probe is registered when the provider's shared object constructor is invoked. See ust-tracepoint-event.h:671 if you are interested in the actual implementation.
>
>> Have a look at the Makefiles and sources in lttng-ust/tests/demo and lttng-ust/tests/daemon which respectively demonstrate the use of tracepoint providers that are dynamically linked and built as part of the traced application.
>
>    The Makefile in lttng-ust/tests/demo is generated by automake and therefore horrendously large and complicated.  If there is a simple series of compile and link commands in there concerning the demo, that fish is thoroughly drowned.  I spotted one demo$(EXEXT) target which looked promising.  After oodles of substitutions and presuming six undefined variables were blank, it resolves to:
>
> demo : demo.o
>         @rm -f demo
>         @echo "  CCLD  " $@;/bin/bash ../../libtool --silent --tag=CC --mode=link gcc -Wall -g -02 -L/usr/local/lib -o $@ demo.o -ldl
>
> ...which isn't very enlightening (in the sense that it looks pretty plain).  There is in fact no trace of '.so' or '-fPIC' in the make.  What is needed is a pared-down makefile like the one in easy-ust.  I think I have figured out the correct outline, except for the tracepoint_dlopen problem.  But since the package's demo-trace runs smack into the same error, I'm suspecting the fault may not be mine.  Googling for this error turns up mostly cases where -shared was omitted from the lib*.so gcc call, resulting in pieces of static libraries being imported into dynamic ones.   This is not what's going on here.
>
>> > /usr/bin/ld: warning: hidden symbol 'tracepoint_dlopen' in sample.o is referenced by DSO ./libtp.so
>> >
>> > lttng-ust/tests/demo/demo-trace, although built by lttng-ust's make, also has the tracepoint_dlopen problem.  This now looks like a bug introduced somewhen since the demos were written (and last tested, it seems).
>>
>> I don't see this warning and error here. Which release are you using?
>
>    lttng-modules 2.1.1+ (74b9312, 2013-02-27)
>    lttng-tools 2.1.1+ (e58727c, 2013-03-01)
>    lttng-ust 2.1.1+ (009769c, 2013-03-05)
>    userspace-rcu 0.7.6+ (108a92e, 2013-02-22)
>

I can confirm I'm able to reproduce the problem with these versions.

>    (All are moderately dated by now, but none of the later commit comments seem pertinent)
>

This revision fixed the "undefined symbol: tracepoint_dlopen" problem:
https://bugs.lttng.org/projects/lttng-ust/repository/revisions/558b9d86247004f8e9bbaf8c982f3b2b182093d1

>   If I run lttng-ust/tests/demo/demo-trace, I get:
>
> ./demo: symbol lookup error: .libs/liblttng-ust-provider-ust-tests-demo3.so: undefined symbol: tracepoint_dlopen
>
>    All that demo-trace does is LD_PRELOAD .libs/liblttng-ust-provider-ust-tests-demo.so and .libs/liblttng-ust-provider-ust-tests-demo3.so before running ./demo
>
>    The make of lttng-ust, when it compiled demo.o, only warned that struct mmsghdr was declared inside a parameter list (/usr/include/x86_64-linux-gnu/bits/socket.h so it's not even an lttng problem).
>
>    Are you saying you can't reproduce this?  Your demo-trace runs and generates events?
>
>    Meanwhile I'll dive in and try to untangle what TRACEPOINT_PROBE_DYNAMIC_LINKAGE does.
>
> Daniel U. Thibault
> R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
> Cyber sécurité pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
> Protection des systèmes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
> 2459 route de la Bravoure
> Québec, QC  G3J 1X5
> CANADA
> Vox : (418) 844-4000 x4245
> Fax : (418) 844-4538
> NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
> Gouvernement du Canada / Government of Canada
> <http://www.valcartier.drdc-rddc.gc.ca/>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: dlopen, gcc -l and LD_PRELOAD
       [not found]       ` <20998D40D9A2B7499CA5A3A2666CB1EB23FCD7EF@ZURMSG1.QUANTUM.com>
@ 2013-03-19 14:03         ` Thibault, Daniel
       [not found]         ` <48CF5AC71E61DB46B70D0F388054EFFD028844@VAL-E-01.valcartier.drdc-rddc.gc.ca>
  1 sibling, 0 replies; 9+ messages in thread
From: Thibault, Daniel @ 2013-03-19 14:03 UTC (permalink / raw)
  To: David OShea, Jérémie Galarneau
  Cc: lttng-dev, Couture, Mario, Painchaud, Frederic

> "I noticed that commit ID b834deadbfa8a78ae1d00440fd91c41dfd351eba changed README to remove a note suggesting that dlopen() not be used.  It looks like the same change should be made to doc/man/lttng-ust.3, which still suggests that you not use dlopen()." 
>
> Just a reminder that it does appear to have been intended that that note be removed, so it should probably be disregarded.

> You may want to have a look at the comment at
> lttng-ust/include/lttng/tracepoint.h:229 which explains how this is accomplished. Basically, the tracepoint provider symbols are initialised and the probe is registered when the provider's shared object constructor is invoked. See ust-tracepoint-event.h:671 if you are interested in the actual implementation.

> Have a look at the Makefiles and sources in lttng-ust/tests/demo and lttng-ust/tests/daemon which respectively demonstrate the use of tracepoint providers that are dynamically linked and built as part of the traced application.

   The Makefile in lttng-ust/tests/demo is generated by automake and therefore horrendously large and complicated.  If there is a simple series of compile and link commands in there concerning the demo, that fish is thoroughly drowned.  I spotted one demo$(EXEXT) target which looked promising.  After oodles of substitutions and presuming six undefined variables were blank, it resolves to:

demo : demo.o
	@rm -f demo
	@echo "  CCLD  " $@;/bin/bash ../../libtool --silent --tag=CC --mode=link gcc -Wall -g -02 -L/usr/local/lib -o $@ demo.o -ldl

...which isn't very enlightening (in the sense that it looks pretty plain).  There is in fact no trace of '.so' or '-fPIC' in the make.  What is needed is a pared-down makefile like the one in easy-ust.  I think I have figured out the correct outline, except for the tracepoint_dlopen problem.  But since the package's demo-trace runs smack into the same error, I'm suspecting the fault may not be mine.  Googling for this error turns up mostly cases where -shared was omitted from the lib*.so gcc call, resulting in pieces of static libraries being imported into dynamic ones.   This is not what's going on here.

> > /usr/bin/ld: warning: hidden symbol 'tracepoint_dlopen' in sample.o is referenced by DSO ./libtp.so
> >
> > lttng-ust/tests/demo/demo-trace, although built by lttng-ust's make, also has the tracepoint_dlopen problem.  This now looks like a bug introduced somewhen since the demos were written (and last tested, it seems).
>
> I don't see this warning and error here. Which release are you using?

   lttng-modules 2.1.1+ (74b9312, 2013-02-27)
   lttng-tools 2.1.1+ (e58727c, 2013-03-01)
   lttng-ust 2.1.1+ (009769c, 2013-03-05)
   userspace-rcu 0.7.6+ (108a92e, 2013-02-22)

   (All are moderately dated by now, but none of the later commit comments seem pertinent)

  If I run lttng-ust/tests/demo/demo-trace, I get:

./demo: symbol lookup error: .libs/liblttng-ust-provider-ust-tests-demo3.so: undefined symbol: tracepoint_dlopen

   All that demo-trace does is LD_PRELOAD .libs/liblttng-ust-provider-ust-tests-demo.so and .libs/liblttng-ust-provider-ust-tests-demo3.so before running ./demo

   The make of lttng-ust, when it compiled demo.o, only warned that struct mmsghdr was declared inside a parameter list (/usr/include/x86_64-linux-gnu/bits/socket.h so it's not even an lttng problem).

   Are you saying you can't reproduce this?  Your demo-trace runs and generates events?

   Meanwhile I'll dive in and try to untangle what TRACEPOINT_PROBE_DYNAMIC_LINKAGE does.

Daniel U. Thibault
R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
Cyber sécurité pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
Protection des systèmes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
2459 route de la Bravoure
Québec, QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada / Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: dlopen, gcc -l and LD_PRELOAD
       [not found]     ` <CA+jJMxvD+g9kPeeqP5hbELOk40qMwD-+UBfMUVNRQfypXk_ycw@mail.gmail.com>
@ 2013-03-19  4:54       ` David OShea
       [not found]       ` <20998D40D9A2B7499CA5A3A2666CB1EB23FCD7EF@ZURMSG1.QUANTUM.com>
  1 sibling, 0 replies; 9+ messages in thread
From: David OShea @ 2013-03-19  4:54 UTC (permalink / raw)
  To: Jérémie Galarneau, Thibault, Daniel; +Cc: lttng-dev

Hi all,

> -----Original Message-----
> From: Jérémie Galarneau [mailto:jeremie.galarneau@efficios.com]
> Sent: Tuesday, 19 March 2013 7:28 AM
> To: Thibault, Daniel
> Cc: lttng-dev@lists.lttng.org
> Subject: Re: [lttng-dev] dlopen, gcc -l and LD_PRELOAD


> > Good question. I think this problem has been fixed as part of the 2.1
> release. However, I do know there are other issues related to
> "dlopen()"-ing probe providers; details on the bug tracker[1].
> >
> > Jérémie
> > [1] https://bugs.lttng.org/issues/447
> > -----Fin du message d'origine-----
> >
> >    Bug 447 concerns dlclose(), not dlopen().  It's a legitimate
> concern (that has yet to be addressed, it seems), but it has nothing to
> do with potential delays or deadlocks upon calling dlopen() on a
> tracepoint provider.

[...]

> Typically, you would want to do one or the other [dlopen or
> LD_PRELOAD]. But to answer your question, yes, this would workaround
> the locking problem described in the man page that affected prior
> versions of lttng-ust (before 2.1).

FYI I mentioned my email to this list dated 25/Feb/2013 that:

"I noticed that commit ID b834deadbfa8a78ae1d00440fd91c41dfd351eba changed README to remove a note suggesting that dlopen() not be used.  It looks like the same change should be made to doc/man/lttng-ust.3, which still suggests that you not use dlopen()."

Just a reminder that it does appear to have been intended that that note be removed, so it should probably be disregarded.

Also, if anyone is able to provide explanations for the questions in my previous email, that might serve to address the topic of this thread too.

Thanks,
David

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: dlopen, gcc -l and LD_PRELOAD
       [not found]   ` <48CF5AC71E61DB46B70D0F388054EFFD028674@VAL-E-01.valcartier.drdc-rddc.gc.ca>
@ 2013-03-18 20:58     ` Jérémie Galarneau
       [not found]     ` <CA+jJMxvD+g9kPeeqP5hbELOk40qMwD-+UBfMUVNRQfypXk_ycw@mail.gmail.com>
  1 sibling, 0 replies; 9+ messages in thread
From: Jérémie Galarneau @ 2013-03-18 20:58 UTC (permalink / raw)
  To: Thibault, Daniel; +Cc: lttng-dev

On Mon, Mar 18, 2013 at 3:07 PM, Thibault, Daniel
<Daniel.Thibault@drdc-rddc.gc.ca> wrote:
> -----Message d'origine-----
> Envoyé : 15 mars 2013 15:33
>
> On Fri, Mar 15, 2013 at 12:41 PM, Thibault, Daniel <Daniel.Thibault@drdc-rddc.gc.ca> wrote:
>>    In the lttng-ust man pages, there is a paragraph that reads:
>>
>> Note about dlopen() usage: Due to locking side-effects caused by the way libc lazily resolves Thread-Local Storage (TLS) symbols when a library is dlopened, linking the tracepoint probe or liblttng-ust with dlopen() is discouraged.  They should be linked with the application using "-llibname" or loaded with LD_PRELOAD.
>>
>>    I'm confused by the LD_PRELOAD bit: as far as I know, LD_PRELOAD serves only to substitute a dynamic library (the LD_PRELOAD argument) for another (the one the executable was linked against).  I don't see how one could compile an instrumented application and leave its tracepoint provider unlinked, which is what the stated -llibname <-> LD_PRELOAD opposition implies.
>>
>
> You may want to have a look at the comment at
> lttng-ust/include/lttng/tracepoint.h:229 which explains how this is accomplished. Basically, the tracepoint provider symbols are initialised and the probe is registered when the provider's shared object constructor is invoked. See ust-tracepoint-event.h:671 if you are interested in the actual implementation.
>
>>    (Also, shouldn't that paragraph drop 'lazily', assuming the locking
>> problems also arise if dlopen is used with RTLD_NOW?  Because if
>> RTLD_NOW fixed the locking problem, that's what would be recommended
>> here, no?)
>
> Good question. I think this problem has been fixed as part of the 2.1 release. However, I do know there are other issues related to "dlopen()"-ing probe providers; details on the bug tracker[1].
>
> Jérémie
> [1] https://bugs.lttng.org/issues/447
> -----Fin du message d'origine-----
>
>    Bug 447 concerns dlclose(), not dlopen().  It's a legitimate concern (that has yet to be addressed, it seems), but it has nothing to do with potential delays or deadlocks upon calling dlopen() on a tracepoint provider.
>

Indeed, hence why I have mentioned there were _other_ potential issues
with the dynamic linking loader interface of which you should be aware
before using it to load the providers.

>    I'm not concerned with how the tracepoint provider initialises its symbols and registers its probe(s) with the session daemons when its constructor is invoked, I'm just trying to figure out what "They [the tracepoint provider and liblttng-ust] should be linked with the application using '-llibname' or loaded with LD_PRELOAD" means.  The first part of the (apparently exclusive) or clearly refers to implementing the tracepoint provider as an .so but making the instrumented application statically aware of it (I'm dubious anyone would try to use liblttng-ust through dlopen(), though).  Is the second part saying that if the app explicitly loads the tracepoint provider .so through dlopen(), setting LD_PRELOAD when calling the app will fix (circumvent) the locking problems?
>

Typically, you would want to do one or the other [dlopen or
LD_PRELOAD]. But to answer your question, yes, this would workaround
the locking problem described in the man page that affected prior
versions of lttng-ust (before 2.1).

>    For that matter, I have yet to successfully divine what a tracepoint provider .so makefile should look like (the lttng-ust man pages don't give an understandable example, and my experience with dynamic libraries has mostly been under Windows).  If you could provide one, I'd be grateful.  Here's as far as I've got, using lttng-ust/doc/example/easy-ust:
>

Have a look at the Makefiles and sources in lttng-ust/tests/demo and
lttng-ust/tests/daemon which respectively demonstrate the use of
tracepoint providers that are dynamically linked and built as part of
the traced application.

> The normal Makefile:
>
> CC = gcc
> LIBS = -ldl -llttng-ust         # On Linux
> #LIBS = -lc -llttng-ust         # On BSD
> CFLAGS = -I.
> LDFLAGS = -L/usr/local/lib
>
> all: sample
>
> sample: sample.o tp.o
>         $(CC) -o $@ $^ $(LDFLAGS) $(LIBS)
>
> sample.o: sample.c sample_component_provider.h
>         $(CC) $(CFLAGS) -c -o $@ $(LDFLAGS) $<
>
> tp.o: tp.c sample_component_provider.h
>         $(CC) $(CFLAGS) -c -o $@ $(LDFLAGS) $<
> [...]
>
> Yields:
> gcc -I. -c -o sample.o -L/usr/local/lib sample.c
> gcc -I. -c -o tp.o -L/usr/local/lib tp.c
> gcc -o sample sample.o tp.o -L/usr/local/lib -ldl -llttng-ust
>
> I can make sample using a static library instead, by changing the Makefile thus:
>
> AR = ar
> CC = gcc
> [...]
> sample: sample.o libtp.a
>         $(CC) -o $@ $^ $(LDFLAGS) -L. $(LIBS)
>
> sample.o: sample.c sample_component_provider.h
>         $(CC) $(CFLAGS) -c -o $@ $(LDFLAGS) $<
>
> libtp.a: tp.o
>         $(AR) -cq $@ $<
>
> tp.o: tp.c sample_component_provider.h
>         $(CC) $(CFLAGS) -c -o $@ $(LDFLAGS) $<
> [...]
>
> Which yields:
> gcc -I. -c -o sample.o -L/usr/local/lib sample.c
> gcc -I. -c -o tp.o -L/usr/local/lib tp.c
> ar -cq libtp.a tp.o
> gcc -o sample sample.o libtp.a -L/usr/local/lib -L. -ldl -llttng-ust
>
> In switching to a statically aware dynamic library, I first modify sample.c by adding '#define TRACEPOINT_PROBE_DYNAMIC_LINKAGE' right after '#define TRACEPOINT_DEFINE'.
>
> Then I've tried to use this Makefile:
>
> CC = gcc
> LIBS = -ldl -llttng-ust         # On Linux
> #LIBS = -lc -llttng-ust         # On BSD
> CFLAGS = -I.
> SOFLAGS = -fPIC
> SOVERSION_MAJOR = 1
> SOVERSION_MINOR = 0
> LDFLAGS = -L/usr/local/lib
>
> all: libtp.so sample
>
> sample: sample.o
>         $(CC) -o $@ $< $(LDFLAGS) $(LIBS) -L. -ltp
>
> sample.o: sample_so.c sample_component_provider.h
>         $(CC) $(CFLAGS) -c -o $@ $(LDFLAGS) $(LIBS) -L. -ltp $<
>
> libtp.so: tp.o
>         $(CC) -shared -W1,-soname,$@.$(SOVERSION_MAJOR) -o $@.$(SOVERSION_MAJOR).$(SOVERSION_MINOR) $(LDFLAGS) $(LIBS) $<
>         ln -sf $@.$(SOVERSION_MAJOR).$(SOVERSION_MINOR) $@.$(SOVERSION_MAJOR)
>         ln -sf $@.$(SOVERSION_MAJOR) $@
>
> tp.o: tp.c sample_component_provider.h
>         $(CC) $(CFLAGS) $(SOFLAGS) $(LDFLAGS) $(LIBS) -c -o $@ $<
>
> Which yields:
> gcc -I. -fPIC -L/usr/local/lib -ldl -llttng-ust -c -o tp.o tp.c
> gcc -shared -W1,-soname,libtp.so.1 -o libtp.so.1.0 -L/usr/local/lib -ldl -llttng-ust tp.o
> ln -sf libtp.so.1.0 libtp.so.1
> ln -sf libtp.so.1 libtp.so
> gcc -I. -c -o sample.o -L/usr/local/lib -ldl -llttng-ust -L. -ltp sample.c
> gcc -o sample sample.o -L/usr/local/lib -ldl -llttng-ust -L. -ltp
> /usr/bin/ld: warning: hidden symbol 'tracepoint_dlopen' in sample.o is referenced by DSO ./libtp.so
>
>    I've tried a number of things to get rid of the warning.  For some reason the 'tracepoint_dlopen' struct symbol in tp.o gets linked (when building 'sample' in the last step) to the one in sample.o (which has the same source: the sample_component_provider.h) instead of the one in liblttng-ust.  If I try a command like 'LD_PRELOAD=./libtp.so ./sample', I get "symbol lookup error: ./libtp.so: undefined symbol: tracepoint_dlopen".
>
>    I'm sure this is a very simple, obvious, dumb mistake, so please point it out to me!
>
> lttng-ust/tests/demo/demo-trace, although built by lttng-ust's make, also has the tracepoint_dlopen problem.  This now looks like a bug introduced somewhen since the demos were written (and last tested, it seems).

I don't see this warning and error here. Which release are you using?

> Daniel U. Thibault
> R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
> Cyber sécurité pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
> Protection des systèmes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
> 2459 route de la Bravoure
> Québec, QC  G3J 1X5
> CANADA
> Vox : (418) 844-4000 x4245
> Fax : (418) 844-4538
> NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
> Gouvernement du Canada / Government of Canada
> <http://www.valcartier.drdc-rddc.gc.ca/>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: dlopen, gcc -l and LD_PRELOAD
       [not found] <48CF5AC71E61DB46B70D0F388054EFFD027A2C@VAL-E-01.valcartier.drdc-rddc.gc.ca>
@ 2013-03-15 19:33 ` Jérémie Galarneau
       [not found] ` <CA+jJMxvm5=mms0BwFtDEy8CKuYOM08K7EYCddKWoRY2VSbxV1Q@mail.gmail.com>
  1 sibling, 0 replies; 9+ messages in thread
From: Jérémie Galarneau @ 2013-03-15 19:33 UTC (permalink / raw)
  To: Thibault, Daniel; +Cc: lttng-dev

On Fri, Mar 15, 2013 at 12:41 PM, Thibault, Daniel
<Daniel.Thibault@drdc-rddc.gc.ca> wrote:
>    In the lttng-ust man pages, there is a paragraph that reads:
>
> Note about dlopen() usage: Due to locking side-effects caused by the way libc lazily resolves Thread-Local Storage (TLS) symbols when a library is dlopened, linking the tracepoint probe or liblttng-ust with dlopen() is discouraged.  They should be linked with the application using "-llibname" or loaded with LD_PRELOAD.
>
>    I'm confused by the LD_PRELOAD bit: as far as I know, LD_PRELOAD serves only to substitute a dynamic library (the LD_PRELOAD argument) for another (the one the executable was linked against).  I don't see how one could compile an instrumented application and leave its tracepoint provider unlinked, which is what the stated -llibname <-> LD_PRELOAD opposition implies.
>

You may want to have a look at the comment at
lttng-ust/include/lttng/tracepoint.h:229 which explains how this is
accomplished. Basically, the tracepoint provider symbols are
initialised and the probe is registered when the provider's shared
object constructor is invoked. See ust-tracepoint-event.h:671 if you
are interested in the actual implementation.

>    (Also, shouldn't that paragraph drop 'lazily', assuming the locking problems also arise if dlopen is used with RTLD_NOW?  Because if RTLD_NOW fixed the locking problem, that's what would be recommended here, no?)

Good question. I think this problem has been fixed as part of the 2.1
release. However, I do know there are other issues related to
"dlopen()"-ing probe providers; details on the bug tracker[1].

Jérémie
[1] https://bugs.lttng.org/issues/447

>
> Daniel U. Thibault
> R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
> Cyber sécurité pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
> Protection des systèmes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
> 2459 route de la Bravoure
> Québec, QC  G3J 1X5
> CANADA
> Vox : (418) 844-4000 x4245
> Fax : (418) 844-4538
> NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
> Gouvernement du Canada / Government of Canada
> <http://www.valcartier.drdc-rddc.gc.ca/>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

^ permalink raw reply	[flat|nested] 9+ messages in thread

* dlopen, gcc -l and LD_PRELOAD
@ 2013-03-15 16:41 Thibault, Daniel
  0 siblings, 0 replies; 9+ messages in thread
From: Thibault, Daniel @ 2013-03-15 16:41 UTC (permalink / raw)
  To: lttng-dev; +Cc: Painchaud, Frederic, Couture, Mario

   In the lttng-ust man pages, there is a paragraph that reads:

Note about dlopen() usage: Due to locking side-effects caused by the way libc lazily resolves Thread-Local Storage (TLS) symbols when a library is dlopened, linking the tracepoint probe or liblttng-ust with dlopen() is discouraged.  They should be linked with the application using "-llibname" or loaded with LD_PRELOAD.

   I'm confused by the LD_PRELOAD bit: as far as I know, LD_PRELOAD serves only to substitute a dynamic library (the LD_PRELOAD argument) for another (the one the executable was linked against).  I don't see how one could compile an instrumented application and leave its tracepoint provider unlinked, which is what the stated -llibname <-> LD_PRELOAD opposition implies.

   (Also, shouldn't that paragraph drop 'lazily', assuming the locking problems also arise if dlopen is used with RTLD_NOW?  Because if RTLD_NOW fixed the locking problem, that's what would be recommended here, no?)

Daniel U. Thibault
R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
Cyber sécurité pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
Protection des systèmes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
2459 route de la Bravoure
Québec, QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada / Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2013-03-20 16:53 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-20 16:00 dlopen, gcc -l and LD_PRELOAD Thibault, Daniel
  -- strict thread matches above, loose matches on Subject: below --
2013-03-20 16:52 Thibault, Daniel
     [not found] <48CF5AC71E61DB46B70D0F388054EFFD028AB5@VAL-E-01.valcartier.drdc-rddc.gc.ca>
2013-03-20 16:38 ` Christian Babeux
     [not found] <48CF5AC71E61DB46B70D0F388054EFFD027A2C@VAL-E-01.valcartier.drdc-rddc.gc.ca>
2013-03-15 19:33 ` Jérémie Galarneau
     [not found] ` <CA+jJMxvm5=mms0BwFtDEy8CKuYOM08K7EYCddKWoRY2VSbxV1Q@mail.gmail.com>
     [not found]   ` <48CF5AC71E61DB46B70D0F388054EFFD028674@VAL-E-01.valcartier.drdc-rddc.gc.ca>
2013-03-18 20:58     ` Jérémie Galarneau
     [not found]     ` <CA+jJMxvD+g9kPeeqP5hbELOk40qMwD-+UBfMUVNRQfypXk_ycw@mail.gmail.com>
2013-03-19  4:54       ` David OShea
     [not found]       ` <20998D40D9A2B7499CA5A3A2666CB1EB23FCD7EF@ZURMSG1.QUANTUM.com>
2013-03-19 14:03         ` Thibault, Daniel
     [not found]         ` <48CF5AC71E61DB46B70D0F388054EFFD028844@VAL-E-01.valcartier.drdc-rddc.gc.ca>
2013-03-19 15:51           ` Jérémie Galarneau
2013-03-15 16:41 Thibault, Daniel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.