From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id s8X6A0Ua8GAXSwAAWB0awg (envelope-from ) for ; Thu, 15 Jul 2021 07:21:41 -0400 Received: by simark.ca (Postfix, from userid 112) id 0118F1EDF0; Thu, 15 Jul 2021 07:21:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_REPLYTO_END_DIGIT,MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 171D01E54D for ; Thu, 15 Jul 2021 07:21:40 -0400 (EDT) Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4GQX4z31JQz12Hl; Thu, 15 Jul 2021 07:21:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1626348099; bh=BJARxsIKL3jdsdygeOJ4QYP33UaqzZqkTd8eT08Lzus=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=EmQUWY8ltwjT6AQOlRnbdax2cF29SC0j1B+EvuBy/buJ4YRcuw4tBaYOcBD4861/l kCMTViCCPMPr8vs10wkaKVGMF1dcco7/+Y3KSB9PsdwuBPTMYKcE4EzBqO+qhL+uLE YD7f6eG3qDABTi1t6d141w0alm3XClL0J/yR+Z63wjqokOxD25YGhjpDozKFlq+Im3 NnSj1l6iKYw7mfz95yB3vNV/9mR9CY4L3ApEKFDKHOJzXHbsj06koLAxEerwQGAZ/P IRP5DvR2ZP0TxWxbf5VroVnSfSBWSki9hVjVNM6mQPcZBRnVywxJxy+ilSTS2lHzQR bg1waFFmVDSmA== Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by lists.lttng.org (Postfix) with ESMTPS id 4GQX4x6gmgz12Hk for ; Thu, 15 Jul 2021 07:21:37 -0400 (EDT) Received: by mail-ot1-x32b.google.com with SMTP id 7-20020a9d0d070000b0290439abcef697so5789877oti.2 for ; Thu, 15 Jul 2021 04:21:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Rohek1ImF0JQHy9yeMYC9yCmFLBSt7f7e8+ZHU/w6UQ=; b=B6FSxPOSmDc/zWssK3nmH/WrI0ql9Gt7DOyHQe+3Zmc0UF5yKrnacVLppZ3PIskobd Bwk9bjTUnIdCwy7s2oCySSy4qS0sR2Ftuv0xh4I0/yJk0vT9JdWwjxoSo3gMzOPxeZV8 dL0ow4cIOynudkJhyjUl74GJBKVHgF1yEm58ph8vUbaKIuHYWRf1tDp9Xk1wE4AXmM19 X9K/hNko4GSRYcX03ladyss7E1RsxHn3RFk4PqSxkK0xj51Oq7c/IZsLNhvkAWz/g1L8 KATMUXakXjyBvc0YKGqBB775h+Gs3x8VBVQYafnqIgvqX2ZoXB9eEacEbo3dIm9l/IQq Rd4Q== X-Gm-Message-State: AOAM5329tyOTK0U3EZ2OQkLkaRSdUNL2nqohhjdU1GUORTpybSaJKIKS NrWvMuzjQ35FKZ/2SAMCKbhHF6WEDYBuNhkFo28XEl0Cl/w5Zw== X-Google-Smtp-Source: ABdhPJzPNw8OlnUfBPvVwfrK3QBwkIybTUAn1DqrFskSRy+ZdBHPkMY2zav6GoPtDHjnLGgyWyLCCcGNmfO0ORJPOLk= X-Received: by 2002:a9d:5603:: with SMTP id e3mr3312453oti.178.1626348096802; Thu, 15 Jul 2021 04:21:36 -0700 (PDT) MIME-Version: 1.0 Date: Thu, 15 Jul 2021 13:21:25 +0200 Message-ID: To: lttng-dev Subject: [lttng-dev] Feature request: dynamically load from prefix X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Norbert Lange via lttng-dev Reply-To: Norbert Lange Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" Hello, The production rootfs should be untouched, ideally read-only, for development/tests a subdirectory can be mounted (eg. /usr/local). Idea is that the contents of that directory alone (and at most some env variables) should allow enabling development features. For lttng I would have wanted to add a library '/usr/local/lib/libmyservice-tracepoints.so' with runpath '/usr/local/lib' that would activate lttng tracing, pulling in lttng libraries (ust, ust-tracepoint) from /usr/local/lib. There is a caveat though, unless 'libmyservice-tracepoints.so'' is preloaded, the code in lttng/tracepoint.h will run constructor functions to register the tracepoint probes, trying to dlopen the lttng-ust-tracepoint library and fail at that because this is not in the library search paths. At a later time, 'libmyservice-tracepoints.so'' will be loaded, and lttng-ust-tracepoint (along with lttng-ust) can be resolved. but the tracepoints are not registered. So I guess what I would need is to either retrigger the registration of tracepoints (likely complicated with static and weak symbols potentially causing a mess), or redirect the dlopen function. Useful would be either try to find the library in /usr/local/lib or use '/usr/local/lib/libmyservice-tracepoints.so'' instead of lttng-ust-tracepoint (both have (dis)advantages). At any rate, I would welcome some customization macro. For illustration the current hack-around is following Norbert Lange #define TRACEPOINT_DEFINE #define TRACEPOINT_PROBE_DYNAMIC_LINKAGE #include static inline void *s_remap_dlopen(const char *localfilename, int flags, unsigned prelen) { void *md = (dlopen)(localfilename + prelen, flags); return md ? md : (dlopen)(localfilename, flags); } # ideally this would be LTTNG_TRACEPOINT_PROBE_DLOPEN instead of the dlopen mess #define dlopen(x, y) s_remap_dlopen("/usr/local/lib/" x, y, (unsigned)sizeof("/usr/local/lib/") - 1U) #include "trace_mytracepoints.h" _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev