script: Support native C/C++ shared object scripting #1205

honggyukim · 2020-09-29T23:39:08Z

This patch adds a native script support that can use a shared object as
a script plugin.

The basic interface is same as python and luajit, but the benefit of
this native script is that it doesn't add any overhead from the
scripting engines. It just bypasses the execution flow into the
dynamically loaded shared object.

The target shared object has to be compiled from C/C++ programs that
provides the following functions.

  void uftrace_begin(struct uftrace_script_info *sc_info);
  void uftrace_entry(struct uftrace_script_context *sc_ctx);
  void uftrace_exit(struct uftrace_script_context *sc_ctx);
  void uftrace_end(void);

The 'struct script_context' is same as the struct used inside uftrace so
it's just passed without any manipulation.

The example C/C++ files are in sctipts directory and the shared objects
can be compiled as follows.

  $ make -C scripts/
  make: Entering directory '/home/honggyu/work/uftrace/scripts'
  gcc -fPIC -shared -o simple_c.so simple.c
  gcc -fPIC -shared -o simple_cpp.so simple.cpp
  make: Leaving directory '/home/honggyu/work/uftrace/scripts'

The basic usage is as follows.

  $ uftrace record -S scripts/simple_c.so --no-libcall t-abc
  program begins...
  entry : main()
  entry : a()
  entry : b()
  entry : c()
  exit  : c()
  exit  : b()
  exit  : a()
  exit  : main()
  program is finished

The output looks exactly same as python and luajit scripts.

Signed-off-by: Honggyu Kim [email protected]

namhyung · 2020-09-30T00:46:03Z

Yes, I like it. Actually I thought about this some time ago, but didn't find real use cases. And we should consider argument and other info for proper usage.

mattyclarkson · 2020-09-30T08:33:37Z

scripts/simple.c

+#include <stdio.h>
+#include <stdint.h>
+
+struct script_context {


Might be worth putting this into a header that can be easily included in a plugin?

Would we need any versioning of the interface?

Yes, we can think about it. I've just put the struct as it looks very simple to copy and paste.

My concern is about having struct list_head for argument info because it adds a dependency on the internal list implementation. It's not always required so user can decide not to use and remove the dependency. I will think more about it. Thanks for the comment.

looks very simple to copy and paste.

Depends if we're ever going to change the structure. I guess as long as we put new members at the end we will be fine.

Depends if you think it would be useful for plugins to know the argument types? Can always follow up with that later.

In the future we may want to have a uftrace/plugin.h (or similar) that includes all the necessary headers for parsing the argument and this structure. For now, it's likely fine to ignore the arguments.

Thanks. uftrace/plugin.h looks good. We have to decide how to provide the header to users. I also prototyped another feature that also needs to provide a header to user, but it's also pending now at #636.

I will think more about how to provide those headers.

I agree that we should provide a header for API/ABI compatibility and also it's good to use a versioning. Then we should consider installing/loading the header and plugin binaries as well.

I've made a draft change at c2c22b8 regarding versioning and providing a header uftrace-script.h.

The C/C++ scripts can be written by including uftrace-script.h and be compiled. The version can be checked before using the struct. We can change the major version when the layout is change and the minor version can be changed when we added a new members at the end of struct.

It's just a draft version, but would like to hear how you think about this approach.

honggyukim · 2020-09-30T08:58:28Z

I will also think about providing a way to disable the uftrace shmem record behaviour when we only need to use this native script interface.

namhyung · 2020-10-01T02:23:23Z

Yes, it's reasonable when we run it during record and want to reduce the overhead. It might be handled in uftrace_begin or using --disable option.

honggyukim · 2020-10-01T23:28:13Z

And we should consider argument and other info for proper usage.

I didn't use struct script_info yet in this implementation because it introduces another internal data structure struct strv so it will make the user to have more complicated header.

How about replace struct strv cmds to just const char *cmds as a concatenated string? I think we don't have to make it complicated unnecessarily and the users can parse the info themselves. I've applied this change at fe80d3f.

cmds/record.c

namhyung · 2020-10-02T03:32:41Z

check-deps/Makefile.check

@@ -35,6 +35,8 @@ ifneq ($(wildcard $(srcdir)/check-deps/have_libluajit),)
  COMMON_CFLAGS += $(shell pkg-config --cflags luajit)
 endif

+COMMON_CFLAGS += -DHAVE_LIBNATIVE
+


I don't think it's needed as it turns on unconditionally.

Sure. I will remove this.

It's now removed, but also we have to always enable script feature so added ca0c6e1.

utils/script-native.c

scripts/Makefile

namhyung · 2020-10-02T03:50:59Z

scripts/info.c

-	struct list_head	*argspec;
-#endif
-};
+#include "utils/uftrace-script.h"


