public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Alan Maguire <alan.maguire@oracle.com>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH v3 1/9] dt_lex: support '/' in probe descriptors
Date: Fri, 16 Jan 2026 10:14:51 +0000	[thread overview]
Message-ID: <8c33b6fe-04fd-4331-bf81-79824eabcd19@oracle.com> (raw)
In-Reply-To: <aWluoAHJlDsea04U@oracle.com>

On 15/01/2026 22:48, Kris Van Hees wrote:
> On Tue, Jan 13, 2026 at 04:51:24PM +0000, Alan Maguire wrote:
>> This will allow us to support paths in module descriptions.
>>
>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>> ---
>>  libdtrace/dt_lex.l | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libdtrace/dt_lex.l b/libdtrace/dt_lex.l
>> index fd70aa0a..a8268c44 100644
>> --- a/libdtrace/dt_lex.l
>> +++ b/libdtrace/dt_lex.l
>> @@ -48,7 +48,7 @@ static size_t dt_input(char *buf, size_t max_size);
>>  %s S0 S1 S2 S3 S4 S5 SIDENT
>>  
>>  RGX_AGG		"@"[a-zA-Z_][0-9a-zA-Z_]*
>> -RGX_PSPEC	[-$:a-zA-Z_.?*\\\[\]!][-$:0-9a-zA-Z_.`?*\\\[\]!]*
>> +RGX_PSPEC	[-$:a-zA-Z_.?*\\\[\]!][-$:0-9a-zA-Z_.`/?*\\\[\]!]*
> 
> This change makes it that / is allowed anywhere in a probe specification,
> except as first character.  That is a much wider change than what you propose
> this patch to provide.
> 
> It also does not accomplish what you want, because if a probe specification
> does not specify the provider name, a module name starting with / would be
> reported as a syntax error.
> 
> Instead of introducing a change here, would it suffice to have the specified
> library name be resolved by means of the /proc/$PID/maps file or something like
> that, i.e. look at what the absolute path is of the library that matches the
> provided module name?  That avoids needing to change the probe specification
> syntax while also avoiding the complexity of not knowing what the library
> search path is for the task being traced.
> 

I'm not sure how that would work to be honest. We sometimes want to trace
stapsdt probes before the library or binary is running, and then there's no pid
to work with. And if there's a pid to work with, it raises the question of
why we need systemwide probing at all. In practice the [LD_LIBRARY_]PATH
resolution approach works well, and provides a very flexible means of
tracing userspace, even if we want to avoid full path specification
in modules. So if you'd prefer, we can drop the absolute path support, but
I think the automatic path resolution needs to avoid using anything that
relies on having a process running since it needs to handle both running and
not currently running programs to be effective.

>>  RGX_IDENT	([a-zA-Z_`][0-9a-zA-Z_`]*)|([0-9][0-9a-zA-Z_]*`[0-9a-zA-Z_`]*)
>>  RGX_INT		([0-9]+|0[xX][0-9A-Fa-f]+)[uU]?[lL]?[lL]?
>>  RGX_FP		([0-9]+("."?)[0-9]*|"."[0-9]+)((e|E)("+"|-)?[0-9]+)?[fFlL]?
>> -- 
>> 2.43.5
>>


  reply	other threads:[~2026-01-16 10:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-13 16:51 [PATCH v3 0/9] stapsdt provider: simple system-wide probing Alan Maguire
2026-01-13 16:51 ` [PATCH v3 1/9] dt_lex: support '/' in probe descriptors Alan Maguire
2026-01-15 22:48   ` Kris Van Hees
2026-01-16 10:14     ` Alan Maguire [this message]
2026-01-13 16:51 ` [PATCH v3 2/9] stapsdt provider: support systemwide probing Alan Maguire
2026-01-13 16:51 ` [PATCH v3 3/9] test: add systemwide stapsdt note test Alan Maguire
2026-01-13 16:51 ` [PATCH v3 4/9] test: add systemwide stapsdt note test using absolute path Alan Maguire
2026-01-13 16:51 ` [PATCH v3 5/9] test: add systemwide stapsdt note test for library Alan Maguire
2026-01-13 16:51 ` [PATCH v3 6/9] stapsdt: add test for listing systemwide probes in object Alan Maguire
2026-01-13 16:51 ` [PATCH v3 7/9] stapsdt: add test for listing systemwide probes in absolute path object Alan Maguire
2026-01-13 16:51 ` [PATCH v3 8/9] stapsdt: add systemwide test for is-enabled probes Alan Maguire
2026-01-13 16:51 ` [PATCH v3 9/9] documentation: update stapsdt docs to describe wildcard support Alan Maguire
2026-01-16 14:48 ` [PATCH v3 0/9] stapsdt provider: simple system-wide probing Kris Van Hees
2026-01-16 15:10   ` Alan Maguire
2026-01-16 15:33     ` Kris Van Hees
2026-01-16 15:36       ` Alan Maguire
2026-01-16 16:22         ` Kris Van Hees

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8c33b6fe-04fd-4331-bf81-79824eabcd19@oracle.com \
    --to=alan.maguire@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=kris.van.hees@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox