From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers via lttng-dev Subject: Re: [PATCH lttng-ust] Add ctor/dtor priorities for tracepoints/events Date: Mon, 13 Jul 2020 14:58:48 -0400 (EDT) Message-ID: <1150223945.10384.1594666728119.JavaMail.zimbra@efficios.com> References: <20200711152907.676582-1-olivier.dion@polymtl.ca> <756801034.9565.1594561774215.JavaMail.zimbra@efficios.com> <87tuycybqx.fsf@clara> <1851244021.9798.1594646692671.JavaMail.zimbra@efficios.com> <87r1tfxx1l.fsf@clara> <2029726158.10046.1594654110710.JavaMail.zimbra@efficios.com> <87lfjnxngn.fsf@clara> Reply-To: Mathieu Desnoyers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by lists.lttng.org (Postfix) with ESMTPS id 4B5Cby5shtz1W3R for ; Mon, 13 Jul 2020 14:58:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 864332A4C14 for ; Mon, 13 Jul 2020 14:58:48 -0400 (EDT) In-Reply-To: <87lfjnxngn.fsf@clara> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" To: Olivier Dion Cc: lttng-dev List-Id: lttng-dev@lists.lttng.org ----- On Jul 13, 2020, at 2:46 PM, Olivier Dion olivier.dion@polymtl.ca wrote: > On Mon, 13 Jul 2020, Mathieu Desnoyers wrote: >> ----- On Jul 13, 2020, at 11:19 AM, Olivier Dion olivier.dion@polymtl.ca wrote: >> >>> On Mon, 13 Jul 2020, Mathieu Desnoyers wrote: >> [...] >>> >>>>>> Also, we should compare two approaches to fulfill your goal: >>>>>> one alternative would be to have application/library constructors >>>>>> explicitly call tracepoint constructors if they wish to use them. >>>>> >>>>> I would prefer this way. The former solution might not work in some >>>>> cases (e.g. with LD_PRELOAD and priority =101) and I prefer explicit >>>>> initialization in that case. >>>>> >>>>> I don't see any cons for the second approach, except making the symbols >>>>> table a few bytes larger. I'll post a patch soon so we can compare and >>>>> try to find more documentation on ctor priority. >>>> >>>> And users will have to explicitly call the constructor on which they >>>> depend, but I don't see it as a huge burden. >>> >>> The burden is small indeed. But users should pay close attention to >>> release the references in a destructor too. >>> >>>> Beware though that there are a few configurations which can be used for >>>> probe providers (see lttng-ust(3)). >>> >>> I'm not following you here. I don't see any configuration for provider >>> except TRACEPOINT_LOGLEVEL. What should I be aware of? >> >> See sections "Statically linking the tracepoint provider" and >> "Dynamically loading the tracepoint provider" from lttng-ust(3). It's >> especially the dynamic loading I am concerned about, because then it >> becomes tricky for an instrumented .so (or app) to call the probe provider's >> constructor without dlopening it beforehand, because there are no dependencies >> from the instrumented module on probe symbols. And given you plan to call >> this from a constructor, it means the dynamic loader lock is already held, >> so even if we dlopen the probe provider from the instrumented constructor, >> I am not sure the dlopen'd .so's constructor will be allowed to run >> immediately. >> >> Maybe one thing that could work for the dynamic loading case would be to: >> >> - let the instrumented constructor dlopen its probe, >> - from the instrumented constructor, use dlsym to get the probe's constructor >> symbols. >> - call those constructors. >> >> If this is common enough, maybe we would want to provide helpers for >> this. > > Okay so to be clear. __tracepoints__init() should be call first, then > __tracepoints__ptrs_init() I don't think the order matters. What makes you think otherwise ? > and then dlsym(3) on > __lttng_events_init__provider() _if_ TRACEPOINT_PROBE_DYNAMIC_LINKAGE. Yes. > > Reverse the steps in destructor. > > And so would something along these lines work? > -------------------------------------------------------------------------------- > #ifdef TRACEPOINT_PROBE_DYNAMIC_LINKAGE > > # define tracepoint_acquire(provider) \ > do { \ > void (*init)(void); \ > __tracepoints__init(); \ > __tracepoints__ptrs_init(); \ Where is the dlopen() done ? What code is responsible for it ? > init = dlsym(RTLD_DEFAULT, \ This should use the handled returned by dlopen. > "__lttng_events_init__" #provider); \ > if (init) { \ > init(); \ > } \ > } while(0) > We may want a dlclose on the release (?) > #else > > # define tracepoint_acquire(provider) \ > do { \ > __tracepoint__init(); \ > __tracepoints_ptrs_init(); \ > _TP_COMBINE_TOKENS(__lttng_events_init__, provider)(); \ > } while(0) > > #endif > -------------------------------------------------------------------------------- > > And then: > ---------------------------------------------------------------------- > #include "my-trace.h" > > __attribute__((constructor)) > static void my_ctor(void) > { > tracepoint_acquire(my_provider); > tracepoint(my_provider, my_event, my_state); > } > > __attribute__((destructor)) > static void my_ctor(void) > { > tracepoint_release(my_provider) > } > ---------------------------------------------------------------------- > > Of course, this requires making __tracepoints__* externally visibile. Why is that so ? Thanks, Mathieu > > -- > Olivier Dion > PolyMtl -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64060C433E2 for ; Mon, 13 Jul 2020 18:58:58 +0000 (UTC) Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F23BF2067D for ; Mon, 13 Jul 2020 18:58:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.lttng.org header.i=@lists.lttng.org header.b="nwisyeXA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F23BF2067D Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=lists.lttng.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lttng-dev-bounces@lists.lttng.org Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4B5Cc03gQyz1Vs1; Mon, 13 Jul 2020 14:58:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1594666737; bh=TJlmG+aqEb+bpVffeKQ+aYeSY/KSjBfavWFzjyVAJJk=; h=Date:To:Cc:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=nwisyeXA9fPhmFYh76lFwi1HlAwZkleTW1KPSFMeM/CZ5nh5MrAjx7k2SFo48ZL5E HujOBg5OxxurH+VDCGTTE+u/KaC/l7qRiiCHM0A4q2ra5L/vnNNYwLTqFw0GXCeiZO YsXHKMlYJS0MoV9iMSs7j7m1MP0R0dYuTpM+LaKW3p+/7uhC4R02URUUfjeIYZOEWQ fEaYcS5YuPsJVMuJ7DCVKOBSPtxwJ5GjNY/2eJwDwD/MeJ2iZP9B9aadLcUkMKB851 /dvKP83zn5sZp+YPkuhtLaTzm6FkiZfWg7VkCUpykWOH5BZewtvMc9+lYsbswGd4rw KrjHy6NB577EQ== Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by lists.lttng.org (Postfix) with ESMTPS id 4B5Cby5shtz1W3R for ; Mon, 13 Jul 2020 14:58:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 864332A4C14 for ; Mon, 13 Jul 2020 14:58:48 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fnZLE6WyLjAy; Mon, 13 Jul 2020 14:58:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 3B6A02A4A46; Mon, 13 Jul 2020 14:58:48 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 3B6A02A4A46 X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HVexSs5or-ZW; Mon, 13 Jul 2020 14:58:48 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 329E92A495A; Mon, 13 Jul 2020 14:58:48 -0400 (EDT) Date: Mon, 13 Jul 2020 14:58:48 -0400 (EDT) To: Olivier Dion Cc: lttng-dev Message-ID: <1150223945.10384.1594666728119.JavaMail.zimbra@efficios.com> In-Reply-To: <87lfjnxngn.fsf@clara> References: <20200711152907.676582-1-olivier.dion@polymtl.ca> <756801034.9565.1594561774215.JavaMail.zimbra@efficios.com> <87tuycybqx.fsf@clara> <1851244021.9798.1594646692671.JavaMail.zimbra@efficios.com> <87r1tfxx1l.fsf@clara> <2029726158.10046.1594654110710.JavaMail.zimbra@efficios.com> <87lfjnxngn.fsf@clara> MIME-Version: 1.0 X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3955 (ZimbraWebClient - FF78 (Linux)/8.8.15_GA_3953) Thread-Topic: Add ctor/dtor priorities for tracepoints/events Thread-Index: rs9ng3DDVWNuaJvIu8mIwswUvRZmBg== Subject: Re: [lttng-dev] [PATCH lttng-ust] Add ctor/dtor priorities for tracepoints/events X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.31 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mathieu Desnoyers via lttng-dev Reply-To: Mathieu Desnoyers Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" Message-ID: <20200713185848.45tDIb_g2QUkUbZRbhGpMt1yffvrNGqc9FDMFtEjfYM@z> ----- On Jul 13, 2020, at 2:46 PM, Olivier Dion olivier.dion@polymtl.ca wrote: > On Mon, 13 Jul 2020, Mathieu Desnoyers wrote: >> ----- On Jul 13, 2020, at 11:19 AM, Olivier Dion olivier.dion@polymtl.ca wrote: >> >>> On Mon, 13 Jul 2020, Mathieu Desnoyers wrote: >> [...] >>> >>>>>> Also, we should compare two approaches to fulfill your goal: >>>>>> one alternative would be to have application/library constructors >>>>>> explicitly call tracepoint constructors if they wish to use them. >>>>> >>>>> I would prefer this way. The former solution might not work in some >>>>> cases (e.g. with LD_PRELOAD and priority =101) and I prefer explicit >>>>> initialization in that case. >>>>> >>>>> I don't see any cons for the second approach, except making the symbols >>>>> table a few bytes larger. I'll post a patch soon so we can compare and >>>>> try to find more documentation on ctor priority. >>>> >>>> And users will have to explicitly call the constructor on which they >>>> depend, but I don't see it as a huge burden. >>> >>> The burden is small indeed. But users should pay close attention to >>> release the references in a destructor too. >>> >>>> Beware though that there are a few configurations which can be used for >>>> probe providers (see lttng-ust(3)). >>> >>> I'm not following you here. I don't see any configuration for provider >>> except TRACEPOINT_LOGLEVEL. What should I be aware of? >> >> See sections "Statically linking the tracepoint provider" and >> "Dynamically loading the tracepoint provider" from lttng-ust(3). It's >> especially the dynamic loading I am concerned about, because then it >> becomes tricky for an instrumented .so (or app) to call the probe provider's >> constructor without dlopening it beforehand, because there are no dependencies >> from the instrumented module on probe symbols. And given you plan to call >> this from a constructor, it means the dynamic loader lock is already held, >> so even if we dlopen the probe provider from the instrumented constructor, >> I am not sure the dlopen'd .so's constructor will be allowed to run >> immediately. >> >> Maybe one thing that could work for the dynamic loading case would be to: >> >> - let the instrumented constructor dlopen its probe, >> - from the instrumented constructor, use dlsym to get the probe's constructor >> symbols. >> - call those constructors. >> >> If this is common enough, maybe we would want to provide helpers for >> this. > > Okay so to be clear. __tracepoints__init() should be call first, then > __tracepoints__ptrs_init() I don't think the order matters. What makes you think otherwise ? > and then dlsym(3) on > __lttng_events_init__provider() _if_ TRACEPOINT_PROBE_DYNAMIC_LINKAGE. Yes. > > Reverse the steps in destructor. > > And so would something along these lines work? > -------------------------------------------------------------------------------- > #ifdef TRACEPOINT_PROBE_DYNAMIC_LINKAGE > > # define tracepoint_acquire(provider) \ > do { \ > void (*init)(void); \ > __tracepoints__init(); \ > __tracepoints__ptrs_init(); \ Where is the dlopen() done ? What code is responsible for it ? > init = dlsym(RTLD_DEFAULT, \ This should use the handled returned by dlopen. > "__lttng_events_init__" #provider); \ > if (init) { \ > init(); \ > } \ > } while(0) > We may want a dlclose on the release (?) > #else > > # define tracepoint_acquire(provider) \ > do { \ > __tracepoint__init(); \ > __tracepoints_ptrs_init(); \ > _TP_COMBINE_TOKENS(__lttng_events_init__, provider)(); \ > } while(0) > > #endif > -------------------------------------------------------------------------------- > > And then: > ---------------------------------------------------------------------- > #include "my-trace.h" > > __attribute__((constructor)) > static void my_ctor(void) > { > tracepoint_acquire(my_provider); > tracepoint(my_provider, my_event, my_state); > } > > __attribute__((destructor)) > static void my_ctor(void) > { > tracepoint_release(my_provider) > } > ---------------------------------------------------------------------- > > Of course, this requires making __tracepoints__* externally visibile. Why is that so ? Thanks, Mathieu > > -- > Olivier Dion > PolyMtl -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev