search

reverie-rs / reverie

trace and intercept linux syscalls.
Other
14 stars 5 forks source link

Minor: allow --tool to take a path #29

Closed rrnewton closed 5 years ago

rrnewton commented 5 years ago

I really don't like the inflexibility of ONLY being able to load tools named libXYZ.so that are in LD_LIBRARY_PATH.

If we want to keep both abilities, it seems like a simple trigger is if "/" is contained in the argument to --tool, then it refers to an absolute or relative path:

--tool FOO    => search for libFOO.so
--tool ./dir/foo.so  => just use the damn dynamic lib directly
wangbj commented 5 years ago

there's a another option --library-path, would --library-path=<dir> --tool <FOO> work?

rrnewton commented 5 years ago

Oh, I see there's already some logic here for conditionally appending "lib"/".so":

https://github.com/iu-parfunc/systrace/blob/591714e04e1f6445014a0eefd451f1311476d0d9/src/main.rs#L325

rrnewton commented 5 years ago

Yeah, it could become equivalent to do:

systrace --library-path "./lib" --tool "foo.so"

But that undocumented conditional behavior on --tool is currently somewhat fragile and also doesn't support loading .so's that are not named "lib.so". It merely avoids appending "lib"/".so" if both are already there. A slightly improved (but still hacky) version of this policy would be to treat it as a filename if it ends with an extension. Treat it as a "stem" (FOO => libFOO.so) otherwise.

wangbj commented 5 years ago

will do. Are you OK with keep both --library-path and --tool, instead of specifying path in --tool?

wangbj commented 5 years ago

should be fixed in b40e25c6dc720043e8e5589b445a353ef0c3da59