Re: [PATCH v3 1/9] dt_lex: support '/' in probe descriptors
Alan Maguire <[email protected]> Fri, 16 Jan 2026 10:14:51 +0000
| Newsgroups | dev.linux.lists.dtrace |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> >> --- >> 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 >>