Maybe "script-api.h"? And this should be installed in the target directory (probably "/usr/include/uftrace/") by make install. We can make a "include" directory in the source and put this file there. Users (or plugin developers) can include "uftrace/script-api.h" then.

I will make include directory and put the headers that will be installed together. If you want to put the headers under /usr/include/uftrace directory, the name can be simpler like /usr/include/uftrace/script.h.

utils/uftrace-script.h

namhyung · 2020-10-02T03:58:48Z

utils/uftrace-script.h

+	struct si_version {
+		uint8_t major;
+		uint8_t minor;
+	} ver;


I don't think we will have complex versioning here. Let's simply use an integer.

I thought about handling the major version change doesn't allow the previously compiled shared objects cannot be used. But minor version change allows that the shared objects can be used in a higher version of uftrace.

In summary

If major version is different, then uftrace rejects loading the shared object.

If uftrace minor version is higher than the shared object, then it can use the shared object without a problem.

If uftrace minor version is lower than the shared object, then uftrace rejects loading the shared object.

But I also think that we can simply use a single integer version because the layout will not be changed often and we don't actually distribute the plugin shared object binaries.

I've just made it to use a single uftrace version for both struct.

namhyung · 2020-10-02T04:08:04Z

utils/uftrace-script.h

+	} ver;
+	char			*name;
+	char			*version;
+	bool			record;


I think it's better to have an extensible interface. Also maybe we can have an interface that script also can ask or control the behavior. For example whether it's called from libmcount (record = true), or the script needs argument info, or the script wants to disable shmem buffer saving and so on.

Maybe we can have 2 integers as bitmasks for them. One indicates current status - only the record bit is available for now. The other can control the behavior like disable, or skip arguments. I think we should keep original behavior unless script changes the bitmasks.

Yes, that's also possible. I also thought that it's wasteful to use a bool type here.

Maybe we can have 2 integers as bitmasks for them. One indicates current status - only the record bit is available for now.

For now, I've just made the existing record variable can be disabled by the given native script. If it's disabled by script, then uftrace do not actually record the data.

The other can control the behavior like disable, or skip arguments. I think we should keep original behavior unless script changes the bitmasks.

I don't see any use case for disabling argument record because we can already do this with uftrace command. I will just leave it as is, but can bump up the script version when it's needed.

namhyung · 2020-10-02T04:12:02Z

utils/uftrace-script.h

+	 * struct list_head internally uses 'new' as a variable name so
+	 * it's not possible to use in C++.
+	 */
+#endif


Ok, let's not use it. We can use a simple linked list for this like:

struct sciprt_arg { struct script_arg *next; int type; /* INT, FLOAT, DOUBLE, STR, OTHER(?) */ char data[]; };

We may have to convert the struct list_head to this type. Could you explain why you used char data[] here?

Otherwise, how about modifying utils/list.h that can be compilable in C++, then distribute it together because uftrace also uses GPLv2 same as list.h anyway.

Could you explain why you used char data[] here?

I wanted to handle all types of arguments include strings which have variable length. But maybe we can just use a pointer to the string wrapped in an union for other types. How about this?

struct uft_script_arg { struct uft_script_arg *next; int type; int size; union { int si; unsigned int ui; long sl; ... char *str; } data; };

Thanks for the suggestion. I see that if we introduce another way of handling arguments then we better use this in script-python.c and script-luajit.c as well without using the current struct list_head.

It may take more time to refine them all so I didn't update it for now.

honggyukim · 2020-10-03T23:01:54Z

I've updated this PR again as follows.

aabc21d uftrace: Do not use C++ keywords as variable names
b1d3ff2 script: Change script_info.cmds from struct strv to char*
306b5fd script: Move script_info and script_context out to include/script.h
edeb132 script: Support native C/C++ shared object scripting
ab13871 script: Add version info to script_info
cb05efc script: Make native script disable uftrace record

namhyung

Thanks for your work!

namhyung · 2020-10-04T02:52:15Z

include/script.h

+
+#include <stdint.h>
+#include <stdbool.h>
+#include "utils/list.h"


I don't want to add list.h here.

namhyung · 2020-10-04T02:53:59Z

include/script.h

+	/* for arguments and return value */
+	int			arglen;
+	void			*argbuf;
+	struct list_head	*argspec;


We should think about how to pass argument info. Currently it needs to understand the argspec and calculate position in the argbuf. That's why I suggested something in the previous version.

include/script.h

Makefile

utils/script-native.h

namhyung · 2020-10-04T03:09:38Z

include/script.h

+int uftrace_script_version(void)
+{
+	return SCRIPT_VERSION;
+}


A function definition in the header? I'm afraid that a plugin can consist of multiple files.

Hmm.. Otherwise, the script writer has to implement this. Could you recommend if you have a better idea?

I think it's script writer's responsibility to check the version number.

namhyung · 2020-10-04T03:10:43Z

cmds/script.c

@@ -133,6 +133,7 @@ int command_script(int argc, char *argv[], struct opts *opts)
 	struct uftrace_data handle;
 	struct uftrace_task_reader *task;
 	struct script_info info = {
+		.script_version = SCRIPT_VERSION,


API version? I don't want to repeat "script" in the script_info..

I've changed it to api_version.

namhyung · 2020-10-04T03:12:03Z

utils/script-native.c

+	INIT_NATIVE_API_FUNC(uftrace_script_version);
+	if (SCRIPT_VERSION != __uftrace_script_version()) {
+		pr_warn("incompatible script versions (uftrace %d != module %d)\n",
+			SCRIPT_VERSION, __uftrace_script_version());


Well.. I think we should have backward compatibility so old version of script can still be run.

Yes, it's right. But that's why I made the major and minor version to handle this before. If we want to keep the backward compatibility then we must not change the layout of struct, but we can only append the data to the struct in include/script.h.

namhyung · 2020-10-04T03:14:05Z

scripts/info.c

@@ -9,6 +9,9 @@ void uftrace_begin(struct script_info *sc_info)
 	printf("%s\n", sc_info->version);
 	printf("%s\n", sc_info->name);
 	printf("%s\n", sc_info->cmds);
+
+	/* disable actual data record by uftrace */
+	sc_info->record = false;


As I said before, I'd like to have two bitmasks to control the behavior.

I can make it to use two bitmasks, but I don't see if it's useful to control argument recording so left it for now. I can update it in the next update.

Let's do this in a separate PR. I think it's better to focus on enabling the native script here. Also other scripting like Python might use this feature too.

honggyukim · 2020-10-04T08:27:59Z

I've just pushed only after rebase to make the "force-pushed" to be clearer in the next update. I will update this PR a bit later.

honggyukim · 2020-12-29T21:54:09Z

@namhyung I've updated this patch again with the following changes.

Split uftrace_script_context into uftrace_script_base_ctx and uftrace_script_args.
Remove list.h dependency by passing uftrace_script_base_ctx to native script APIs without argument info.

In addition, I've already made comments for API version handling and record bits so please have a look again. I actually don't have a better idea yet so please let me know if you have better ideas.

namhyung · 2021-01-10T15:00:18Z

utils/script.h

 	int			arglen;
 	void			*argbuf;
 	struct list_head	*argspec;
 };

+/* context and args information passed to script */
+struct uftrace_script_context {
+	struct uftrace_script_base_ctx ctx;


I'd like to rename it to 'base' so that I can refer to 'ctx->base.tid' or so.

namhyung · 2021-01-10T15:01:53Z

Makefile

@@ -338,6 +340,9 @@ endif
 	$(Q)$(INSTALL) $(objdir)/libmcount/libmcount-fast.so $(DESTDIR)$(libdir)/libmcount-fast.so
 	$(Q)$(INSTALL) $(objdir)/libmcount/libmcount-single.so $(DESTDIR)$(libdir)/libmcount-single.so
 	$(Q)$(INSTALL) $(objdir)/libmcount/libmcount-fast-single.so $(DESTDIR)$(libdir)/libmcount-fast-single.so
+	$(call QUIET_INSTALL, headers)
+	$(Q)$(INSTALL) -m 644 $(srcdir)/include/script.h $(DESTDIR)$(incdir)/script.h
+	$(Q)$(INSTALL) -m 644 $(srcdir)/utils/list.h $(DESTDIR)$(incdir)/list.h


We don't use it anymore, right?

namhyung · 2021-01-10T15:05:17Z

utils/script.h

@@ -14,8 +14,6 @@
 #include "utils/script-luajit.h"
 #include "utils/utils.h"

-#define SCRIPT_ENABLED (SCRIPT_LUAJIT_ENABLED || SCRIPT_PYTHON_ENABLED)
-


Maybe we can just make this 'true', then no need to change other code.

namhyung · 2021-01-10T15:11:58Z

scripts/info.c

+#include <stdio.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include "include/script.h"


I'm ok to put the header file there. This script is an example that users can compile even without the uftrace source IMHO. So it should work with the system-installed header.

namhyung · 2021-01-10T15:14:04Z

scripts/Makefile

@@ -0,0 +1,7 @@
+script:
+	gcc -I.. -fPIC -shared -g -o simple_c.so simple.c
+	g++ -I.. -fPIC -shared -g -o simple_cpp.so simple.cpp


No need to implement same one twice. Please add other one like 'count.so'?

namhyung · 2021-01-10T15:16:42Z

include/script.h

+	char			*name;
+};
+
+#endif	/* UFTRACE_INCLUDE_SCRIPT_H */


Don't we need 'extern "C"' here?

namhyung · 2021-01-10T15:22:13Z

include/script.h

+int uftrace_script_version(void)
+{
+	return SCRIPT_VERSION;
+}


I think it's script writer's responsibility to check the version number.

namhyung · 2021-01-10T15:30:23Z

libmcount/mcount.c

@@ -74,6 +74,9 @@ static int __maybe_unused mcount_depth = MCOUNT_DEFAULT_DEPTH;
 /* boolean flag to turn on/off recording */
 static bool __maybe_unused mcount_enabled = true;

+/* boolean flag to turn on/off recording, but keep script working */
+bool __maybe_unused record_enabled = true;


IIRC, mcount_enable can be used for this (hmm.. but it'd need this too)

diff --git a/libmcount/mcount.c b/libmcount/mcount.c index a2310798..60b10945 100644 --- a/libmcount/mcount.c +++ b/libmcount/mcount.c @@ -1232,7 +1232,7 @@ void mcount_exit_filter_record(struct mcount_thread_data *mtdp, mtdp->record_idx--; if (!mcount_enabled) - return; + goto out; if (!(rstack->flags & MCOUNT_FL_RETVAL)) retval = NULL; @@ -1276,6 +1276,7 @@ void mcount_exit_filter_record(struct mcount_thread_data *mtdp, mtdp->nr_events = k; /* invalidate sync events */ } +out: /* script hooking for function exit */ if (SCRIPT_ENABLED && script_str) script_hook_exit(mtdp, rstack);

The struct script_info and script_context can be exposed to the external users so it'd be better to have uftrace_ prefix for their names. Signed-off-by: Honggyu Kim <[email protected]>

It doesn't look like a good idea to expose 'struct strv' type in 'struct script_info' when it's exposed to external users. Rather than using the internal data structure to represent commands, it'd be much simpler to use a concatenated char* string. So this patch changes the type of script_info.cmds from 'struct strv' to 'const char*' type as follows. struct script_info { char *name; char *version; bool record; - struct strv cmds; + const char *cmds; }; Signed-off-by: Honggyu Kim <[email protected]>

The current script context is as follows. /* base context information passed to script */ struct uftrace_script_context { int tid; int depth; uint64_t timestamp; uint64_t duration; /* exit only */ unsigned long address; char *name; /* for arguments and return value */ int arglen; void *argbuf; struct list_head *argspec; }; This patch splits it into the following two parts so that the additional script APIs can selectively support them. For example, native script API will not support arguments for now. /* base context information passed to script */ struct uftrace_script_base_ctx { int tid; int depth; uint64_t timestamp; uint64_t duration; /* exit only */ unsigned long address; char *name; }; /* arguments and return value passed to script */ struct uftrace_script_args { int arglen; void *argbuf; struct list_head *argspec; }; /* context and args information passed to script */ struct uftrace_script_context { struct uftrace_script_base_ctx base; struct uftrace_script_args args; }; Signed-off-by: Honggyu Kim <[email protected]>

This patch factors out uftrace_script_info and uftrace_script_base_ctx from utils/script.h to include/script.h, which can be included in C/C++ native scripts. The header will be installed into $DESTDIR/include/uftrace/script.h to be used by native script writers. Signed-off-by: Honggyu Kim <[email protected]>

Currently script can be diabled when both python and luajit is not enabled during configure, but need to prepare to always enable it to have native script feature. Signed-off-by: Honggyu Kim <[email protected]>

This patch adds a native script support that can use a shared object as a script plugin. The basic interface is same as python and luajit, but the benefit of this native script is that it doesn't add any overhead from the scripting engines. It just bypasses the execution flow into the dynamically loaded shared object. The target shared object has to be compiled from C/C++ programs that provides the following functions after including "include/script.h". void uftrace_begin(struct uftrace_script_info *sc_info); void uftrace_entry(struct uftrace_script_base_ctx *sc_ctx); void uftrace_exit(struct uftrace_script_base_ctx *sc_ctx); void uftrace_end(void); The 'struct uftrace_script_base_ctx' is same as the struct used inside uftrace so it's just passed without any manipulation. The example C files are in sctipts directory and the shared objects can be compiled as follows. $ make -C scripts/ make: Entering directory '/home/honggyu/work/uftrace/scripts' gcc -fPIC -shared -g -o simple.so simple.c gcc -fPIC -shared -g -o info_c.so info.c gcc -fPIC -shared -g -o count.so count.c gcc -fPIC -shared -g -o dump.so dump.c make: Leaving directory '/home/honggyu/work/uftrace/scripts' The basic usage is as follows. $ uftrace record -S scripts/simple_c.so --no-libcall t-abc program begins... entry : main() entry : a() entry : b() entry : c() exit : c() exit : b() exit : a() exit : main() program is finished The output looks exactly same as python and luajit scripts. Signed-off-by: Honggyu Kim <[email protected]>

This patch adds script version info to uftrace_script_info and the script version can be changed when the layout of the script related struct types are changed. The script writer has a reponsibility to check the version. The API version of the script is SCRIPT_API_VERSION and the API version of uftrace engine is sc_info->api_version. Signed-off-by: Honggyu Kim <[email protected]>

This patch makes the given script to disable the actual uftrace record to shared memory. It allows the script control the behavior of uftrace. Signed-off-by: Honggyu Kim <[email protected]>

namhyung

Thanks for working on this.

namhyung · 2023-05-06T22:18:13Z

scripts/info.c

@@ -9,6 +9,9 @@ void uftrace_begin(struct script_info *sc_info)
 	printf("%s\n", sc_info->version);
 	printf("%s\n", sc_info->name);
 	printf("%s\n", sc_info->cmds);
+
+	/* disable actual data record by uftrace */
+	sc_info->record = false;


Let's do this in a separate PR. I think it's better to focus on enabling the native script here. Also other scripting like Python might use this feature too.

namhyung · 2023-05-06T22:19:54Z

utils/script.h

+/* context and args information passed to script */
+struct uftrace_script_context {
+	struct uftrace_script_base_ctx base;
+	struct uftrace_script_args args;


I don't think this is needed. Maybe we can add a separate script context definition for native script and leave this as is.

namhyung · 2023-05-06T22:28:30Z

utils/script.h

@@ -29,7 +29,7 @@ struct uftrace_script_info {
 	char *name;
 	char *version;
 	bool record;
-	struct strv cmds;
+	const char *cmds;


Let's not expose this to users. Native scripts can have a separate header with your change. Maybe argc + argv[] are more appropriate for native scripts.

namhyung · 2023-05-06T22:33:55Z

utils/script-luajit.c

@@ -223,6 +223,9 @@ static int luajit_uftrace_begin(struct uftrace_script_info *info)
 {
 	int i;
 	char *s;
+	struct strv sv = {


Please use STRV_INIT.

namhyung · 2023-05-06T22:34:09Z

utils/script-python.c

@@ -572,6 +572,9 @@ int python_uftrace_begin(struct uftrace_script_info *info)
 	PyObject *ctx;
 	int i;
 	char *s;
+	struct strv sv = {
+		0,
+	};


namhyung · 2023-05-06T22:36:38Z

uftrace.c

+		"",
+		"#",
+		"--",
+		"//",


I think the trailing comma makes line break.

namhyung · 2023-05-06T22:38:46Z

scripts/simple.cpp

+{
+	std::cout << "program is finished\n";
+}
+}


This can be confusing. Please add a comment like // extern "C".

namhyung · 2023-05-06T22:40:52Z

scripts/Makefile

+CSO     = $(SRCS:%.c=%_c.so)
+CPPSO   = $(SRCS:%.cpp=%_cpp.so)
+
+all: $(CSO) $(CPPSO)


This needs to be called from the top level Makefile. But I think you should split the addition of examples to a separate commit.

paranlee · 2024-03-08T23:59:37Z

I thought it would be very useful to write a script to view CPU register information, and I'll work on that feature if it needs to be enhanced.

paranlee · 2024-03-09T02:46:18Z

I've also rebased @honggyukim branch and test the rust plugin works well!

$ uftrace record -S  scripts/simple_rs.so --no-libcall tests/t-abc
uftrace_begin called scripts/simple_rs.so
uftrace_entry called with name: main
uftrace_entry called with name: a
uftrace_entry called with name: b
uftrace_entry called with name: c
uftrace_exit called with name: c
uftrace_exit called with name: b
uftrace_exit called with name: a
uftrace_exit called with name: main
uftrace_end called

https://github.com/paranlee/uftrace/tree/review/native-script

use std::os::raw::c_char;
use std::ffi::CStr;

// Information passed during initialization
#[repr(C)] // Ensure C-compatible layout
pub struct UftraceScriptInfo {
	pub api_version: i32,
	pub name: *const c_char, // Use raw pointer for name and version
	pub version: *const c_char,
	pub record: bool,
	pub cmds: *const c_char,  // Use raw pointer for commands string
}

// Base context information passed to script
#[repr(C)] // Ensure C-compatible layout
pub struct UftraceScriptBaseCtx {
	pub tid: i32,
	pub depth: i32,
	pub timestamp: u64,
	pub duration: u64,
	pub address: usize, // Use usize for address on most platforms
	pub name: *const c_char, // Use raw pointer for name
}

#[no_mangle]
pub extern "C" fn uftrace_begin(info: &UftraceScriptInfo) {
	println!("uftrace_begin called {}", unsafe { CStr::from_ptr(info.name) }.to_string_lossy());
}

#[no_mangle]
pub extern "C" fn uftrace_entry(ctx: &UftraceScriptBaseCtx) {
	println!("uftrace_entry called with name: {}", unsafe { CStr::from_ptr(ctx.name) }.to_string_lossy());
}

#[no_mangle]
pub extern "C" fn uftrace_exit(ctx: &UftraceScriptBaseCtx) {
	println!("uftrace_exit called with name: {}", unsafe { CStr::from_ptr(ctx.name) }.to_string_lossy());
}

#[no_mangle]
pub extern "C" fn uftrace_end() {
	println!("uftrace_end called");
}

namhyung · 2024-03-13T05:47:55Z

I thought it would be very useful to write a script to view CPU register information

I'm not sure if it's useful. The register content is volatile - IOW it's changed whenever you call a function (at least for some registers).

honggyukim · 2024-03-14T11:43:51Z

I've also rebased @honggyukim branch and test the rust plugin works well!

Thanks!

I'll work on that feature if it needs to be enhanced.

I think current status is good but this PR is pending because we have many things to consider to keep the backward compatibility especially for argument handling. Maybe we better drop argument handling for now and let this merged without it.

namhyung · 2024-03-17T17:21:22Z

Maybe we better drop argument handling for now and let this merged without it.

Then it needs to be specified with API version. I thought converting all data into a string and pass them once. This would reduce the complexity to handle different types and number of arguments. But the script should parse the argument (which may be fine since it can control the argument when recording).

yskelg · 2024-10-01T16:54:02Z

This is especially great for uncertain post-mortem analysis or when we are unsure about which filtering parameters to narrow down.

In my opinion, the strength of this feature lies in the fact that uftrace currently cannot dynamically observe information at runtime, but with this, we can script specific parts as needed. Additionally, if we can implement such modules using Rust, C, or C++, which have lower performance overhead compared to other scripting languages, it allows for more flexible observation of the program's behavior at runtime. And once the source code is written as a module, I think it's great that anyone can share and reuse it.

@honggyukim's slides were a great inspiration for me. Thank you so much!

https://uftrace.github.io/talks/uftrace_BHAS23_Arsenal.pdf

I believe that people will find better use cases than the ones I come up with, and that's how it will be.

honggyukim · 2024-10-01T17:02:52Z

Thanks @yskelg. I would like to complete this feature but I haven't had much time for working on this. It's in my TODO list for a long time but didn't get a strong request as of yet.

I can't promise I will continue in the near future but will come back to this when I can find some time. Thanks.

mattyclarkson reviewed Sep 30, 2020

View reviewed changes

honggyukim force-pushed the review/native-script branch from 803bc45 to c2c22b8 Compare October 1, 2020 23:27

namhyung requested changes Oct 2, 2020

View reviewed changes

honggyukim force-pushed the review/native-script branch 2 times, most recently from f7a2024 to cb05efc Compare October 3, 2020 22:58

namhyung reviewed Oct 4, 2020

View reviewed changes

honggyukim force-pushed the review/native-script branch from cb05efc to 6fab0c8 Compare October 4, 2020 08:27

honggyukim force-pushed the review/native-script branch from 6fab0c8 to a1617a5 Compare October 4, 2020 20:18

honggyukim force-pushed the review/native-script branch from a1617a5 to 6801f97 Compare December 29, 2020 21:49

namhyung reviewed Jan 10, 2021

View reviewed changes

honggyukim force-pushed the review/native-script branch from 6801f97 to 98317a9 Compare January 25, 2021 00:03

honggyukim mentioned this pull request Jul 18, 2021

ImportError: dynamic module does not define init function #1284

Closed

honggyukim force-pushed the review/native-script branch 2 times, most recently from c70e89f to 6494fc0 Compare February 20, 2023 08:06

honggyukim added 5 commits May 6, 2023 07:31

script: Add uftrace_ prefix to script_info and script_context

441a52b

The struct script_info and script_context can be exposed to the external users so it'd be better to have uftrace_ prefix for their names. Signed-off-by: Honggyu Kim <[email protected]>

script: Always enable script feature

34aca70

Currently script can be diabled when both python and luajit is not enabled during configure, but need to prepare to always enable it to have native script feature. Signed-off-by: Honggyu Kim <[email protected]>

honggyukim force-pushed the review/native-script branch from 6494fc0 to eaab48c Compare May 6, 2023 11:49

honggyukim added 3 commits May 6, 2023 20:55

script: Make native script disable uftrace record

5cfe799

This patch makes the given script to disable the actual uftrace record to shared memory. It allows the script control the behavior of uftrace. Signed-off-by: Honggyu Kim <[email protected]>

honggyukim force-pushed the review/native-script branch from eaab48c to 5cfe799 Compare May 6, 2023 11:56

namhyung reviewed May 6, 2023

View reviewed changes

honggyukim added the script related to script execution label Jul 23, 2023

script: Support native C/C++ shared object scripting #1205

Are you sure you want to change the base?

script: Support native C/C++ shared object scripting #1205

Conversation

honggyukim commented Sep 29, 2020 • edited Loading

namhyung commented Sep 30, 2020

Choose a reason for hiding this comment

honggyukim Sep 30, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honggyukim Sep 30, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honggyukim commented Sep 30, 2020

namhyung commented Oct 1, 2020

honggyukim commented Oct 1, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honggyukim commented Oct 3, 2020

namhyung left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honggyukim commented Oct 4, 2020

honggyukim commented Dec 29, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

namhyung left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paranlee commented Mar 8, 2024

paranlee commented Mar 9, 2024

namhyung commented Mar 13, 2024

honggyukim commented Mar 14, 2024

namhyung commented Mar 17, 2024

yskelg commented Oct 1, 2024

honggyukim commented Oct 1, 2024

honggyukim commented Sep 29, 2020 •

edited

Loading

honggyukim Sep 30, 2020 •

edited

Loading

honggyukim Sep 30, 2020 •

edited

Loading